Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 80 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

17778808283160

Comments

  • RaymanRayman Posts: 14,721
    Thanks, think it's starting to sink in...
  • This is strictly an assembler (not hardware) request. Instead of writing:
      jmp #label  ' relative branch
      jmp #\label ' absolute branch
    
    could we instead do:
      bra #label 'relative branch
      jmp #label 'absolute branch
    
    I think having a separate opcode name for relative / absolute branches would make the difference a little clearer, and it would also simplify the assembler syntax for tools that need to parse it. It might also save some headaches for those porting self-modifying code over from the P1 -- modifying the source field of a jmp instruction is probably a bad idea if the jmp is relative!

    Eric
  • jmgjmg Posts: 15,173
    ersmith wrote: »
    could we instead do:
      bra #label 'relative branch
      jmp #label 'absolute branch
    

    Smarter still, is to drag PASM into 2017+ and support what just about every other assembler does.... No hash on label names.
    Hash usually means immediate/absolute value, so somewhat contradicts a RJMP, not not mention adds 'char chaff clutter'.
      rjmp label 'relative branch
      ajmp label 'absolute branch
      jmp label 'generic JUMP, Assembler uses smallest form, usually rjmp.
    
    Usually RJMPs have more limited reach, and you do not want to be editing code just because you added lines....

  • How would you then indicate a jump to the address contained in a register?
  • jmp @addr
    
  • jmg wrote: »
    ersmith wrote: »
    could we instead do:
      bra #label 'relative branch
      jmp #label 'absolute branch
    

    Smarter still, is to drag PASM into 2017+ and support what just about every other assembler does.... No hash on label names.
    Hash usually means immediate/absolute value, so somewhat contradicts a RJMP, not not mention adds 'char chaff clutter'.
      rjmp label 'relative branch
      ajmp label 'absolute branch
      jmp label 'generic JUMP, Assembler uses smallest form, usually rjmp.
    
    Usually RJMPs have more limited reach, and you do not want to be editing code just because you added lines....

    Actually I've grown to like the way hashes are done in PASM; at least it's consistent (jmp #label jumps to the label, jmp label uses the contents of label, just like any other instruction). But that's a slightly different can of worms from the one I was opening :).

    Also, for PASM the "smallest form" issue doesn't really apply since the whole address space can be reached in one instruction. So we just need "absolute jump" and "relative jump" instruction forms. I think making them different instruction mnemonics rather than marking them on the operand makes it easier to read.

    Eric
  • Losing the # symbol then creates a new issue with AUGS options on 'FAR' references.
  • potatoheadpotatohead Posts: 10,261
    edited 2017-04-23 00:45
    We have been over this how many times? The hash on jmp is correct and consistent with how the chip works.

    A P2 is a memory to memory design in the COG, not a load, store design.

    I'm in favor of BRA to differentiate relative jumps, and would prefer it to the slash.

    I am opposed to removing the hash, because it would then be inconsistent with every other use, which we have been through a bunch of times already.

    The PC is not directly addressable on a Prop, and people just have to understand that. Once they do, it makes a ton of sense, as will how COG addressing works compared to hub addressing.

    This isn't an assembler problem. It is all due to the Prop being fundamentally different from most everything else out there.

  • jmgjmg Posts: 15,173
    David Betz wrote: »
    jmp @addr
    

    Yup, @Reg32 is commonly used, and there is also in use IJMP Reg32 , ICALL Reg32 for Indirect Jump / Calls

  • potatoheadpotatohead Posts: 10,261
    edited 2017-04-23 00:45
    Yes, on load store machines, which the P2 is not.
  • potatoheadpotatohead Posts: 10,261
    edited 2017-04-23 01:00
    The way it works now is super simple. Use a hash when you want the number contained in the instruction to be the operand. Don't use one when you want the number contained in the instruction to be the address in memory containing the operand.

    The minute that is understood, jmp #target makes perfect sense.

    It's address as value moved to the PC, which it should be for non indirect jumps, either relative or absolute.

    Adding BRA as a relative jmp helps to clarify absolute vs relative. I like that a lot.

    Because the P2, like P1 is a memory to memory design, not a load store one, most instructions will not need hashes. It's contents of to contents of.





  • potatohead wrote: »
    The way it works now is super simple. Use a hash when you want the number contained in the instruction to be the operand. Don't use one when you want the number contained in the instruction to be the address in memory containing the operand.

    The minute that is understood, jmp #target makes perfect sense.

    It's address as value moved to the PC, which it should be for non indirect jumps, either relative or absolute.

    Adding BRA as a relative jmp helps to clarify absolute vs relative. I like that a lot.

    +1 :)
  • @cgracey
  • jmgjmg Posts: 15,173
    edited 2017-04-23 01:24
    potatohead wrote: »
    We have been over this how many times?
    It will always come up, because P2 ASM is out of phase with everyone else .....
    potatohead wrote: »
    A P2 is a memory to memory design in the COG, not a load, store design.

    So what ?
    potatohead wrote: »
    This isn't an assembler problem. It is all due to the Prop being fundamentally different from most everything else out there.
    Nope, quite the straw man argument.

    The Prop has two opcodes, just like all other MCUs.
    The difference is merely in how the Assembler chooses to present those opcodes to the user.

    Thus it is very much an assembler decision / assembler problem.

    It is quite simple to craft an assembler that is 'more normal' in operation, and reduces char chaff clutter.

    Simple fact:
    Indirect calls are less common in Assembler code, than Label-Derived branches.



  • Please don't remove the # and change the meaning of @. I don't think I could handle another change in syntax. OK, I probably could handle it, but I like the syntax the way it is now.
  • I do too.

  • Dave Hein wrote: »
    Please don't remove the # and change the meaning of @. I don't think I could handle another change in syntax. OK, I probably could handle it, but I like the syntax the way it is now.
    I agree. I don't think PASM should go the way of @ for indirection. I was simply pointing out that other assemblers use that notation. Like Eric, I've gotten used to the # notation and it makes perfect sense.

  • jmgjmg Posts: 15,173
    edited 2017-04-23 06:15
    ersmith wrote: »
    I think making them different instruction mnemonics rather than marking them on the operand makes it easier to read.

    Certainly, reducing char chaff clutter is a good idea. Different mnemonics is a common solution.

    Here are are some quick google examples of how the rest of the industry, manages label references, in there Assembler Code :
    ~~~~~~  AVR Assembler ~~~~~~~~~~~~
        RCALL Somewhat ; Jump to the label somewhat
    [...] here we continue with the program.
    
    Here the jump to the label somewhat somewhere in the program code,
    
    Somewhat: ; this is the jump address
    [...] Here we do something, when we are finished and want to jump back to the calling location:
        RET
    	
    ~~~~~~~~ MicroChip Assembler ~~~~~~~~~~~
    	CALL DELAY
    ...
    DELAY:
    
    ~~~~~~~~~~ Intel x86 Assembler ~~~~~~~~~~~~
    Here is a simple infinite loop:
    top: incl %ecx
    	jmp top
    
    ~~~~~~~~~~ 8051 Assembler ~~~~~~~~~~~~
    
    Loop:  inc  Reg8   ; increment reg
           jmp Loop
    
    ~~~~~~~~~~~ STM8 Assembler Example ~~~~~~~~~~~
    blink_once
        ldw X,#$FFFF    
    loop_delay
        ldw Y,#$0050    
    loop_inner_delay
        decw Y
        jrne loop_inner_delay
        decw X
        jrne loop_delay
        bcpl  PD_ODR,#0    
        ret
    
    ; main program loop
    loop_forever                                    
        call blink_once
        jra loop_forever
    
    ~~~~~~~~~~~ PIC32 Assembler ~~~~~~~~~~~
        /* endless loop */
    endless:
        j        endless
        nop
    
    

    Spot what they ALL have in common ?
    See the absence of char chaff clutter, and how the common simplest syntax means all can be quickly scanned ?

  • So what?

    See how that works jmg? :D

    Seriously, the current syntax makes sense. If it were easy to change it up and make as much sense, it would have happened one of the many times it was discussed.

    Of course, you could show us that simple assembler. If it's compelling...

    :D



  • I think most other processors are a bit different from the P2. They can't load programs into their registers and execute them. So the notion of jumping to a register doesn't make sense in a lot of other processors. Running programs loaded in registers, and jumping to registers is the normal mode for the P2. If we use the syntax of "jmp @register" then we need a new way to designate the location of the register in it's hub image.
  • I like the consistency of the # notation. It has essentially the same meaning as the non-jmp instructions.

    I think consistency is a very important factor. Changing the jmp instructions would make things a mess, unless you also changed the non-jmp ones to be consistent. I do not like that idea at all.
  • jmgjmg Posts: 15,173
    Dave Hein wrote: »
    I think most other processors are a bit different from the P2. They can't load programs into their registers and execute them. So the notion of jumping to a register doesn't make sense in a lot of other processors. Running programs loaded in registers, and jumping to registers is the normal mode for the P2.
    That was true for P1, but not so true anymore for P2, because you can now execute just fine from LUT and HUB - the notion of jumping to a register doesn't make sense there either.

    That means on P2, that code labels are simply labels, not always register aliases.
    Dave Hein wrote: »
    If we use the syntax of "jmp @register" then we need a new way to designate the location of the register in it's hub image.
    There is also Indirect jump/call form IJMP/ICALL used by others already, if you want to avoid @ symbol.



  • I don't want to do it. COG code will be important, used more than enough to carry the great P1 syntax forward.

    Your argument is clear jmg. Well done, but this is a "what is worth what?" scenario, and it's evaluated to "not worth it" a ton of times now.

  • RaymanRayman Posts: 14,721
    edited 2017-04-23 14:23
    I just wish you'd get a warning if the "#" is missing...
    Seems that half my bugs turn out to be a missing #.

    I think jmg is right and that direct calls are much more common.
    If I were doing this from scratch, definitely drop the #...
    Anyway, best if the normal usage is the simplest...
  • kwinnkwinn Posts: 8,697
    Rayman wrote: »
    I just wish you'd get a warning if the "#" is missing...
    Seems that half my bugs turn out to be a missing #.

    I think jmg is right and that direct calls are much more common.
    If I were doing this from scratch, definitely drop the #...
    Anyway, best if the normal usage is the simplest...

    + 1
  • because you can now execute just fine from LUT and HUB - the notion of jumping to a register doesn't make sense there

    Yes it does. And we will see it used regularly too.

    We took explicit steps to insure running COG code mixed with HUB code made sense.

    Just saying. It's not one model or the other here.
  • There will still be plenty of cases where it makes sense to run code from cog memory where execution speed is important. Also, there is only one data streamer, so if you want to stream data in or out it has to be done from cog memory. It will be quite common for code executing from hub memory to call routines in cog memory.
  • jmgjmg Posts: 15,173
    Chip has recently done a great job cleaning up Spin2, to cut down the errors dogging even experienced programmers..., and make it easier for those moving to Spin2 from any other language.

    This problem is exactly the point :
    Rayman wrote: »
    I just wish you'd get a warning if the "#" is missing...
    Seems that half my bugs turn out to be a missing #.

    I think jmg is right and that direct calls are much more common.
    If I were doing this from scratch, definitely drop the #...
    Anyway, best if the normal usage is the simplest...

    Yes, having taken the step to clean up Spin2, it now makes sense to do the same clean up pass for P2ASM....

    The fact that sometimes code might land on a Register, is a red herring, it is the most common code usage that should determine best design. ( litmus test via numbers : in P2 99.902% of possible landing addresses are NOT registers. If P2 is one quarter full, that is still 99.610%)

    In all the assemblers I quoted above, names are always labels, and understood to be destination addresses. No # clutter or confusion.

    Indirect usage is relatively rare, and handled a few different ways. Easy enough to pick one compatible with P2.

  • Warnings for valid code is just wrong.
  • potatoheadpotatohead Posts: 10,261
    edited 2017-04-23 22:39
    Yup.

    People just need to take a moment and understand this:
    The way it works now is super simple. Use a hash when you want the number contained in the instruction to be the operand. Don't use one when you want the number contained in the instruction to be the address in memory containing the operand.

    And that is cake easy! Universal. Anything else gets harder, creates exceptions.

    Most common code will be COG code, by a mile. People will write PASM to get at advanced features and we are designing that right in with reserved COG space for it to happen too.

    The majority of HUB code will be compiled. And SPIN is being made to help that all along. C will work that way by default.

    Many won't need more than PASM snippets, by intent and design, if we get this right.

    Those able to and desiring to write HUB code won't have trouble.

    I'm done on this topic now. Sheesh.

    I really like using BRA for relative and JMP for absolute though. I hope we do it. :D

    I oppose messing with # again.
Sign In or Register to comment.