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.
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
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....
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.
[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.
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.
[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.
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?
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.
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] ?!
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.
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.
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.
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 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.
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).
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.
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.
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?
Comments
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.
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....
The # may be annoying to type, but changing it would make it inconsistent with other instructions that take immediate values.
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.
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.
Agreed.
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.
So, then, call by reference after the ":", instead of call by value? That's going to be confusing.
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
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
Ok. Agreed.
I say we go for it.
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.
Same for call vs. callr, etc.
Maybe even better,
and keep the original syntax for jmp. That provides at least some backward compatibility for those who want it.
-Phil
If you do not like [Rn] the other common asm syntax is @Rn, which is clearer to scan, than a single suffix r.
Usually that would be a code-label, not an address of register.
I'm not following this concern ?
Hmm, of course this moronic forum highlighter thinks @ is a keysymbol, even inside [code] ?!
-Phil
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.
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 : Here, they could not really use *, as the enclosure of the braces contains meaning.
Square braces are currently used in the index variants of the PTRA/PTRB registers.
How about "HUB" instead of "FAR"? Just a thought...
I'm ok with the ##
It's what I'm working on now. P2 Verilog may be done. The old spin is limited to 32KB. New Spin is needed.
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.
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.
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.
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?