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?
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.
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.
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.
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.
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.
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.
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.
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...
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?
Comments
Therefore I expect source to be available, as is for the P1.
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.
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)
- 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.
Are we precluding Spin programs from using video harware?
Actually can current Spin use video hardware? I have never thought about it.
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.
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.
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.
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...
Do you think that initially a restriction to using the lower 64KB hub space might be acceptable?