Shop OBEX P1 Docs P2 Docs Learn Events
Fast Bytecode Interpreter - Page 3 — Parallax Forums

Fast Bytecode Interpreter

1356730

Comments

  • cgraceycgracey Posts: 14,133
    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.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • Cluso99Cluso99 Posts: 18,066
    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 ???
  • Is ret_ifnb too long? ifnb = if no branch
  • I'm fine with underscores
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-03-15 06:07
    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).
  • 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
    



  • Maybe two aliases for the %0000 condition like
    	else_ret	djnz	count,#loop
    'or
    	ret_after	add	r0,r1
    
  • jmgjmg Posts: 15,140
    edited 2017-03-15 06:28
    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.

  • AribaAriba Posts: 2,682
    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: 15,140
    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)
  • Cluso99Cluso99 Posts: 18,066
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-03-15 09:40
    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.
  • Heater.Heater. Posts: 21,230
    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.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • cgraceycgracey Posts: 14,133
    edited 2017-03-15 16:35
    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.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • cgraceycgracey Posts: 14,133
    RETPOST

    That would fit.
  • RET_NEXT
    RET_BACK
    RET_THEN
    RET_PAST

  • Cluso99Cluso99 Posts: 18,066
    edited 2017-03-15 16:50
    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???
  • cgraceycgracey Posts: 14,133
    AUTORET
  • Heater.Heater. Posts: 21,230
    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.
  • Cluso99Cluso99 Posts: 18,066
    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.



  • cgraceycgracey Posts: 14,133
    edited 2017-03-15 17:15
    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: 14,133
    edited 2017-03-15 17:18
    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
  • Cluso99Cluso99 Posts: 18,066
    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.
  • RaymanRayman Posts: 13,797
    edited 2017-03-15 18:01
    I'll try:

    RET_IF

    "if" for if no jmp. IF also implies what bits it's playing with...
Sign In or Register to comment.