Shop OBEX P1 Docs P2 Docs Learn Events
New CAST instruction for Spin2 - Page 3 — Parallax Forums

New CAST instruction for Spin2

13567

Comments

  • cgraceycgracey Posts: 14,133
    Ken Gracey just had two name ideas:

    SNAP

    THAT

    How do those grab you?
  • cgraceycgracey Posts: 14,133
    More ideas from Ken...

    DOG - the long and thorough version of CASE that smells everything along the way.

    CAT - the table version that scrams from point A to point B right away.
  • DEMUX?
  • Why settle for a GOTO, or even a JUMPTO?
    when you can have a LEAPTO
  • Cluso99 wrote: »
    Agreed for the second option where the numeric is specified.

    I like being able to start at non-zero even tho you’re really saying for example CAST n-x

    What is the pasm result? A table of addresses and you add ‘n’ to the base address? It’s sort of like using an XBYTE instruction with the skip bits all zero.

    What about JTABLE ?
        JTABLE n
          LOWER:  block4
          5: block5
          6: block6
          ...
          11: block11
          OTHER: block12
    

    Postedit

    Use JTABLE n-5 in the above example and code for 0... and forget LOWER:

    I like JTABLE because it's descriptive.
    I preferred the structure of SELECT/CASE until I decided to experiment with ON/GOTO/GOSUB and realised that there was a jump table happening...heck of a lot quicker...great for machine sequences.

  • Why forget LOWER? That seems useful.
  • Cluso99Cluso99 Posts: 18,066
    I think the point being missed is that this CASE TABLE x (or whatever) uses a table (of word addresses) such that all cases will take the same time to execute ie deterministic.

    Short case tables will take longer to execute than could have been possible whereas large case tables will execute faster. But all tables will take the same time to execute regardless of size, and hence be deterministic.

    My preferences...
    CASE TABLE x or JTABLE x
    with
    ELSE:

    And please, no ELIF:
  • Chip, I think Ken's brain is still adjusting from being in high altitudes. :D His suggestions are more confusing, I think.

    I think having a keyword to indicate it's the jump table type is fine, makes it easier for the compiler and very clear for the user.

    I think, after some thought, that using CASE TABLE x would be best and clear. I still prefer DEFAULT or OTHER, but could live with ELSE if it must be.
  • cgraceycgracey Posts: 14,133
    Roy Eltham wrote: »
    Chip, I think Ken's brain is still adjusting from being in high altitudes. :D His suggestions are more confusing, I think.

    I think having a keyword to indicate it's the jump table type is fine, makes it easier for the compiler and very clear for the user.

    I think, after some thought, that using CASE TABLE x would be best and clear. I still prefer DEFAULT or OTHER, but could live with ELSE if it must be.

    CASE TABLE x

    OTHER

    I agree. I can agree with lots of things, but I think I agree with these the most now.
  • Cluso99 wrote: »
    I think the point being missed is that this CASE TABLE x (or whatever) uses a table (of word addresses) such that all cases will take the same time to execute ie deterministic.

    Short case tables will take longer to execute than could have been possible whereas large case tables will execute faster. But all tables will take the same time to execute regardless of size, and hence be deterministic.

    My preferences...
    CASE TABLE x or JTABLE x
    with
    ELSE:

    And please, no ELIF:

    Is there a need for ELSE?

    BASIC's ON/GOTO/GOSUB simply falls through if no match.
  • MJBMJB Posts: 1,235
    does this mean instead of writing
    CASE TABLE x
      1: some  simple things to do
      2: some other things
      3: a little bit more elaborated thing
      4: almost nothing
    
    and leaving the compiler to do the job
    the programmer now has to define 4 subroutines (we do not expect return values do we?)
    for 1: .. 4: with all the overhead?
    that will be called from inside CASE TABLE ... ??

    Or is any expression valid in the case item body?


  • cgraceycgracey Posts: 14,133
    MJB wrote: »
    does this mean instead of writing
    CASE TABLE x
      1: some  simple things to do
      2: some other things
      3: a little bit more elaborated thing
      4: almost nothing
    
    and leaving the compiler to do the job
    the programmer now has to define 4 subroutines (we do not expect return values do we?)
    for 1: .. 4: with all the overhead?
    that will be called from inside CASE TABLE ... ??

    Or is any expression valid in the case item body?


    No, no. It's simple and looks like a regular case statement. The only caveats are that the 'value :' terms are constants and don't exceed 0..255, which is an arbitrary limitation that I'm placing. Multiple lines of statements can be placed after each 'value :'.
  • MJB wrote: »
    does this mean instead of writing
    CASE TABLE x
      1: some  simple things to do
      2: some other things
      3: a little bit more elaborated thing
      4: almost nothing
    
    and leaving the compiler to do the job
    the programmer now has to define 4 subroutines (we do not expect return values do we?)
    for 1: .. 4: with all the overhead?
    that will be called from inside CASE TABLE ... ??

    Or is any expression valid in the case item body?


    This creates an indexed jump table, not a GOSUB table, in place of a sequence of comparison operations. If there are any other limitations beyond a traditional CASE statement they are yet to be announced.

    Taking an example from the SPIN reference:
    case X+Y
      10, 15: !outa[0]
      A*2   : !outa[1]
      30..40: !outa[2]
    X += 5
    'Test X+Y
    'X+Y = 10 or 15? Toggle P0
    'X+Y = A*2? Toggle P1
    'X+Y in 30 to 40? Toggle P2
    'Add 5 to X
    

    Produces a set of comparisons like:
    If X+Y == 10 or X+Y == 15 then !outa[0]
    Elseif X+Y == A*2 then !outa[1]
    Elseif X+Y => 30 and X+Y =< 40 then !outa[2]
    

    This CASE TABLE will instead produce a table of addresses with entries like:
    0  next instruction
    1  next instruction
    2  next instruction
    3  next instruction
    4  next instruction
    5  next instruction
    6  next instruction
    7  next instruction
    8  next instruction
    9  next instruction
    10 !outa[0]
    11 next instruction
    12 next instruction
    13 next instruction
    14 next instruction
    15 !outa[0]
    16 next instruction
    17 next instruction
    18 next instruction
    19 next instruction
    20 next instruction
    21 next instruction
    22 next instruction
    23 next instruction
    24 next instruction
    25 next instruction
    26 next instruction
    27 next instruction
    28 next instruction
    29 next instruction
    30 !outa[2]
    31 !outa[2]
    32 !outa[2]
    33 !outa[2]
    34 !outa[2]
    35 !outa[2]
    36 !outa[2]
    37 !outa[2]
    38 !outa[2]
    39 !outa[2]
    40 !outa[2]
    41 next instruction
    .
    .
    .
    max table value next instruction
    
    This is one example where the CASE TABLE may not work properly, as A*2 can only be determined at compile time if A is a constant, unless the code then includes more code to update the table entries; probably a case of diminishing returns.

    It also shows that for some simple use cases, memory use will be much larger.
    But in some use cases it will be the best balance between code simplicity and deterministic behaviour.

    To re-iterate:
    Cluso99 wrote: »
    I think the point being missed is that this CASE TABLE x (or whatever) uses a table (of word addresses) such that all cases will take the same time to execute ie deterministic.

    Short case tables will take longer to execute than could have been possible whereas large case tables will execute faster. But all tables will take the same time to execute regardless of size, and hence be deterministic.

  • Cluso99Cluso99 Posts: 18,066
    Chip,
    Guess I am now a little confused. I thought that the CASE TABLE x would produce a jump table to addresses. ie there is no possible multiple instructions in the case table statement as can occur in the case statement.
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    Chip,
    Guess I am now a little confused. I thought that the CASE TABLE x would produce a jump table to addresses. ie there is no possible multiple instructions in the case table statement as can occur in the case statement.

    Each case can have a block of code in it. The jump table is just how it gets to those blocks.
  • Cluso99Cluso99 Posts: 18,066
    Thanks Chip
  • cgraceycgracey Posts: 14,133
    I think I'm just going to punt, for now, and call this instruction JUMP.
    JUMP x
      0	: case_0
      1	: case_1
      2	: case_2
      3	: case_3
      4..5	: case_4..5
      6..7	: case_6..7
      other	: case_other
    
  • BeanBean Posts: 8,129
    Not to add more fuel to the fire...BUT...

    What about "WHEN..IS" ?

    WHEN x IS
    1: Dothis
    2: Dothis
    ELSE Dothis

    Maybe leave out the "IS" part...

    Bean

  • I'd call it something like LANE - implies things keep moving and in sync (deterministically), but you branch to preferred lane.
  • Yanomani wrote: »
    XPICK, YPICK; XJMP; YJMP (not to be confused with Z80's IX and IY-based indexing...)

    Made me think of "YUMP!"


  • SLOT
    ?

    Jonathan
  • Yanomani wrote: »
    XPICK, YPICK; XJMP; YJMP (not to be confused with Z80's IX and IY-based indexing...)
    Made me think of "YUMP!"

    So, according to Collins Dictionary, you are thinking about leaving the ground for a short while...

    https://collinsdictionary.com/dictionary/english/yump

    It also makes me think about Super Mario... :lol:
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2019-05-22 18:14
    I'm still not buying the need for a special syntax beyond just case. If a programmer's case block meets the special requirements of the presumptive new keyword, the compiler can emit the special code for it. The only thing that needs to change from the user's standpoint is a note in the Spin docs that adhering to those requirements in their case structures will result in faster, more efficient code.

    This is in keeping with the spare syntax of Spin. After all, DO, FOR, and their ilk have all been subsumed by repeat. So let's keep it that way with case without cluttering up the language with a redundant new keyword.

    -Phil
  • K2K2 Posts: 691
    I'd rather ask for a special fast CASE than contrive everything so that (hopefully) the fastest implementation is chosen.

    I may be in a Aussie state-of-mind today, but both ACTION and LANE sound good to me. It's too whimsical, but FastLane provides uniqueness and suggests dispatch.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I think I'm just going to punt, for now, and call this instruction JUMP.
    JUMP x
      0	: case_0
      1	: case_1
      2	: case_2
      3	: case_3
      4..5	: case_4..5
      6..7	: case_6..7
      other	: case_other
    

    JUMP is a poor choice, because JUMP has no return.
    The instance blocks can be in-line, or function calls, or any mix, but the CASE code executes ONE choice and then falls out the end.
    The fine print is around how it makes that one-of choice, and to me that does not need a new keyword, and certainly does not need a misnomer keyword.
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-05-22 21:04
    Either a new word or a modifier is required to “force” the use of a table.

    Remember, a table is not always faster, nor shorter code. It’s a deliberate requirement to use a table to keep deterministic timing. Otherwise, timing becomes lopsided depending on the path taken.

    So perhaps for consistency with existing CASE command, add the table modifier as in CASE TABLE x or CASETABLE x

    BTW I still like ELSE rather than OTHER, so how about permitting both???
    Seems every language introduced its own case quirk just to make it different from every other language. IMHO else is easier to remember and more language consistent for newbies.

    OT - I have been doing some Python for work. Looked nice, requires indentation. Then I got to ELIF :( Seriously, are we so lazy we cannot type ELSEIF ?
  • Chip,
    Ugh. please just use CASE TABLE x, like you said you liked. JUMP is dumb.

    Also, be sure that it can handle missing numbers, gaps. Like:

    CASE TABLE x
    4      : case 4
    5      : case 5
    10..12 : case 10..12
    13     : case 13
    other  : case other
    
    in the above example, cases 0..3 and 6..9 would go to the other case.
    There would be 15 entries in the table, 0 through 13 plus the other.
  • Cluso99 wrote:
    Then I got to ELIF :( Seriously, are we so lazy we cannot type ELSEIF ?
    Yeah, Perl uses elsif. I've always figured it had something to do with outdated parser/scanner technology seeing the else in elseif and stopping there before scanning the whole word.

    -Phil
  • RaymanRayman Posts: 13,805
    jmg wrote: »
    JUMP is a poor choice, because JUMP has no return.
    The instance blocks can be in-line, or function calls, or any mix, but the CASE code executes ONE choice and then falls out the end.
    The fine print is around how it makes that one-of choice, and to me that does not need a new keyword, and certainly does not need a misnomer keyword.

    Actually, maybe it'd be nice if you could have something like the "break" in the C++ switch statement?
    So, you could combine more options... For example, the "1" case could do both "1" and "2" things if you wanted by leaving off the "break" at the end of the "1" code...

  • jmgjmg Posts: 15,140
    Cluso99 wrote:
    Then I got to ELIF :( Seriously, are we so lazy we cannot type ELSEIF ?
    Yeah, Perl uses elsif. I've always figured it had something to do with outdated parser/scanner technology seeing the else in elseif and stopping there before scanning the whole word.

    -Phil

    Oberon uses ELSIF, and FreeBASIC uses ElseIf
    I think the motivation here is not so much laziness, as tab-stop driven users seek shorter words :)
Sign In or Register to comment.