Fast Bytecode Interpreter

1356726

Comments

  • The _ret_ may be kludgy, but just 'ret' looks too understated, I think. All the conditions have underscores in them, so my eye expects to see an underscore in a prefix. I wish we could just use if_ret, but that don't make a lick of sense. I tried do_ret, but it looks weird. There is probably a better idea, but I don't have it.
  • The point is a nice additional function for (almost) all instructions with no clock or code penalty.

    Compiler features and naming doesn't impact silicon.

    Personally, there are much more deficiencies in the compilers than converting 1op into 2 instructions or visa versa.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I have been checking the instruction set.

    NOP = 0000_0000000_000_000000000_000000000
    ROR = eeee_0000000_czi_ddddddddd_sssssssss
    But...
    _RET_ ROR 0,0 will be treated as a NOP.
    Any ROR with conditional (if_xxxx), ddddddddd <>0, sssssssss<>0, or #sssssssss will execute correctly. So it's only an extremely specific case which has no purpose that becomes a NOP. This case/exception could be flagged by the assembler.

    However, what happens if this _RET_ ROR 0,0 is preceded by an AUGxx ???
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Is ret_ifnb too long? ifnb = if no branch
  • I'm fine with underscores
    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>
  • Cluso99Cluso99 Posts: 12,981
    edited March 15 Vote Up0Vote Down
    I have three ideas for the _RET_
     IF_RET opcode .....
     _RET   opcode .....
            opcode ......     [WC][,][WZ][,][RET]
    

    Perhaps the last idea makes more sense because it is only performed if a jump/branch is not taken (DJxx etc).
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    However, what happens if this _RET_ ROR 0,0 is preceded by an AUGxx ???

    The AUGx will be applied to the next #immediate related to the AUGx.
    	long	%1111_1111000_000_000000000_000001111 'AUGS $F
    	or	outb,ax
    	nop
    	nop
    	nop
    	or	outb,#0		'AUGS will be applied here
    



    Melbourne, Australia
  • Maybe two aliases for the %0000 condition like
    	else_ret	djnz	count,#loop
    'or
    	ret_after	add	r0,r1
    
    Melbourne, Australia
  • jmgjmg Posts: 10,622
    edited March 15 Vote Up0Vote Down
    ozpropdev wrote: »
    Maybe two aliases for the %0000 condition like
    	else_ret	djnz	count,#loop
    'or
    	ret_after	add	r0,r1
    

    both work, but I still find this simpler, less cluttered, and easier to read & edit.
    		djnz	count,#loop
    		ret
    'or
    		add	r0,r1
    		ret
    
    Identical binary code results.

    PC's should be doing the housekeeping, so programmers do not have to.

  • jmg wrote: »
    ... but I still find this simpler, less cluttered, and easier to read & edit.
    		djnz	count,#loop
    		ret
    'or
    		add	r0,r1
    		ret
    
    Identical binary code results.

    PC's should be doing the housekeeping, so programmers do not have to.

    And how will you write it if you want 2 instructions, an ADD and a RET ?
    In Assembler you need to have control over every aspect of the generated code, you need to be able to count the cycles and the instruction count from the source.
    Both is here not possible without knowing how the assembler optimizes this code.

    Andy
  • jmgjmg Posts: 10,622
    Ariba wrote: »
    And how will you write it if you want 2 instructions, an ADD and a RET ?

    Easy, already covered above.
    		djnz	count,#loop
    		ret
    '...
    		add	r0,r1
    label
    		ret
    
    The instance with the label, is made larger and slower, because the assembler does not (easily) know what jumps
    to the label.
    Ariba wrote: »
    In Assembler you need to have control over every aspect of the generated code, you need to be able to count the cycles and the instruction count from the source.
    Yup, completely agree about control - which is why the solution above exists.

    Count the cycles ? - somewhat less so, as already the P2 stalls in various places, making that impossible.
    If I really want cycles, I time the code in a real device, or use a simulator. I do not expect to be able to extract all the timing nuances from assembler source.

    Instruction count ? - I already look at List files for that, because I commonly use Macros and conditionals in my ASM for other MCUs. Many P2 designers will do the same. (once the tools catch up)
  • jmg wrote: »
    ozpropdev wrote: »
    Maybe two aliases for the %0000 condition like
    	else_ret	djnz	count,#loop
    'or
    	ret_after	add	r0,r1
    

    both work, but I still find this simpler, less cluttered, and easier to read & edit.
    		djnz	count,#loop
    		ret
    'or
    		add	r0,r1
    		ret
    
    Identical binary code results.

    PC's should be doing the housekeeping, so programmers do not have to.

    Totally disagree. It is a single instruction so it shouldn't be represented as two instructions. It's much easier to calculate how many clocks are being used.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 12,981
    edited March 15 Vote Up0Vote Down
    ozpropdev wrote: »
    Maybe two aliases for the %0000 condition like
    	else_ret	djnz	count,#loop
    'or
    	ret_after	add	r0,r1
    

    Love the RET_AFTER syntax!

    For me, it works in both examples.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmg,
    So you never use macros then ?
    Or include files ?
    Or generic calls ?
    Or conditional code ?

    There are already many cases where any exact ASM source-line-to-bytes rule is broken.
    Yep, bin there, done that.

    At some point, when your program is big enough and complex enough to require macros and high level language features you start to ask yourself "Why am I doing all this?". It's time to just use a proper high level language.

    With all that complexity added to PASM the user now has three languages to learn instead of two. Spin + PASM + all that asm meta-programming, rather than simply Spin + PASM.
    Since the approach I suggest (which does get rid of the horribly ugly _underscores_) is not mutually exclusive, you are of course free to use the _ret_ form. A user taste choice.
    I get the idea. It's just that now instructions as written may generate a variable number of actual instructions. Which makes all that instruction counting that people like to do on the Propeller, to get timing right, rather more difficult.

    I have always campaigned for simplicity in the P2, but that boat seems to have sailed a long time ago.
  • I was going to suggest POST_RET, but I like Cluso's suggestion for RET_AFTER even better.
  • Right now, PASM can be written P1 COG style, and it's still reasonable and clean. Out in HUB land, there is more, but there should be too.

    In terms of large assembly language programs, people have two choices right now:

    Just write PASM as the current syntax for doing that is pretty sweet.

    Or

    Online it as well as write procedures, methods on SPIN.

    At some point macro capable tools will happen. That's a third, clearly optional thing.

    I submit, as it should be. SPASM, heh, has all one needs to max out the chip and make effective space / speed choices.

    Re: instructions

    I'm in favor of some explicit declaration for this return functionality. A "ret" should only appear as an instruction when there is one generated.

    If we don't do that, labels can get confusing. Say someone wants to jmp to the ret as an early exit, or something similar. They will have trouble.

    It's tempting to say we are already doing that with the self modify instructions, but really those do not have the label problem, and can always be made explicit.

    This ret if no branch functionality is different enough to warrant it's own syntax. Doing that has been a part of PASM the whole time.

    I see no reason to break that idea.
    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>
  • Dave Hein wrote: »
    I was going to suggest POST_RET, but I like Cluso's suggestion for RET_AFTER even better.
    Was ozpropdev's idea.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgraceycgracey Posts: 8,321
    edited March 15 Vote Up0Vote Down
    I really like RET_AFTER. Is there any way to get that under 8 characters, though, so that it can sit at the tab stop just prior to the instruction? Then, it aligns with most IF_x prefixes.
  • cgracey wrote: »
    I really like RET_AFTER. Is there any way to get that under 8 characters, though, so that it can sit at the tab stop just prior to the instruction? Then, it aligns with most IF_x prefixes.
    I don't think the tab stop matters since we also have IF_NC_AND_NZ and similar.

    RET_NXT would fit though.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • RETPOST

    That would fit.
  • RET_NEXT
    RET_BACK
    RET_THEN
    RET_PAST

  • Cluso99Cluso99 Posts: 12,981
    edited March 15 Vote Up0Vote Down
    Could the RET_AFTER be used as REP_AFTER for the REP instruction?
    This would save having to count instructions to be repeated.

    Perhaps then the SETQ instruction could have pseudo REP for setting the repeat count.

    This might simplify the logic???
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • AUTORET
  • Given that this optional return happens after the instruction is executed surly the RET should come after the operation like the WC and such flags do:

    LABLE IF_X OP RET

    Hmm...Do we still have WC flags and such.
  • Heater. wrote: »
    Given that this optional return happens after the instruction is executed surly the RET should come after the operation like the WC and such flags do:

    LABLE IF_X OP RET

    Hmm...Do we still have WC flags and such.
    I would prefer it after the WC,WC,RET too.
    BTW there would no no IF_xxx possible on these instructions because it is a condition 0000.



    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgraceycgracey Posts: 8,321
    edited March 15 Vote Up0Vote Down
    I agree with the reasoning about RET being placed along with WC and WZ, after the instruction and operands, but it would be marooned way out there. I think this thing needs to go where the conditionals go, so that it jumps out in a consistent position. Otherwise, it gets lost in the noise.
  • cgraceycgracey Posts: 8,321
    edited March 15 Vote Up0Vote Down
    Cluso99 wrote: »
    Could the RET_AFTER be used as REP_AFTER for the REP instruction?
    This would save having to count instructions to be repeated.

    Perhaps then the SETQ instruction could have pseudo REP for setting the repeat count.

    This might simplify the logic???

    That's a neat idea, and doable, but it would preclude the use of a conditional on the last repeated instruction.
  • POSTRET
    PRET
    P_RET
    or just
    RETURN
  • cgracey wrote: »
    Cluso99 wrote: »
    Could the RET_AFTER be used as REP_AFTER for the REP instruction?
    This would save having to count instructions to be repeated.

    Perhaps then the SETQ instruction could have pseudo REP for setting the repeat count.

    This might simplify the logic???

    That's a neat idea, and doable, but it would preclude the use of a conditional on the last repeated instruction.

    Would it simplify the logic?
    Would be nice to not have to count instructions although the assembler can do it.

    Isn't there a NOP or two delay after the REP instruction before the repeat loop starts? If using a SETQ or similar idea, would this avoid the nop(s)?

    Not sure if precluding a conditional on the last instruction is a problem. Would take an extra instruction (2 clocks) if a conditional was required.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • RaymanRayman Posts: 8,337
    edited March 15 Vote Up0Vote Down
    I'll try:

    RET_IF

    "if" for if no jmp. IF also implies what bits it's playing with...
    Prop Info and Apps: http://www.rayslogic.com/
Sign In or Register to comment.