Shop OBEX P1 Docs P2 Docs Learn Events
Spin Implementation? — Parallax Forums

Spin Implementation?

SeairthSeairth Posts: 2,474
edited 2013-01-08 12:48 in Propeller 2
Is the Spin interpreter still going to be loaded from ROM, or will it now be embedded in the compiled binary? Either way, has there been any consideration of publishing the code for it?

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2013-01-08 04:58
    The spin interpreter will be loaded as a soft program - ie it is not in ROM.

    Therefore I expect source to be available, as is for the P1.
  • Heater.Heater. Posts: 21,230
    edited 2013-01-08 07:29
    Chip,
    For Spin in the Prop2, I plan to use the CLUT as the Spin stack...
    Are we talking about the call stack only? Or data stack? Or is there only one stack for both?

    If parameters and local variables are on the CLUT stack it means Spin programs cannot get their addresses any more.

    I suspect not many programs want to do that but it might be worth remembering.

    I think it would break Lonesock's F32 floating point object for example.
  • cgraceycgracey Posts: 14,151
    edited 2013-01-08 08:20
    Heater. wrote: »
    Chip,

    Are we talking about the call stack only? Or data stack? Or is there only one stack for both?

    If parameters and local variables are on the CLUT stack it means Spin programs cannot get their addresses any more.

    I suspect not many programs want to do that but it might be worth remembering.

    I think it would break Lonesock's F32 floating point object for example.

    It's a combined stack. And, yes, it would make locals only directly addressable. Any indexed variables would have to be declared in main memory using VAR. The upside to this is that you are not likely to run out of stack space having only 256 longs because you wouldn't be putting arrays on the stack. And recursive calls would have to be very limited.

    Do you guys see this as much of a problem? I look at it as if locals were something akin to registers.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-01-08 08:25
    In an ideal world, it would be nice to have two versions of the Spin interpreter - one with the stack in the CLUT, and one with the stack in the hub.

    Why?

    The CLUT version should be a little faster, but it will break some existing Spin code and limit call stack depth.

    The HUB version would not break existing code, and allow deep stack nesting (and recursion)
    cgracey wrote: »
    It's a combined stack. And, yes, it would make locals only directly addressable. Any indexed variables would have to be declared in main memory using VAR. The upside to this is that you are not likely to run out of stack space having only 256 longs because you wouldn't be putting arrays on the stack. And recursive calls would have to be very limited.

    Do you guys see this as much of a problem? I look at it as if locals were something akin to registers.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-01-08 08:27
    Here is an idea for simplifying the port of Spin to Propeller 2

    - use separate address spaces for byte code and for data
    - this allows 16 bit pointers (like the Spin interpreter currently uses) for code and for data

    I am sure this has occurred to several people already... and I would prefer a flat 32 bit address space, but this would allow getting something running faster.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-01-08 08:30
    Bill Henning wrote: »
    In an ideal world, it would be nice to have two versions of the Spin interpreter - one with the stack in the CLUT, and one with the stack in the hub.

    Why?

    The CLUT version should be a little faster, but it will break some existing Spin code and limit call stack depth.

    The HUB version would not break existing code, and allow deep stack nesting (and recursion)
    A third alternative might be to put return addresses and linkage information in the CLUT and local variables on a hub stack.
  • Heater.Heater. Posts: 21,230
    edited 2013-01-08 08:56
    Wait a minute. Who says that Spin programs aren't going to want to use the CLUT as, well, a CLUT?
    Are we precluding Spin programs from using video harware?
    Actually can current Spin use video hardware? I have never thought about it.
  • Heater.Heater. Posts: 21,230
    edited 2013-01-08 09:00
    How would one write a Spin program that loads up the CLUT, with say a look up table, and then starts a PASM routine in the same COG that uses that table.

    Same for C for that matter. I was thinking than an FFT might do that for the sin table or an emulator would do that for the dispatch table.
  • Dave HeinDave Hein Posts: 6,347
    edited 2013-01-08 09:19
    Since the Spin interpreter is not in ROM on P2 there will probably be many versions of the interpreter. A CLUT-stack version should be faster, but there are many objects in the OBEX that would need to be modified to work with this.

    Having multiple versions of the interpreter may cause some confusion. We may need to explicity include the source for the interpreter with the Spin source code. Maybe this can be specified in the OBJ section, or a new specifier may be needed.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-01-08 09:23
    Yes, current SPIN can use the video hardware. Eric Ball actually went and wrote a driver with SPIN. Impressive actually.

    I'm with Heater on this point, but there is a whole lot more to be discussed yet.

    Frankly, I would love it if SPIN included LMM this time around. We could do in-line PASM and make large, fast programs "bbc-Basic" style, ideally not as ugly syntax wise though. When it's all said and done, I probably will make this a project based off of whatever SPIN we settle on.
  • AribaAriba Posts: 2,690
    edited 2013-01-08 09:33
    I hope P2-Spin will implement a little LMM execution engine. Many of the object which now use a PASM cog can then be done with the same cog that interpretes the Spin code. Together with the 4 threads per cog this will help to not run out of cogs as soon as with the Propeller 1.

    Such LMM code has then also access to the CLUT and all the other cog features that are not supported by Spin commands.

    Andy

    Edit: I see potatohead had the same idea while I wrote it...
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-01-08 12:48
    I would be fairly certain that LMM would be a "given". This also permits those little routines that are hardly ever called to be placed in hub and allow for more efficient code in the cog. Chip really had to perform wonders to juggle spin into one cog for the P1, but it makes the code very convoluted.

    Do you think that initially a restriction to using the lower 64KB hub space might be acceptable?
Sign In or Register to comment.