Shop OBEX P1 Docs P2 Docs Learn Events
New Spin - Page 9 — Parallax Forums

New Spin

1679111236

Comments

  • Cluso99Cluso99 Posts: 18,069
    Seairth wrote: »
    cgracey wrote: »
    kwinn wrote: »
    cgracey wrote: »
    ........
    .............

    And maybe we could change ":=" to just "=".

    Wonderful. Eliminates one of my two most common mistakes. Now how about NOT using "#" to indicate the most commonly used addressing mode in PASM.

    It looks doable, all right.

    How would the rest of you feel about PASM addresses being expressed as such:
      JMP label         (was 'JMP #label')
      JMP [reg]         (was 'JMP reg')
    

    This would introduce ripple into the literal-vs-register syntax for all branches (and the LOC instruction), but would prevent common mistakes that I even make sometimes.

    I could make this change in the next release, v16. Yea or nay?

    +1
    +2

    bst flags the missing # so I always add a comment if I really want 'jmp reg'.
    It is a big bugbear of mine because I get caught out quite frequently.
  • kwinnkwinn Posts: 8,697
    So good to find I am not alone in getting caught by the : and # so often. Another change to look forward to.
  • +1 for the # swap for convenience,

    However didn't we already try this # swap some time during P2-hot development, then change it back again? I can't remember why , but I remember we've been through this once already
  • jmgjmg Posts: 15,172
    Tubular wrote: »
    +1 for the # swap for convenience,

    However didn't we already try this # swap some time during P2-hot development, then change it back again? I can't remember why , but I remember we've been through this once already

    IIRC, I think it was talked about, but never got implemented, because other items had higher priority....

  • ElectrodudeElectrodude Posts: 1,654
    edited 2017-02-23 04:03
    Why not leave it how it is now and add a compiler warning if there's no #, like BST does, but make it not emit the warning if the target looks like a sensible indirect jump register (i.e. a res, long, certain jump instructions, etc.)?

    The # may be annoying to type, but changing it would make it inconsistent with other instructions that take immediate values.
  • cgraceycgracey Posts: 14,137
    edited 2017-02-23 04:15
    I started making the change and I realized that a replacement was needed for "##". I'm thinking the word "FAR" could precede the label in that case.

    This is going to make PASM code a lot easier on the eyes.

    And yes, Tubular, this came up during P2-Hot. Can't remember exactly what happened, though.
  • jmgjmg Posts: 15,172
    cgracey wrote: »
    I started making the change and I realized that a replacement was needed for "##". I'm thinking the word "FAR" could precede the label in that case.
    FAR works, but can this not also be largely automatic ? - if the longer form is needed, the assembler uses that.

    Other ASMs I use have a generic CALL and JMP that the assembler autosizes to 2 or 3 bytes, and they have SJMP,AJMP,LJMP explicit forms too.

    cgracey wrote: »
    This is going to make PASM code a lot easier on the eyes.

    Agreed.

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-02-23 04:35
    cgracey wrote:
    [x,y] += func2(a, b)
    Maybe we just shouldn't go there.
    I don't know why not. I think the semantics are obvious:

    x += func2(a,b)[0]
    y += func2(a,b)[1]

    I don't like the [x, y] over (x, y), though. Square brackets should be reserved for subscripts. Lists on the right use parentheses, so having them on the left is more consistent.

    In any event, P2 has plenty of native capability with dyads, given the rotates and such. So some native list capability in Spin2 would be nice. To keep things simple, you could limit list returns to two elements, I suppose.
    In cases where two values are produced, they could be handled like this:
    ROTATE(x, y, angle : newxvar, newyvar)
    So, then, call by reference after the ":", instead of call by value? That's going to be confusing.
    And maybe we could change ":=" to just "=".
    Absolutely not! Spin does a great job of distinguishing between assignments and definitions. I think it's important for the syntax to continue reflecting that distinction, regardless of what C and Perl do. Algol and Pascal got it right. And so did Spin.

    -Phil
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-02-23 04:51
    cgracey wrote:
    How would the rest of you feel about PASM addresses being expressed as such:
    JMP label (was 'JMP #label')
    JMP [reg] (was 'JMP reg')

    This would introduce ripple into the literal-vs-register syntax for all branches (and the LOC instruction), but would prevent common mistakes that I even make sometimes.

    I could make this change in the next release, v16. Yea or nay?
    Oh, boy! That's a tough one. The old syntax is pretty much ingrained. And, yes, even though missing #s cause a lot of my own bugs, it is consistent with the other immediate operand notation.

    More to the point, however: IIRC, the P2 has other addressing modes, including some sort of indexing from pointers, right? So I think a broader syntax strategy needs to encompass all addressing modes in a consistent way, before zeroing in on JMPs and CALLs.

    -Phil
  • cgraceycgracey Posts: 14,137
    cgracey wrote:
    [x,y] += func2(a, b)
    Maybe we just shouldn't go there.
    I don't know why not. I think the semantics are obvious:

    x += func2(a,b)[0]
    y += func2(a,b)[1]

    I don't like the [x, y] over (x, y), though. Square brackets should be reserved for subscripts. Lists on the right use parentheses, so having them on the left is more consistent.

    In any event, P2 has plenty of native capability with dyads, given the rotates and such. So some native list capability in Spin2 would be nice. To keep things simple, you could limit list returns to two elements, I suppose.
    In cases where two values are produced, they could be handled like this:
    ROTATE(x, y, angle : newxvar, newyvar)
    So, then, call by reference after the ":", instead of call by value? That's going to be confusing.
    And maybe we could change ":=" to just "=".
    Absolutely not! Spin does a great job of distinguishing between assignments and definitions. I think it's important for the syntax to continue reflecting that distinction, regardless of what C and Perl do. Algol and Pascal got it right. And so did Spin.

    -Phil

    Ok. Agreed.
  • cgracey wrote: »
    kwinn wrote: »
    cgracey wrote: »
    ........
    .............

    And maybe we could change ":=" to just "=".

    Wonderful. Eliminates one of my two most common mistakes. Now how about NOT using "#" to indicate the most commonly used addressing mode in PASM.

    It looks doable, all right.

    How would the rest of you feel about PASM addresses being expressed as such:
      JMP label         (was 'JMP #label')
      JMP [reg]         (was 'JMP reg')
    

    This would introduce ripple into the literal-vs-register syntax for all branches (and the LOC instruction), but would prevent common mistakes that I even make sometimes.

    I could make this change in the next release, v16. Yea or nay?

    I say we go for it.
  • Also second Phil's comments. ":=" makes a lot of sense.

  • Well, if we change

    jmp reg = jump to address of register, or jump to value "jmp 5", if address of reg = 5

    jmp [reg] = jump to contents of register

    Doesn't that then break most things like:

    mov r2, r1, in that it should be mov [r2], [r1] ?

    Or we change add r1, #3 to be add [r1], 3

    I'm not sure I feel good about all those brackets. This is probably some of what came up in the "hot" discussion.

    We could just make jmp work that way, as an odd exception, or maybe flag it, but now, i'm on the fence if it's gonna be made consistent throughout the syntax. We will type nearly twice as much most times.

    Unless, I'm missing something here. Hope I am.

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-02-23 08:36
    Not sure I like the square brackets for indirect jmps. Why not just introduce a pseudo opcode for those?
    jmp     label   'Immediate jmp to label.
    jmpr    reg     'Jmp to contents of reg.
    
    Same for call vs. callr, etc.

    Maybe even better,
    jmpi    label   'Immediate jmp to label.
    jmpr    reg     'Jmp to contents of reg.
    
    and keep the original syntax for jmp. That provides at least some backward compatibility for those who want it.

    -Phil
  • jmgjmg Posts: 15,172
    Not sure I like the square brackets for indirect jmps. Why not just introduce a pseudo opcode for those?
    jmp     label   'Immediate jmp to label.
    jmpr    reg     'Jmp to contents of reg.
    

    Same for call vs. callr, etc.

    -Phil

    If you do not like [Rn] the other common asm syntax is @Rn, which is clearer to scan, than a single suffix r.


  • jmgjmg Posts: 15,172
    edited 2017-02-23 08:42
    potatohead wrote: »
    Well, if we change

    jmp reg = jump to address of register, or jump to value "jmp 5", if address of reg = 5

    Usually that would be a code-label, not an address of register.
    potatohead wrote: »
    jmp [reg] = jump to contents of register

    Doesn't that then break most things like:

    mov r2, r1, in that it should be mov [r2], [r1] ?

    Or we change add r1, #3 to be add [r1], 3

    I'm not following this concern ?
     mov  r2,r1 usually moves to r1, r2 so r1 <- r2
     mov [r2], [r1] is equiv to mov @r2,@r1, which I do not think P2 supports ?
    
    likewise
    
    add r1,#3  gives r1 <- r1+3, not    @R1 <- @R1 + 3
    
    maybe @Rn is better, as it is more obvious that indirection is occurring ?
    

    Hmm, of course this moronic forum highlighter thinks @ is a keysymbol, even inside [code] ?!
  • jmg wrote:
    If you do not like [Rn] the other common asm syntax is @Rn, which is clearer to scan, than a single suffix r.
    Yeah, I thought of that, and it's common in other asms, but @ is already a loaded concept in Spin. In fact, it means just the opposite of what we'd be trying to achieve here ("address of" vs. "contents of"), and I think it would confuse people.

    -Phil
  • TorTor Posts: 2,010
    And please keep ' for comments. // requires a shift on my keyboard :)
    I also very much like to have functions returning multiple values, as Perl can do. I always miss that in C.
    Actually it seems I'm really agreeing with everything Phil says.
  • cgraceycgracey Posts: 14,137
    edited 2017-02-23 09:01
    If [reg] is ugly, we could use *reg. Remember that there are a lot of branch mnemonics that would have to end in 'r' to denote register.
  • cgraceycgracey Posts: 14,137
    If we use * to denote register in branches, it's very simple and kind of a complement to the # rule to denote constants in non-branch instructions.
  • jmgjmg Posts: 15,172
    cgracey wrote: »
    If [reg] is ugly, we could use *reg. Remember that there are a lot of branch mnemonics that would have to end in 'r' to denote register.

    I'm not seeing [reg] as ugly, it is a common usage.
    What does GCC emit in ASM listings ?

    Can you list all the possible indirect modes in P2 ?

    I find this for ARM :
    Examples
    
    LDR r0,[r1,#4]        Load word addressed by R1+4.
    STR r0,[r1],#4        Store R0 to word addressed by R1. Increment R1 by 4.
    LDR r0,[r1,#4]!       Load word addressed by R1+4. Increment R1 by 4.
    LDRLS pc,[r1,r0,LSL #2] jump table idiom: load routine address into PC from R1 + R0 * 4.
    
    Here, they could not really use *, as the enclosure of the braces contains meaning.


  • In P2, register indirection is done by the prefix instructions ALTS,ALTD ,ALTR and ALTI.
    Square braces are currently used in the index variants of the PTRA/PTRB registers.
    1000NNNNN PTRA[INDEX] 'use PTRA + INDEX*SCALE
    1100NNNNN PTRB[INDEX] 'use PTRB + INDEX*SCALE
    1011NNNNN PTRA++[INDEX] 'use PTRA, PTRA += INDEX*SCALE
    1111NNNNN PTRB++[INDEX] 'use PTRB, PTRB += INDEX*SCALE
    1011nnnnn PTRA--[INDEX] 'use PTRA, PTRA -= INDEX*SCALE
    1111nnnnn PTRB--[INDEX] 'use PTRB, PTRB -= INDEX*SCALE
    1010NNNNN ++PTRA[INDEX] 'use PTRA + INDEX*SCALE, PTRA += INDEX*SCALE
    1110NNNNN ++PTRB[INDEX] 'use PTRB + INDEX*SCALE, PTRB += INDEX*SCALE
    1010nnnnn --PTRA[INDEX] 'use PTRA - INDEX*SCALE, PTRA -= INDEX*SCALE
    1110nnnnn --PTRB[INDEX] 'use PTRB - INDEX*SCALE, PTRB -= INDEX*SCALE
    
  • RaymanRayman Posts: 14,580
    edited 2017-02-23 11:31
    Would be interesting to see if the "*" works...

    How about "HUB" instead of "FAR"? Just a thought...
    I'm ok with the ##
  • It seems like all this "New Spin" talk is taking away from the P2 development. I'd prefer seeing the P2 sooner than to have New Spin and then P2 later. Do we really even need a new Spin? Why not just use the old Spin and add a few intrinsics to handle the new features of the P2?
  • cgraceycgracey Posts: 14,137
    Dave Hein wrote: »
    It seems like all this "New Spin" talk is taking away from the P2 development. I'd prefer seeing the P2 sooner than to have New Spin and then P2 later. Do we really even need a new Spin? Why not just use the old Spin and add a few intrinsics to handle the new features of the P2?

    It's what I'm working on now. P2 Verilog may be done. The old spin is limited to 32KB. New Spin is needed.
  • Dave Hein wrote: »
    It seems like all this "New Spin" talk is taking away from the P2 development. I'd prefer seeing the P2 sooner than to have New Spin and then P2 later. Do we really even need a new Spin? Why not just use the old Spin and add a few intrinsics to handle the new features of the P2?
    Dave raises a good point here -- if the interpreter is not built into ROM (and/or if Spin2 is compiled to PASM) then it can be developed in parallel with or after the chip itself. It's tempting to get carried away with adding features to Spin2, but really it would be easy to get Spin1 up and running on the P2 (I did it with an older P2 and fastspin last year, and I think Cluso did it with the Spin1 interpreter as well).
  • Had the above wrong.

    Address of reg = 5, its contents are 10

    Jmp #reg is jmp to address 5. Jmp reg = jmp to contents at address 5, which is 10

    If we change to jmp reg being an address and jmp [reg] being a value, then thing like mov r1, r2 end up mov [r1], [r2], which gets painful.

    Basically, we invert and change most of PASM to make the jmp case a little easier.

    We can flag these easier and be more productive, IMHO.

    I'm gonna withdraw my earlier sentiment. This is what we ran into on the HOT chip. Fixing the jmp, isnt a fix as much as the intent needed is not the default needed for so many other things. Flipping this makes for a ton of other confusion, and work.
  • Re: language before next chip step.

    Right now, its basically ready for synthesis. We really need to exercise a lot of things before doing that. The synthesis is super expensive.

    Seems to me a brief test period, with SPIN and C initial, core development as part of that, is prudent.

  • MJBMJB Posts: 1,235
    BYTE code interpreter ...

    maybe not everybody followed Peter's recent developments on TACHYON.

    It started out with a very fast BYTEcode engine and he recently changed it into a WORDcode engine resulting in a great SPEEDup. Also possibly giving more address reach on the P2.

    I am neither a bytecode engine nor compiler writer ... just thought I mention it.
    Especially since Peter had TACHYON already running on P2 a while ago.
    AND the SPIN engine is a stack machine as well ... so maybe not so different.

  • kwinnkwinn Posts: 8,697
    Ouch! I didn’t mean to start a debate or large scale changes with that suggestion. I could live with a warning for a missing “#” and using := for variable assignment.

    I like PhiPi’s suggestion of adding i or r to the instruction. Similar to the assembler I used back in the day. IIRC a jmp, call, jsr, etc. was direct addressing, adding i was for indirect, and r for relative.

    The *reg idea is also a logical choice. Reminiscent of C string pointers so why not use it as a pointer to the register that holds the address.

    Perhaps make a list of the various choices and take a vote?
Sign In or Register to comment.