Fast Bytecode Interpreter

145791025

Comments

  • I was waiting for the "You are free to not use it." argument to come out.

    It's perfectly true of course.

    My worry about such things is that they can become mind bendingly complicated for anyone but the author to read. Probably hard for the author if he revisits his code after half a year.

    That's OK too.

    Except, wizards will use such things. Their code will end up in OBEX or whatever.

    Others coming along to investigate the P2 will see that and run!

  • Roy Eltham wrote: »
    David Betz,
    You are free to not use it.

    No need to make this personal. I think he's making a valid statement. While I like the general idea (being able to quickly skip a number of intructions), I think skip has got some real issues that shouldn't just be swept aside or marginalized.
  • ctwardell wrote: »
    Obviously some details need to be worked out, but so far the SKIP concept looks very compelling.

    See. The guy who is not afraid to light a fire under his butt gets it.
  • cgracey wrote: »
    ctwardell wrote: »
    Obviously some details need to be worked out, but so far the SKIP concept looks very compelling.

    See. The guy who is not afraid to light a fire under his butt gets it.
    I get it. I just don't think it's a good idea.

  • cgracey wrote: »
    ctwardell wrote: »
    Obviously some details need to be worked out, but so far the SKIP concept looks very compelling.

    See. The guy who is not afraid to light a fire under his butt gets it.

    I think we all get it. But this minor change has potentially significant impact on how code is written. As a result, taking a critical look at it is the right thing to do, no?
  • I see it as allowing for speed and compactness that is not achievable by any other means. This is ninja programming in assembler.
  • cgracey wrote: »
    I see it as allowing for speed and compactness that is not achievable by any other means. This is ninja programming in assembler.

    Indeed! And I like it, mostly! I just think it would be safer if it was cancelled by a branch instruction. It would still allow for ninja coding (your example above would still work, right?) without accidentally throwing a shuriken in your foot.
  • I love it!
    I can see massive potential in activating/de-activating debug code snippets inside code.
    The speed/size benefits for SPIN2 are worth it.
    Melbourne, Australia
  • jmgjmg Posts: 9,846
    edited March 21 Vote Up0Vote Down
    Seairth wrote: »
    cgracey wrote: »
    I see it as allowing for speed and compactness that is not achievable by any other means. This is ninja programming in assembler.

    Indeed! And I like it, mostly! I just think it would be safer if it was cancelled by a branch instruction. It would still allow for ninja coding (your example above would still work, right?) without accidentally throwing a shuriken in your foot.
    Or at least a RET...

    trying to think of cases where Branch would be useful and it seems the whole idea behind skip, is to allow removal of branch instructions.
    In XIP code, a re-address has a significant time cost, so skips within the range of the short-skip (9 single opcodes) would usually be faster.
    Seairth wrote: »
    I think we all get it. But this minor change has potentially significant impact on how code is written. As a result, taking a critical look at it is the right thing to do, no?

    I agree, I think it also needs some Assembler support, so the Skip MASK does not have to be manually crafted and maintained in the most common use cases (as in my IF-ELSE example above). That does not look hard to do.

    Even more obtuse cases, like Chips, could benefit from some simple tools intelligence.

  • Seairth wrote: »
    cgracey wrote: »
    I see it as allowing for speed and compactness that is not achievable by any other means. This is ninja programming in assembler.

    Indeed! And I like it, mostly! I just think it would be safer if it was cancelled by a branch instruction. It would still allow for ninja coding (your example above would still work, right?) without accidentally throwing a shuriken in your foot.

    That it endures through branches is a really strong point. It's going to make The bytecode interpreter really compact. I will have an example up shortly.
  • jmgjmg Posts: 9,846
    cgracey wrote: »
    That it endures through branches is a really strong point. It's going to make The bytecode interpreter really compact. I will have an example up shortly.
    Does it need to endure thru a RET ?

  • I agree that this is really powerful, but unless you have really good tools and debugging facilities to help manage this, it's *going* to come back and bite you in the ****. Use it sparingly. This feels like templates and lambda functions rolled into macro-magic to me. (C++ programmers will understand what I mean)
  • jmg wrote: »
    cgracey wrote: »
    That it endures through branches is a really strong point. It's going to make The bytecode interpreter really compact. I will have an example up shortly.
    Does it need to endure thru a RET ?

    It's not an issue, I think, because if you allow the RET in your SKIP bits, you would not have any 1's above. The exception would be if the RET was conditional, I suppose.

    Making SKIP end upon RET would be trivial, anyway.
  • Heater, this is ASM, why should it be restricted to the beginner level. You always bring up the OBEX and beginners seeing this stuff and freaking out. That is a fine argument for Spin remaining simpler and intuitive, but ASM is for the advanced coders. Also, have you been to the OBEX? It's full of piles of very scary code. P1 is capable of some gnarly obfuscated stuff if you want to do it. You can easily make completely unreadable, hard to follow, obfuscated messes in Spin/PASM for P1. You can also make very clean, simple to follow, elegant code. I think both things are true for P2 and these new changes/additions.

    P2 has interrupts now, so that complicates the crap out of everything for debugging and following code paths. You can write interrupt code that messes with the mainline code flow (isn't it glorious?!) and that's even more invisible at a glance.

    Others:
    I think it's simpler to understand if there are no caveats, like cancelled by some instructions and not others. The aug/alt instructions are instructions so they take a bit in the mask. It allows for even more combinations and compactness. Yes, it's all a bit harder to read/follow, but with comments/documentation it's workable. It's a huge code density win.
  • cgraceycgracey Posts: 7,605
    edited March 21 Vote Up0Vote Down
    I think trying to make the assembler facilitate the generation of SKIP masks is a fool's errand, as it would impose some structure which could really constipate matters. If you're going to use SKIP, you're just going to need to be responsible and wise about it.
  • Maybe Pnut could support a simple bit mask facility like this
    		skip	##!{1,6,13,14}    '   "use these"
    		jmp	#rw_mem
    'instead of
    		skip	##%001111110111100	'execute jmp/rfbyte/add/rdlong/pusha
    		jmp	#rw_mem
    

    and labelling "SKIP" related code blocks like this
    
    ' Read/write hub memory
    '
    rw_mem
    .1		rfbyte	m		'one of these (offset)		3 x
    .2		rfword	m
    .3		rflong	m
    
    .4		add	m,pbase		'one of these (base)		3 x
    .5		add	m,vbase
    .6		add	m,dbase
    
    .7		popa	x		'maybe this (index)		2 x (on/off)
    .8		shl	x,#1		'...and maybe this
    .9		shl	x,#2		'...or maybe this
    .10		add	m,x		'...and this
    
    .11		rdbyte	x,m		'one of these (read)		6 x
    .12		rdword	x,m
    .13		rdlong	x,m
    .14	_ret_	pusha	x		'...and this
    
    .15		popa	x		'or this (write)
    .16	_ret_	wrbyte	x,m		'...and one of these
    .17	_ret_	wrword	x,m
    .18	_ret_	wrlong	x,m
    
    Melbourne, Australia
  • jmgjmg Posts: 9,846
    cgracey wrote: »
    I think trying to make the assembler facilitate the generation of SKIP masks is a fool's errand, as it would impose some structure which could really constipate matters. If you're going to use SKIP, you're just going to need to be responsible and wise about it.
    I'm not following the logic here ?

    The assembler-help use, is not intended to cover all cases, you are always free to enter random bit patterns, in hand crafted kernels.

    The assembler cases suggested are for the common IF_ELSE structures, where mask bits are not random, but are really opcode-counters.

    I can see uses for Skip in XIP code, and if it is a revision minefield, it will tend to be avoided because of that.
    The software help needed here is not complex, just a variation on existing relative jump calculations.

  • Roy ElthamRoy Eltham Posts: 2,104
    edited March 21 Vote Up0Vote Down
    jmg,
    You can already do common if/else stuff with the if_z/if_nz prefixes (or the other variants). The skip instruction is for multiple combination and more complex cases.
  • jmgjmg Posts: 9,846
    Roy Eltham wrote: »
    Others:
    I think it's simpler to understand if there are no caveats, like cancelled by some instructions and not others.
    I can think of use cases where Cancel by RET is both safe and useful, and gives a code density win.
    Chip has said that is easy to do.

    Chip has cases where preserve across Branch are useful, and I'm ok with that. We wait for examples.
    Roy Eltham wrote: »
    The aug/alt instructions are instructions so they take a bit in the mask. It allows for even more combinations and compactness. Yes, it's all a bit harder to read/follow, but with comments/documentation it's workable. It's a huge code density win.
    With some simple Assembler housekeeping, it can be no harder to follow at all.
    Comments are not code, and often give a false sense of what you hoped would happen....

  • Cancel by RET is interesting, but it could be that a RET is the thing you want to skip, right?
    Prop Info and Apps: http://www.rayslogic.com/
  • Dave HeinDave Hein Posts: 5,116
    edited March 22 Vote Up0Vote Down
    I'm OK with the SKIP instruction. I hope that anybody that uses it documents it well so the code is semi-readable. In my opinion, I don't think it's necessary to complicate the assembler by adding special support for the SKIP instruction. Let people handcode the skip patterns. Why take the fun out of it by letting the assembler generate the patterns. :)
  • Might be interesting to have an ENDSKIP command that cannot be skipped.
    Or, not let SKIP be skipped...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 9,846
    Rayman wrote: »
    Cancel by RET is interesting, but it could be that a RET is the thing you want to skip, right?
    Perhaps I should have said cancelled by an executed RET.
    Any RET that is skipped, is surely invisible ? - skip has no idea WHAT it skips over.

  • RaymanRayman Posts: 8,165
    edited March 22 Vote Up0Vote Down
    Googling around, I see AVR has this:

    SBIC - Skip if Bit in I/O Register is Cleared
    Description:
    This instruction tests a single bit in an I/O register and skips the next instruction if the bit is cleared. This instruction operates on the lower 32 I/O registers - addresses 0-31.


    This is pretty wild too, let an I/O pin control whether code is executed or not...
    Prop Info and Apps: http://www.rayslogic.com/
  • I can think of cases where I would not want the skip to be cancelled by a ret. I think it's better if it's not cancelled by anything (except another skip).

  • jmgjmg Posts: 9,846
    Dave Hein wrote: »
    I'm OK with the SKIP instruction. I hope that anybody that uses it documents it well so the code is semi-readable. In my opinion, I don't think it's necessary to complicate the assembler by adding special support for the SKIP instruction. Let people handcode the skip patterns. Why take the fun out of it by letting the assembler generate the patterns. :)

    My approach is a little different.
    I like to write code that is inherently clear, and safe.
    PC's and software exist to manage the housekeeping.
    That is why I already use Macros, and Conditionals in my Assembly
    Mundane Housekeeping is less 'fun', than risk.
    "Let people handcode the skip patterns" seems like quite bad advice to give any novice, but there was no winky here.

  • jmg,
    A novice is not coding in ASM.
  • The way I see this is planned in advance jumps. The other way I see it is table driven execute.

    It's the ON X GOTO of PASM.

    I agree with Roy here. It's Assembly language.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • jmgjmg Posts: 9,846
    Roy Eltham wrote: »
    jmg,
    You can already do common if/else stuff with the if_z/if_nz prefixes (or the other variants). The skip instruction is for multiple combination and more complex cases.
    Not in a SKIP format, which is the broader appeal Skip has to me.
    Of course, Skip can also be used for complex cases, but it is by no means limited to that.

  • JasonDorie wrote: »
    I agree that this is really powerful, but unless you have really good tools and debugging facilities to help manage this, it's *going* to come back and bite you in the ****. Use it sparingly. This feels like templates and lambda functions rolled into macro-magic to me. (C++ programmers will understand what I mean)
    I'm not sure what your objection to lambda functions is. Maybe they're more awkward in C++ than they were in LISP.

Sign In or Register to comment.