Computer Based Interpreter Vs Chip To take advantage of PASM Speed.
TJHJ
Posts: 243
I am sure this has been done, or discussed but I did not find anything about the subject.
So as I see it, PASM is significantly faster than spin because spin has its own command sets that get interpreted on chip before being executed.
When I look at C compilers for PIC ect, they actually convert it to ASM before the final compiler/chip load. As seen by the fact you can actually look at the ASM file created.
Maybe I am looking at this wrong, but why not have the computer compiler convert the spin to PASM commands before the chip loads, I know this seems like a monstrous idea but I think it is doable. This would let us take advantage of spins simplicity while also using PASM speed.
So What am I missing here? Or Just has it not been done? Did I miss a large discussion on this idea somehow?
Thoughts, Ideas, Comments Please.
Thanks,
TJ
So as I see it, PASM is significantly faster than spin because spin has its own command sets that get interpreted on chip before being executed.
When I look at C compilers for PIC ect, they actually convert it to ASM before the final compiler/chip load. As seen by the fact you can actually look at the ASM file created.
Maybe I am looking at this wrong, but why not have the computer compiler convert the spin to PASM commands before the chip loads, I know this seems like a monstrous idea but I think it is doable. This would let us take advantage of spins simplicity while also using PASM speed.
So What am I missing here? Or Just has it not been done? Did I miss a large discussion on this idea somehow?
Thoughts, Ideas, Comments Please.
Thanks,
TJ
Comments
It would however be nice to have a Spin (or other) compiler that does what you suggest for rapid (non-LMM) PASM output for COG loading.
PASM is easy, but it is nevertheless tedious.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
First, the native instruction set is 32-bit wide and hub memory is limited, just 8K instructions max. Things will be better with the Prop II.
Second, the area within which 32-bit native instructions can run at full-speed is just 496 instructions and that has to include local data as well. That will not change with the Prop II, though some changes will make things even more efficient within the CPU itself.
Thus, thinking of the Propeller as any other micro, it's a small ( but wide ) CPU with a reasonable amount of external memory attached from which data can be fetched but not executed.
That isn't really a good match for running native assembler only, but is a good match for running a high-speed interpreter of a high-level language ( such as Spin bytecode ), and even better ( if you want speed over code size ) for running a very high-speed interpreter of something very close to native assembler (LMM).
That last option is what ImageCraft have adopted with their Propeller C compiler.
www.imagecraft.com and there's other discussion about their offering within the forum.
[noparse][[/noparse] Edited : corrected numbers, better phrasing ]
Post Edited (hippy) : 1/19/2009 7:25:32 PM GMT
The Spin interpretive code was optimized for compactness and to make it easier to code the Spin interpreter to fit into a single cog. The LMM (large memory model) suggested by Bill Henning and improved on by others provided for a small, tight interpreter that can reside in a small portion of a cog's memory and execute modified native instructions from hub (shared) memory with only a 3 or 4 to 1 speed penalty which is very very good for an interpreter and allows programs to be compiled to mostly native code limited by hub size (8K longs). ImageCraft's C compiler works this way.
Mike, What makes sense is relative ... except for inlaws [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Native PASM on a GOG is limited to 512 instructions, it's designed that way and will always be that way. I can't imagine any one wanting to put the effort into building a high level language compiler for SPIN, C , whatever that would always be so limited.
Native PASM I think is very "compiler unfriendly". There are no stack operations, there are no index registers, there is no idea of bytes and words etc etc, things that have evolved in cpus to help compilers. By the time you have gotten your compiler to generate code for all this there is no space left for real work.
Things like indexing an array rely on self modifying code, something which compiler writers probably don't like[noparse]:)[/noparse]
PICs on the other hand although they can be very small are more amenable to compilers.
Now I have thought it might be an idea to dream up a new language that is not so high level as C. Something very simple.
It would not support recursion, for example, only single level calls as the prop does not have a stack. Perhaps it would not support parameter passing either or local variables for routines. It would have GOTO pretty much anywhere. Array indexing would be supported though self modifying code. There may only be one data type LONG. How would this language look ? Starts to sound like BASIC.
But actually PASM is very easy to work with so any intermediate level language would not have much to offer.
For case where you need PASM for speed it's probably better to use assembler. Anything else can be SPIN or nowadays
C as using LMM as Hippy says.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think you're right, especially as I don't think it's easy to get compact code generation for the propeller ( indexing needs a lot of work than for an instruction set which supports it natively, and the same goes for stack handling ).
In terms of the Propeller supporting a virtual instruction set though I think it's perhaps one of the better if not best platforms, but there are things which could be even better there ( especially for quickly expanding thumb-style opcodes of PASM sub-set to full PASM ).
For people interested in virtual instruction sets and roll-your-own CPU's I'd say that for most non-professionals and hobbyists the Propeller beats even FPGA. Certainly FPGA is better, but overall the Propeller is more user friendly and more accessible.
For the Propeller I think it's a different approach for compiler writing to 'how do I generate code for this' but more 'how do I get this to support something compiled'. Chip delivered superbly by holding three points of the important triangle; the Spin language, the Spin interpreter and Cog design. While I've disapproved of some aspect of ImageCraft's implementation of their C compiler it has been the right approach to take.
The first aim is obvious I guess in a safety critical system. The second comes about because all the control algorithms had to 1) Read their sensor inputs, 2) decide what to do and 3) drive their outputs say 10 or 100 times per second. So it was important to know that no piece of code was suddenly going to take a long time in a loop or a recursive function. The combined set of modules HAD to meet their deadline.
To meet these aims the language had no loop condtructs, "loop", "while", "repeat" etc. Only "if" and "else" and function calls. No "goto". No recursion.
How the hell do you write a program with that? You may ask. Well the trick is that all modules were executed every 10 or 100 ms. If the code maintained a state machine it could perform loops within the state machine over a succession of executions.
Now here is the magic part. Because of the lack of loops and gotos it is very easy for the compiler to find the possible path ways through a module find the longest add up the cycles of every instruction on that path and report exactly what the maximum execution time was. This it would do, summing up the time for all modules in a program and issuing an error if the total came too close to the iteration period. This way code could NEVER over step is time slot in mysterious and unexpected ways.
I have not seen any other compiler that can do that!
The functions calls I mentioned were little more than macros that would allow you to use maths funtions, logic functions, integrators etc etc which were hand coded in assembler by he LUCOL implementors. No loops there either. I'm not sure it was possible to define functions in LUCOL. Rather you could write a "sub" module and the write to it's input variables and read it's output variables.
Needless to say most programmers did not like the language. To crude. BUT I observed that newer projects that were done in ADA were just unmanageable and unpredictable in their timing. There was just noway to be sure when that time slot would be overrun!! We never had any such problems with LUCOL.
Those features of LUCOL also made it much easier to write test harnesses and scripts.
So a LUCOL style language may be ideal for compiling to PASM within one or more COGS. Cogs connected together by variables in HUB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dolman, W.C., Parkes, J.P. "An Approach to Software for High Integrity Applications." The American Society of Mechanical Engineers. 82-GT-251
(1982)
"Parallel processing in high integrity aircraft engine control" - S. H. Duncan, P. L. Gordon, E. J. Zaluska1 and S. I. Edwards2
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For people interested in virtual instruction sets and roll-your-own CPU's I'd say that for most non-professionals and hobbyists the Propeller beats even FPGA. Certainly FPGA is better, but overall the Propeller is more user friendly and more accessible.
Gotta disagree with that. The FPGA route offers real flexibility and choice when exploring rolling-your-own CPU's and such. The OTOH Prop offers nothing for the roll your CPU types at all. You are merely locked into Chip's idea of what constitutes a instruction set and architecture much like any other micro-controller you get from Freescale or Microchip.
That being said, the FPGA route requires a solid grasp of basic digital design and computer architecture which limits its access to the more serious hobbyist or EE student.
I love how easy it is to prototype an app with a Prop, I think Chip got it spot on with the design of the Prop, after all, he must have done, it brought us all here didn't it [noparse]:)[/noparse]
Build it and we shall come! as they say lol.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I'd agree with this, there is no way that FPGA comes close to Propeller for ease of use.
I'd agree with this too but it's nowhere near as simple for the beginner or hobbyists otherwise we'd all be on the Xilinx or Altera forums lol or maybe even XLinkers Leon
If you gave two technicians two bags of core components, one FPGA based and one Propeller based, add a way to prototype their design on a board and give them a simple task like flash an LED, I betcha the Prop would be up and running first.
They are two completely different animals, you use each of them for what they are good at, don't compare them it's a complete waste of time and effort!!!!
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
now that has some serious BTU output [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
TJHJ, the whole point of SPIN, is it's ease of use, and small size, it's ability to add together objects, and it's like the glue to PASM keeping things in check.
PASM is used when SPIN just isn't fast enough for driving things fast, like displays, LED arrays, multiple PWM channels, multiple audio channels, fast SPI and I2C modes, yet it can be used to control the PASM drivers, with great simplicity.
don't get me wrong, SPIN can do handle a LOT of things on it's own also, but when you need that extra speed and don't mind the 4bytes per asm instruction for the boost in performance, PASM is used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
LMM manages about 16 MBytes/sec @ 80 MHz, and the best I think that can be coded is 20 MBytes/sec @ 80 MHz.
SPIN's code density isn't that great in my opinion, as most 8 bit execution tokens are basically the same functionality as one ASM instruction. This means that there is a lot more time spent interpreting than executing. There is also no way to substitute ASM as needed for high performance. Function pointers are missing too.
I think 16 bit execution tokens are the way to go, to allow a mix of interpreted code and native ASM. I'm tinkering with this in a DTC Forth.
ASIDE: My current self-challenge is a full feature kernel, plus 3 instructions (read, write, execute) and basic serial routines, in 496 longs or less.
Yeah My whole thing is spin is so simple and great. It really just seems to be picked up so easy by me and many others. So I was thinking if there was a way to use spin as the base, but PASM speed. I guess not.
Thank you all again.
TJ