Has anyone written a spin compiler?
HollyMinkowski
Posts: 1,398
Just wondering if someone has created a compiler for spin.
Seems like one would be useful and that several additions to spin could be added.
It seems a bit odd that the propeller has an interpreter instead of just having an
optimizing compiler. Lots of people can whip up compilers ...it just seems
harder to embed the interpreter than to write a compiler?!?! or am I missing something?
Is there some reason an interpreter was a better choice? You can always make corrections
to a compiler but an interpreter in silicon seems a risky joy or pain forever...I'd have been chewing
down my fingernails and praying no one found an error in the interpreter that could not be fixed.
Seems like one would be useful and that several additions to spin could be added.
It seems a bit odd that the propeller has an interpreter instead of just having an
optimizing compiler. Lots of people can whip up compilers ...it just seems
harder to embed the interpreter than to write a compiler?!?! or am I missing something?
Is there some reason an interpreter was a better choice? You can always make corrections
to a compiler but an interpreter in silicon seems a risky joy or pain forever...I'd have been chewing
down my fingernails and praying no one found an error in the interpreter that could not be fixed.
Comments
I'm not aware of any SPIN compilers - why would you need one when we have a perfectly good SPIN interpreter embedded in each Propeller? But I'm sure some lunatic in these forums has probably either already written one or has one in development
In fact an interpreter is far easier to write than a compiler, and interpreters tend to consume far less resources at both load time and run time. That's why many of the early high level languages for microcomputers were interpreted (pascal, basic etc) - there just wasn't enough space or speed for anything else. The main disadvantage of an interpreted language is that they are usually far slower - often by an order of magnitude - than a compiled language.
But you are right that with an interpreter embedded in silicon you have to get it right first time - so the success of SPIN is a great credit to Parallax in general and Chip Gracey in particular.
If you've been following the various compiler threads, you will see that compilers for the Propeller are still a bit problematic, in that their output sometimes consumes too much space relative to the benefit they offer. This is because the Propeller instruction set is based on 32 bit 'longs', and therefore the code takes up a lot of space. The propeller instruction set is also not particularly well geared to implementing stack based machines, which is the model most modern languages and compilers use. SPIN, on the other, hand is byte-oriented, and it does implement a stack - but it's very slow in consequence, and some things (like floating point) had to be left out altogether to amke it fit at all.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Compiled output that is native PASM is bigger and faster than Spin code (as Ross mentioned). All in all the system Parallax created is a good fit for the target Propeller market. We're always trying to make it wear bigger shoes though [noparse]:)[/noparse] don't be distracted by that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Ask yourself this: What would a compiler for the Propeller compile to? Normally compilers output native instructions of their target processor, which saves one having to write ones code in assembler. BUT for the Propeller this is not realistically an option. PASM instructions are all huge 32 bit things and you can only get 496 of them into the a COG. Not much use spending a lot of time to build a compiler that can only output such small programs.
Then there are issues of not having a stack based architecture, as noted above, and having to use self modifying code in PASM to do anything interesting. Neither is good for complier code generation as far as I understand. Not to mention the difficulties of handling bytes and words in PASM instructions.
Now we do have compilers for the Prop., ICC and Catalina (maybe others). I would argue they are not optimal for the Prop as they compile down to LMM. That is PASM instructions in HUB RAM that have to be fetched into the COG my a PASM kernel and executed there almost one at a time. They have very poor code density due to the size of the PASM op codes and can never approach the raw speed of PASM (which a good compiler almost can) due to the LMM method which is still a form of interpreter.
Interestingly, judging by Chip's reaction when Bill Henning first described the LMM technique on this forum, it had never occurred to Chip to fetch PASM from HUB for execution. I believe that even if it had he would have rejected it as a solution as the code density achievable, i.e. the amount of functionality one can get in the limited space available, is much greater with Spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Gotta go - just got another end of life notice that should keep our purchasing manager busy for a week. . .
Ken Gracey
Parallax, Inc.
This is great news because I can't bear to wait more than a long time[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I agree with everything heater said - 110%. It continues to astound me just how much you can do in SPIN with a tiny RAM footprint, and also much you can do in a measly 496 instructions in PASM. And of course Ken's comments are true as well - SPIN is precision software, engineered with the same level of rigour and attention to detail as the Propeller hardware itself.
And yet ....
.... stepping up on soapbox ....
I maintain that not only is there a place for higher level languages - such as C - on the Prop, but that the Propeller is doomed to end up as a wonderfully engineered but obscure and underutilized curio without them. Let's face it - who's going set up a development team of 100 SPIN programmers to develop a new whiz-bang-internet-capable-fourth-generation-self-diagnosing-field-upgradeable-bluetooth-enabled waffle maker? (I mean, apart from the lunatics on this forum?)
But that's where most chips like this end up - billions and billions and BILLIONS of them.
To quote en.wikibooks.org/wiki/Embedded_Systems
Personally, I think the word "perhaps" in that quote is only there so the author doesn't have to nominate their sources. I would replace it with "unquestionably" but then some smart-alec would ask me to nominate my sources - so I won't.
Or to quote another chip maker - in this case National Semiconductor www.national.com/an/AN/AN-587.pdf
.... stepping down off soapbox ....
heater said PSIN and PASM is an optimal combination. I agree, from a technical perspective, but I think from a commercial perspective that C and PASM may be the combination that really makes the Propeller fly, and takes it to places that SPIN and PASM simply won't reach. And why is this so important? Why, so that Parallax makes more money on the Propeller I and we get the Propeller II sooner, of course!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
1. C compilers should not generate PASM code for LMM (or XMM) rather they should emit SPIN byte code to be run by the Props existing interpreter.
2. We should create a SPIN byte code interpreter that will execute SPIN byte codes from external RAM.
The reason for 1) is that compiling to LMM is always going to be wasteful of HUB RAM and never approach PASM speed. We have PASM for speed anyway. This brings us back to the meaning behind Holly's first question.
The reason for 2) is to allow for huge programs (by Prop standards) in external RAM. We now have multiple external RAM solutions either available or on the drawing board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Quite true, although the differences between C and SPIN are more substantial than is at first apparent (e.g. structures). And non-standard C would be worse than none at all. Extend C with library functions by all means - but keep the language intact or you are just shooting yourself in the foot - and that's what C++ was invented for!
I decided against going down this path because the loss of execution speed would have been too high (at least for me) - but it might be worth someone else revisiting it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Is it possible that compiling down to SPIN byte codes to be executed from external RAM could actually result in faster execution than compiling down to PASM instructions in external RAM ?
I'm thinking that SPIN byte codes fetched through the "key hole" of the byte wide access to external RAM that we currently have could be more efficient than fetching 32 bit long instructions. There are presumably byte codes for stack operations and such that could be more efficient than sequences of PASM that do the same thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You may be right - it is certainly worth investigating. I looked a this (very) briefly as well, but discarded the idea when I realized how many byte codes you'd have to add to the SPIN byte code set to support ANSI C. At that point I realized there was not much point in trying to maintain compatibility with SPIN - you'd only be able to support a partial subset of C if you did - and you'd probably be better off designing your own byte encoding. So I almost went down the Java route - but someone else was already working on that.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Out of interest can you give an example of a "missing" byte code operation that C might need ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Fairly obviously - anything to do with floating point. Less obviously, things like type conversions - SPIN has no data types for local variables. In some cases you could make up for these by combining multiple byte codes. But (just as a ludicrous example, which is probably not true) if it took four byte codes to convert a signed byte into an unsigned long, the final program would execute too slowly to be very useful - and would be as long as the quivalent PASM program in any case.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I cannot answer the question of speed for C to run from external memory.
However, I can say that the Interpreter could fetch the data (bytes) from external memory at least as fast, and maybe marginally faster, providing there are no latches (another gotcha)·from external memory as hub. However, any improvement would·be marginal since at a minimum, about 27 instructions are executed in pasm for each bytecode fetched/executed. In fact, I think 27 was my Interpreter and the rom interpreter was slower.
The next gotcha is that the external memory can only be accessed by 1 cog without overhead of collisions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Very useful info. I knew SPIN was quite slow, but I never had any actual numbers.
Of course, not all LMM instructions equate to one PASM instruction (although many do) - some of them are the LMM "meta" instructions that take multiple PASM instructions to execute within the Kernel. But even so, on these numbers I'd expect byte coded C to be around 10 times slower than LMM C executed from hub RAM - and maybe 3 to 4 times slower than LMM C executed from XMM RAM.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Floating point of course. I forgot all about it. In some decades now of programming embedded systems I've never had to use it.
Type conversions is not so obvious, as you say.
Clusso:
"Interpreter could fetch the data (bytes) from external memory at least as fast, and maybe marginally faster...from external memory as hub."
If that is true then there really should be an XMM Spin compiler/interpreter combo.
"The next gotcha is that the external memory can only be accessed by 1 cog without overhead of collisions."
Yes, but that is true of XMM C as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Of course you can only run 1 XMM C program. I just hadn't bothered to think about that because I am not a C programmer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Brad, mpark, pretty please...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
C lets you shoot yourself in the foot, however when you do that with C++ you blow your whole leg off [noparse]:)[/noparse]
@heater. I was just thinking about the XMM SPIN thing (no, I'm not planning it). I can't see many advantages aside from perhaps being able to use the hub as high speed RAM for video buffers or the like while running the actual spin code bytecode and storage from XMM. You'd need extra opcodes to determine what goes where, and there are a whole load of limitations with regard to pointers and addresses being 16 bit in the current system. On top of that you'd need local cache areas and bounce buffers in the HUB. I just can't see a point to it myself. You may as well write a new interpreter/compiler from scratch. If you look at it, XMM / LMM is really a kind of interpreter also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
That already sounds like a great advantage !
However if you have to add new opcodes and bend things around to get over 16 bit addresses, then we need a whole new interpreter. For sure it looks like to much of a mess of a solution.
Oh well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ask a simple question and let the floodgates open! As you can see, these are very knowledgeable and opinionated folks here.
And friendly to boot. Welcome. I like your illo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
"As you can see, these are very knowledgeable and opinionated folks here"
Yes indeed.
Lots of very smart guys here, I hope I'm smart enough to keep up
Does the designer of the propeller interact with users here on this forum?
@RossH
"you are just shooting yourself in the foot - and that's what C++ was invented for!"
hahahah
I like C...it's a very easy language to learn and use, but I have no use for C++.
Asm is the simplest way to program controllers because each step is so elementary....but it takes a long time to write a big program.
C is ideal for controllers since you can code so quickly... I usually code in C and add a bit of asm when I need max speed.
Ken
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup