New CAST instruction for Spin2

123457»

Comments

  • Also, does adding OTHER entail a 256-entry long jump table to accommodate determinism for the OTHER option, too?

    -Phil

    OTHER is a separate matter from the table that always picks up the no-match cases. It won't cause the table to be maximally-, or even differently-, sized.
  • Chip,

    Will you be publishing a formal grammar for Spin2? There wasn't one for Spin, which complicated things for others wanting to write a compiler for it.

    Thanks,
    -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
  • I doubt a formal grammar exists.
  • Chip,

    Will you be publishing a formal grammar for Spin2? There wasn't one for Spin, which complicated things for others wanting to write a compiler for it.

    Thanks,
    -Phil

    Yes. It's almost to the point where I can do that. I just need to get it running and make sure it's all sensible.
  • Roy Eltham wrote: »
    I doubt a formal grammar exists.

    https://github.com/totalspectrum/spin2cpp/blob/master/frontends/spin/spin.y is pretty close, I think.
  • ersmithersmith Posts: 3,035
    edited 2019-05-29 - 21:05:34
    ersmith wrote:
    I don't think it's that simple. If the user writes
    case table
    
    did they mean to do a "case x table" statement but forgot the "x", or did they really mean to do a "case" statement with variable "table"?
    That would depend, of course, on whether table was declared as a constant or variable -- an easy check for the compiler to perform.
    It's still ambiguous, even if it was declared as a variable -- the user may simply have forgotten to type the variable they really meant.

    Also, compilers are often written in passes, the first of which (the lexical analyzer) is tasked with identifying keywords and which doesn't know about variables.
    In any event, I have little sympathy for compiler writers who want to make their tasks easy, when the overriding objective should be to make the programmers' tasks easy and the language simple, clear, and elegant. A compiler only has to be written once; programs compiled with it could run in the millions of instances.
    There's no need to make the compiler writers' job any harder, either. Why not use "CASE_FAST" (introducing a new keyword unlikely to conflict with any existing one) or "CASE JMP" (re-using an existing keyword)? They're just as clear, and are easier to parse.

    I think this thread has amply demonstrated that we're never going to get everyone to agree, so I think the guy who's actually implemening the compiler should pick the option that's best for him.
  • Could the compiler spot the existing case statement being used with only sequential constants and make it an optimization to implement it that way?

    This kind of reminds me of having to use CONSTANT(1 + 2) instead of (1 + 2) in p1 spin.
  • ersmithersmith Posts: 3,035
    edited 2019-05-29 - 21:50:56
    PaulForgey wrote: »
    Could the compiler spot the existing case statement being used with only sequential constants and make it an optimization to implement it that way?

    This kind of reminds me of having to use CONSTANT(1 + 2) instead of (1 + 2) in p1 spin.

    As posted earlier, fastspin already does this (both the CASE optimization and the CONSTANT optimization) I don't think Chip wants to add that compexity to his Spin2 compiler right now, but perhaps it'll be implemented later (or perhaps fastspin will implement output of Spin2 bytecodes rather than PASM someday).
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,324
    edited 2019-05-29 - 22:26:02
    PaulForgey wrote:
    This kind of reminds me of having to use CONSTANT(1 + 2) instead of (1 + 2) in p1 spin.
    Automatic constant folding in Spin2 would be a blessing, as would automatic promotion of simple, multi-character strings to their addresses. Of all the inconveniences in Spin, constant and string have to rank pretty high.

    -Phil

    Addendum: Come to think of it, just replacing string with @ would solve the string problem, and make it crystal clear to the programmer that an address was being returned.
    “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 it's that simple. If the user writes
    case table
    
    did they mean to do a "case x table" statement but forgot the "x", or did they really mean to do a "case" statement with variable "table"?
    That would depend, of course, on whether table was declared as a constant or variable -- an easy check for the compiler to perform.

    In any event, I have little sympathy for compiler writers who want to make their tasks easy, when the overriding objective should be to make the programmers' tasks easy and the language simple, clear, and elegant. A compiler only has to be written once; programs compiled with it could run in the millions of instances.

    -Phil

    +1
    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)
  • That's the way, code monkeys dump on the compiler engineers, who dump on systems engineers, who dump on chip engineers, who dump on fabrication engineers. And everyone dumps on the scientists.
    "... 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.