Shop OBEX P1 Docs P2 Docs Learn Events
Why does Spin interpret instead of compiling? — Parallax Forums

Why does Spin interpret instead of compiling?

ElectronegativityElectronegativity Posts: 311
edited 2010-11-08 19:59 in Propeller 1
The title pretty much says it all.

If the Spin code compiled into machine language we could have our cake and eat it too.

Comments

  • LeonLeon Posts: 7,620
    edited 2010-11-08 13:35
    It would use too much memory.
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-11-08 13:40
    Leon wrote: »
    It would use too much memory.
    But, it would be faster. Unfortunately, we cannot have our cake and also eat it, except for very small pieces of cake.
  • wjsteelewjsteele Posts: 697
    edited 2010-11-08 13:48
    Electronegativity wrote: »
    If the Spin code compiled into machine language we could have our cake and eat it too.

    Actually, it's not hard at all to compile spin... the problem is much deeper than that, however.

    All program execution runs in a cog. Spin is interpreted because one or more cogs have a spin intrepreter running in it. That program fits nicely into the cog memory. The actual spin code resides in the 32k of HUB memory. 32k > 512. If you compiled it, it would have to run in 512 instructions... which makes for a small program.

    There is an alternative... mostly referred to as LMM (Large Memory Model,) in which code is compiled and stored in the HUB memory. Then the only thing in the cog memory is a bit of code that reads instructions from HUB memory and executes them. Naturally, it's slower than pure PASM, but it is still faster than SPIN.

    So... you can eat your cake if your prefer small cupcakes... or you can have someone just bring you your cake a byte at a time. :-)

    Bill
  • CampeckCampeck Posts: 111
    edited 2010-11-08 14:02
    Haha!
    Nice explanation steele.
  • ElectronegativityElectronegativity Posts: 311
    edited 2010-11-08 16:50
    Thanks for the explanations.

    This whole thing is giving me flashbacks to the Apple IIC computers I used in high school.
    They ran interpretive BASIC, but you could write assembly subroutines.
  • evanhevanh Posts: 16,159
    edited 2010-11-08 17:51
    Spin and LMM are both virtual machines.

    I'd fallen into the same thinking, that Spin is interpreted, until it was pointed out that the Spin source is not the same program as it's compiled binary counterpart.

    The other factor is addressing, Hub space is treated as main memory in Spin. In native Cog coding Hub space has special instructions to access it.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2010-11-08 17:52
    Electronegativity wrote: »
    Thanks for the explanations.

    This whole thing is giving me flashbacks to the Apple IIC computers I used in high school.
    They ran interpretive BASIC, but you could write assembly subroutines.

    Yes, I think you are forgetting that the Propeller is actually 8 microcontrollers (cogs) on a chip with a common (but slow) 32KB hub RAM. Each cog only has <512 words of memory for program and data so any "assembly" language would have to fit in that small space. Assembly code cannot run directly from the hub RAM either so it makes sense then to "interpret" code from there in much the same way a VM (virtual machine) works.

    Don't confuse a Basic interpreter with a VM runtime interpreter which reads virtual opcodes which have been compiled, in this case with the Spin tool. Spin byte code could be considered the machine code of the Spin VM.

    It is also not possible for the cog to directly address more than 512 words of instruction memory either as this is a feature (and a limitation) of the instruction set.
  • evanhevanh Posts: 16,159
    edited 2010-11-08 17:59
    Having said that, there are big differences between the two though. Spin is a high level language that compiles to a simpler library based binary. Where as LMM tries to be a virtual Cog.
  • ericballericball Posts: 774
    edited 2010-11-08 18:56
    In addition to everything said above, the Propeller Tool compiles the SPIN source code to a bytecode - similar to how Java source is compiled into Java bytecode. The bytecode instructions are often more functionally complex than machine code - again reducing the size of the code required to express a given function.
  • william chanwilliam chan Posts: 1,326
    edited 2010-11-08 19:33
    Leon wrote: »
    It would use too much memory.

    Does this mean that PropBasic also uses too much memory?
  • potatoheadpotatohead Posts: 10,261
    edited 2010-11-08 19:59
    Propbasic can compile to a COG, where the program needs to fit into the ~500 cog longs.

    It can also do LMM, where additional longs are fetched from the HUB, then executed, at a lower speed. This speed is higher than SPIN, but lower than the native COG speed.

    LMM is larger than SPIN, for most things. Maybe all things, but I've not really looked at it closer.
Sign In or Register to comment.