PDA

View Full Version : Computer Based Interpreter Vs Chip To take advantage of PASM Speed.



TJHJ
01-20-2009, 02:13 AM
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

jazzed
01-20-2009, 02:33 AM
Spin byte code significantly sized programs are smaller than equivalent PASM programs. The ICC output shows this it seems.
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

hippy
01-20-2009, 02:42 AM
There are two problems with the 'compile to assembler' approach on a Propller, and they apply to any language, not just C.

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 (http://www.imagecraft.com) and there's other discussion about their offering within the forum.

[ Edited : corrected numbers, better phrasing ]

Post Edited (hippy) : 1/19/2009 7:25:32 PM GMT

Mike Green
01-20-2009, 02:47 AM
The native Propeller instructions have to reside in the cog's ram which is only 512 longs (with some of them normally for special purposes) and some of that has to be for variables or other data. That's a pretty small program and most compilers are not that good at coding efficiently. The assumption was that most assembly programs would be tightly hand coded, so a Spin to assembly compiler wouldn't make sense.

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.

jazzed
01-20-2009, 02:58 AM
Hippy, good to see you post. Where is the forum? I can never find it!
Mike, What makes sense is relative ... except for inlaws :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

heater
01-20-2009, 03:06 AM
An interesting question that I have also pondered from time to time. I see it like this:

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:)

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.

Mike Green
01-20-2009, 03:31 AM
There was a compiler for the IBM360 called PL360 which was essentially an assembler that had a syntax that looked a bit like Pascal. Admittedly, the IBM360 had index registers, so array subscripts could use the index registers, but PL360 is a useful way of thinking about the use of a high level syntax and semantics to work with very low level machine instructions.

hippy
01-20-2009, 03:42 AM
heater said...
Native PASM I think is very "compiler unfriendly".


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.

heater
01-20-2009, 04:49 AM
Some years ago I worked for Lucas Aerospace on fly by wire aircraft systems. They had an interesting in house language called LUCOL. Now LUCOL was designed to be small, simple, fast. It's prime design aims were to be able to write provably correct programs and to have total knowledge of execution time.

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.

heater
01-20-2009, 05:08 AM
For LUCOL see:

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.

waltc
01-20-2009, 02:49 PM
Hippy wrote:

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.

Baggers
01-20-2009, 07:38 PM
Yeah I'd also say Prop beats FPGA for ease of use, as anyone can pick up a prop and program it, it's a LOT more difficult ( practically impossible ) for just anyone to pick up an FPGA and get a TV or VGA display up and running, let alone anything to populate the display with.

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 :)
Build it and we shall come! as they say lol.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Leon
01-21-2009, 12:31 AM
The Digilent Spartan 3 kit I have has a VGA port and plenty of RAM. Code is available for it and it will only take a few minutes to get it working.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Baggers
01-21-2009, 02:15 AM
Yes, I know that Leon, I could knock up my own TV or VGA driver in VHDL or verilog in a few mins too, but I was talking about ease of use for beginners :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Coley
01-21-2009, 02:28 AM
Sorry if this is a little OT but.....


Baggers said...
Yeah I'd also say Prop beats FPGA for ease of use, as anyone can pick up a prop and program it, it's a LOT more difficult ( practically impossible ) for just anyone to pick up an FPGA and get a TV or VGA display up and running, let alone anything to populate the display with.



I'd agree with this, there is no way that FPGA comes close to Propeller for ease of use.


Leon said...
The Digilent Spartan 3 kit I have has a VGA port and plenty of RAM. Code is available for it and it will only take a few minutes to get it working.


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 http://forums.parallax.com/images/smilies/tongue.gif

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 (http://www.propgfx.co.uk) - The home of the Hybrid Development System and PropGFX Lite

Phil Pilgrim (PhiPi)
01-21-2009, 03:22 AM
One application area in which the Propeller has utterly failed to impress me is heating my morning coffee. Oh sure, you say, it could easily control the fanciest espresso machines — even by touch screen, if that's what you want. But I have to tell you this: when it comes to raw BTU output, the Propeller can't hold a candle to most FPGAs.

-Phil

potatohead
01-21-2009, 03:51 AM
:)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Baggers
01-21-2009, 04:00 AM
Phil, that's very true, it's BTU is also appauling especially compared to Leon's fave :D don't need to give it another mention, as I'm sure we're all aware of what it is :)
now that has some serious BTU output :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Baggers
01-21-2009, 04:14 AM
Back on Topic :)

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

·

Andrew E Mileski
01-21-2009, 04:17 AM
With limited cog memory, performance is ultimately limited by hub bandwidth.

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.

TJHJ
01-22-2009, 12:06 AM
Thanks for the interesting replies,

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