Spin2 Semantics
cgracey
Posts: 14,152
in Propeller 2
It's sure been quiet around here the last few days.
What do you think would better names for the following Spin2 pin instructions:
Would maybe renaming RPIN to just PIN be better?
I think these need improvement.
What do you think would better names for the following Spin2 pin instructions:
WPIN(pin,val) 'val pin output LPIN(pin) 'low pin outout HPIN(pin) 'high pin output TPIN(pin) 'toggle pin output ZPIN(pin) 'float pin RPIN(pin) 'read pin, returns 0/1
Would maybe renaming RPIN to just PIN be better?
I think these need improvement.
Comments
Would it be better to hide the implementation more by insisting on this syntax?
I quite like WRPIN from pasm2, with WXPIN and WYPIN for special smartpin functionality.
We do have matching interpreter bytecodes for the smart pin instructions:
The trouble is that the PASM instructions which affect DIR and OUT bits and read IN bits are more of a mess:
It would be nice to simplify these somehow.
I've got lots of space in the cog. Cog registers $000..$00CF are free for user PASM code right now. I moved some non-speed-critical routines out to hub RAM to open as much space as possible within the cog RAM for inline assembly and terminate-stay-resident programs.
Here is the interpreter, at the moment.
There are only a few details left to wrap up the interpreter and then a few adjustments to make to the compiler. Then, they should work together. I'm really looking forward to seeing how it all plays together and what it feels like.
Am I correct in assuming the cog ram routines are generic (ie you don't need multiple instances for different cogs)?
-Phil
I got rid of the old var~ and var~~ operators because now we have something better: var\exp. This is for use in expressions where var is returned but updated to exp. This is more flexible and intuitive than before:
var\0 in Spin2 was var~ in Spin1.
var\1 in Spin2 was var~~ in Spin1.
var\exp in Spin2 is allowed.
We could get rid of := in Spin2 and use =, instead. Less typing and clearer:
If we use WPIN/LPIN/HPIN/TPIN/ZPIN/RPIN, we avoid that.
At least they'd sort naturally for docs, and could be simpler to find by function group.
Maybe there is already a convention in-use though.....
Also, please keep the :=
It's a little odd, but forgetting a : is easier to fix than forgetting the 2nd = in a condition
BTW, ~~ and ~ are still useful, and are symmetric as pre- and post- set and clear. It doesn't look like \ can be used a pre-op.
Also, will you be allowing something like this?
And for
Where is the seed stored? It can't be just one bit.
-Phil
There are bitfields possible for all Spin2 variables, but working it into this PIN[x] syntax would be difficult. These PIN operations all amount to a single PASM {#}D instruction that does something to a certain pin. On the next silicon, bits 10..6 add additional pins to the operation, while bits 5..0 specify the base pin. The thing is, it wraps within the 32-pin base-pin group, so you can't span between A and B ports.
To use bitfields, you would have to operate on DIRA or DIRB and also OUTA or OUTB (bitfield is extra_pins<<6 + base_pin):
DIRA.bitfield := -1
OUTA.bitfield := exp
In PASM, DRVRND D/# writes that cog's 32-bit chunk of the hub's xoroshiro128** PRNG value to up to 32 pins at once. So, while the other instructions specify all pins going to some single state, DRVRND and DRVNOT treat each pin individually. So, it's more of a fit for my original WPIN/LPIN/HPIN/... instruction than for a general PIN[y..x] approach. Eric's compiler could unravel all this and compile the appropriate bytecodes, whereas I'm going to rely more on special syntax for optimization.
P31:=1 '(for pin #31)
I.e., just use P0..P63 names directly..
That is nice and clean and follows a widely used function call, which will read easily to almost any other language user.
With Spin2, I think it is better to focus on new users, as there will be far more of them in the long term.
I think Spin2 generator can also generate P1 binaries (as well as P2 binaries) ? Is that still in your plans ?
I will complete the Spin for P1 translation so that P1 spin with minor fixes will run on P2, with few things left out due to not being present on P2.
This will allow the majority of spin programs to work fine with little to no mods.
I believe that I can open up the whole lower 64KB of hub - there is a 16bit address limitation.
In this scenario, IMHO we can have a better Spin2. This decision changes the discussion about Spin2 semantics considerably.
So, can we have a discussion first about if Spin2 will be compatable with Spin1 first?
Note it will never be totally compatable due to P2 differences anyway
If roughly incompatable...
A Spin1 to Spin2 source translator can be written, and would probably not be too difficult.
Get rid of ~ and ~~. It is really no simpler to type X~~ than X := 1. This makes code far simpler to read, and the compiler should use the short bytecode version anyway.
I like @Rayman's
P37..P43 :=1
Fix some problems
if x ### y
where ### can be <, <=, ==, !=, <>, >=, > (missed any?)
There was a problem where we had to use =< and =>. Was that above???
Did you mean to say this ? It would be better to make a Spin2 interpreter for Prop1, I think.
-Phil
I meant to say that. On the other hand, Spin1 is best-suited to Prop1. Spin2 is best-suited to Prop2.
What do you think about this?
Phil explained the whole matter once. He said that Prop1 (and Spin1, I assume) is like a cat sitting tightly in a shoe box. It takes up all the space and there's no dimension which can be increased to allow for more in the box. Spin2, on the other hand, could work in much larger memory models.
I would agree those are the largest sets, but there are also smaller subsets/paths, like Cluso99 mentions.
Freeing Spin2 from having to closely follow Spin1, means you can make it much easier to read, and you can follow wider industry conventions.
That means new users will be much more attracted to P2.
Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
Being able to run Spin2 on P1, also has appeal, tho that path may be moderated by more practical considerations.
IIRC ersmiths fastspin can produce P1 and P2 binaries ? but that may be more for native Spin/Basic/C compile, not Spin-interpreter-bytecodes
All of these choices of Compiler/Interpreter and language cross sets are going to need some clear naming convention.
While it covers the case, it is NOT the same as it compiles to PASM. Thus, anything that is RAM critical, or even with some RAM free, may not work due to larger code size.
I am talking about a Spin1 interpreter running on P2. I stopped working on it a couple of months age when I thought there was no need. I am now convinced otherwise, so I'll finish it when I get time, which is currently short atm.
I believe all 3 can and will co-exist (fastspin, spin1 on P2, spin2) for P2. Each will have their audience.
Excellent. I think this is the best path
I think it's a good idea to have a Spin1 interpreter for the P2. This will allow P1 Spin programs to run on the P2 with little or no changes to the Spin source code. The programs would have to run in the lower 64K of RAM, but the upper RAM could be used for display memory and user data. Now that Chip has posted his Spin2 interpreter it should be fairly easy to modify it to run Spin1 bytecodes.
Certainly should keep some separation between pin operations and smartpin operations. With config for both being all in the one WRPIN instruction I've already noticed people are not making the distinction.