Spin2 Semantics

It's sure been quiet around here the last few days.

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.
«134

Comments

  • These six xPIN instructions have bytecodes in the interpreter.

    Would it be better to hide the implementation more by insisting on this syntax?
    PIN(n) := exp		WPIN(n,exp)
    PIN(n) := 0		LPIN(n)
    PIN(n) := 1		HPIN(n)
    PIN(n)!			TPIN(n)
    PIN(n)\			ZPIN(n)
    x := PIN(n)		RPIN(n)
    
  • Do these really need to be different to pasm2? I don't really mind what we end up with, but matching on something some basic like this would be nice. I'd be fine with a change in pasm2 to match what we end up with here

    I quite like WRPIN from pasm2, with WXPIN and WYPIN for special smartpin functionality.



  • cgraceycgracey Posts: 11,129
    edited 2019-06-03 - 11:47:17
    Tubular wrote: »
    Do these really need to be different to pasm2? I don't really mind what we end up with, but matching on something some basic like this would be nice. I'd be fine with a change in pasm2 to match what we end up with here

    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:
    WRPIN(pin,val)				bc_wrpin
    WXPIN(pin,val)				bc_wxpin
    WYPIN(pin,val)				bc_wypin
    AKPIN(pin)				bc_akpin
    RDPIN(pin)		(push)		bc_rdpin
    RQPIN(pin)		(push)		bc_rqpin
    

    The trouble is that the PASM instructions which affect DIR and OUT bits and read IN bits are more of a mess:
    DRVC  - maybe just use DRV(pin,val)
    DRVL
    DRVH
    DRVNOT
    DRVRND
    FLTL  - maybe just use FLT(pin)
    TESTP  - maybe just use TEST(pin)
    

    It would be nice to simplify these somehow.
  • TubularTubular Posts: 3,573
    edited 2019-06-03 - 11:51:26
    How cramped for space are you, Chip?
  • PINW(pin,val)
    PINL(pin)
    PINH(pin)
    PINNOT(pin)
    PINRND(pin)
    PINZ(pin)
    x := PIN(pin)
    
  • cgraceycgracey Posts: 11,129
    edited 2019-06-03 - 12:37:52
    Tubular wrote: »
    How cramped for space are you, Chip?

    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.
  • Yeah looking forward to seeing how it all 'cogs' together too

    Am I correct in assuming the cog ram routines are generic (ie you don't need multiple instances for different cogs)?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,324
    edited 2019-06-03 - 13:12:36
    Why not keep it more compatible with Spin1?
    PIN[n] := exp		WPIN(n,exp)
    PIN[n]~		        LPIN(n)
    PIN[n]~~                HPIN(n)
    PIN[n]!			TPIN(n)
    PIN[n]\			ZPIN(n)
    x := PIN[n]		RPIN(n)
    

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • AwesomeCronkAwesomeCronk Posts: 615
    edited 2019-06-03 - 13:56:19
    I like Phil's idea. I think that P1 users moving up to the P2 would find similar code easier to understand. Also, with porting Spin1 objects to Spin2, similarity would be good.
    That's not an explosion! That's an unscheduled rapid disassembly!

    Looking for a way to have a silicon chip made.
  • cgraceycgracey Posts: 11,129
    edited 2019-06-03 - 14:39:09
    I think maybe we should even drop to P[n], instead of PIN[n].

    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.
    P[n] := exp
    P[n]\0
    P[n]\1
    P[n]\float (float = -1)
    P[n]!
    x := P[n]
    

    We could get rid of := in Spin2 and use =, instead. Less typing and clearer:
    P[n] = exp
    P[n] = 0
    P[n] = 1
    P[n] = float (float = -1)
    P[n]! (toggle)
    P[n]? (random)
    x = P[n]
    
  • I don't think "PIN" or "P" are good choices; these are both likely to be common variable and/or constant names in user code.
  • cgraceycgracey Posts: 11,129
    edited 2019-06-03 - 14:45:54
    ersmith wrote: »
    I don't think "PIN" or "P" are good choices; these are both likely to be common variable and/or constant names in user code.

    If we use WPIN/LPIN/HPIN/TPIN/ZPIN/RPIN, we avoid that.
  • If your going with WPIN/LPIN/etc..., then wouldn't PINW,PINL,etc... be better, as you wrote earlier ?
    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.....
  • I'm for using the array-like syntax, especially with the range stuff. Just seems more aesthetically pleasing to me. What about PINS as the keyword?
    Also, please keep the :=
    It's a little odd, but forgetting a : is easier to fix than forgetting the 2nd = in a condition
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,324
    edited 2019-06-03 - 16:53:01
    ersmith wrote:
    I don't think "PIN" or "P" are good choices; these are both likely to be common variable and/or constant names in user code.
    Especially not P. I like PINS, though. And, yes, please keep the :=.

    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?
    PINS[3..5] := 7
    

    And for
    PINS[1]?
    

    Where is the seed stored? It can't be just one bit.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • ersmith wrote:
    I don't think "PIN" or "P" are good choices; these are both likely to be common variable and/or constant names in user code.
    Especially not P. I like PINS, though. And, yes, please keep the :=.

    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?
    PINS[3..5] := 7
    

    And for
    PINS[1]?
    

    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.
  • RaymanRayman Posts: 9,474
    edited 2019-06-03 - 18:49:03
    How about:

    P31:=1 '(for pin #31)

    I.e., just use P0..P63 names directly..
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,522
    cgracey wrote: »
    .....

    We could get rid of := in Spin2 and use =, instead. Less typing and clearer:
    P[n] = exp
    P[n] = 0
    P[n] = 1
    P[n] = float (float = -1)
    P[n]! (toggle)
    P[n]? (random)
    x = P[n]
    
    If you are going to be that brave, you should look more closely at Python, and check what you are doing is not in direct conflict.
    cgracey wrote: »
    PINW(pin,val)
    PINL(pin)
    PINH(pin)
    PINNOT(pin)
    PINRND(pin)
    PINZ(pin)
    x := PIN(pin)
    

    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 ?
  • Cluso99Cluso99 Posts: 14,956
    edited 2019-06-03 - 23:14:21
    If we accept Spin2 for P2 is not compatable with Spin for P1 then...

    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???
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I am not planning on making Spin2 compatible with Spin1. I've tried to make Spin2 ideal for what it is. It would be better to make a Spin2 interpreter for Spin1, I think.
  • jmgjmg Posts: 13,522
    cgracey wrote: »
    I am not planning on making Spin2 compatible with Spin1. I've tried to make Spin2 ideal for what it is. It would be better to make a Spin2 interpreter for Spin1, I think.

    Did you mean to say this ? It would be better to make a Spin2 interpreter for Prop1, I think.
  • cgracey wrote:
    I am not planning on making Spin2 compatible with Spin1.
    Fair enough, as long as you in include the trinary operator x ? y : z. :)

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • jmg wrote: »
    cgracey wrote: »
    I am not planning on making Spin2 compatible with Spin1. I've tried to make Spin2 ideal for what it is. It would be better to make a Spin2 interpreter for Spin1, I think.

    Did you mean to say this ? It would be better to make a Spin2 interpreter for Prop1, I think.

    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?
  • cgracey wrote:
    I am not planning on making Spin2 compatible with Spin1.
    Fair enough, as long as you in include the trinary operator x ? y : z. :)

    -Phil

    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.
  • jmgjmg Posts: 13,522
    cgracey wrote: »
    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?

    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.
  • jmg wrote: »
    Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
    Eric's fastspin covers this case and exists already.

  • David Betz wrote: »
    jmg wrote: »
    Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
    Eric's fastspin covers this case and exists already.

    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgracey wrote: »
    I am not planning on making Spin2 compatible with Spin1. I've tried to make Spin2 ideal for what it is. It would be better to make a Spin2 interpreter for Spin1, I think.

    Excellent. I think this is the best path :smiley:
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    David Betz wrote: »
    jmg wrote: »
    Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
    Eric's fastspin covers this case and exists already.

    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.

    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.
  • Chip,
    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.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
Sign In or Register to comment.