Spin compiler?

Vampyr Noire

I do not know much about the process involved in developing a compiled language vs an interpreted language, but I just have a question out of curiosity. Why was Spin on the Propeller implemented to be interpreted by an assembly program running on the chip versus being implemented as a language that is compiled into assembly? I assume that if it were compiled, it would take far less of a performance hit than it does being interpreted. Are compiled languages significantly more complex to develop or something? I guess I am basically asking what the advantages are to spin being interpreted versus compiled since it is designed to run on a specific platform. In the non-embedded world of programming, interpreted languages are usually only used where portability to other platforms is a concern (at least that is my understanding, I am still in my infancy as a programmer). Is this not really the case with embedded programming? If someone has any insight into this I would be very interested in hearing your thoughts!

And out of fear of being misinterpreted, I am not complaining, just wondering. The developers of this device are FAR wiser than I am about these things

Thanks!
~Ken

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Paul Baker

One word: memory. Each cog only has enough memory to hold 496 instructions. Each high level command almost always results in multiple assembly instructions. This leads to exhausting the memory on a cog very quickly, only permiting very small programs to be made. By using an interpretor and it's asscoiated byte code, the byte code can exist in hub memory and can be many times larger in size.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10

Vampyr Noire

Very interesting point. I figured it had to do something with limited resource. Does this mean that the Spin interpreter is only 496 instructions or less though? It would seem impossible to implement something like that with so few instructions but again I don't know a lot about writing languages, I've only used them.

But anyways, if I understand correctly, the tradeoff is this:

-Compiled code offers higher performance at the cost of more memory consumption
-Interpreted code offers the abilty to do more with less memory consumption at the cost of lower performance

That about right? If so that suddenly makes the light go on in my head. It always seemed weird to me before that interpreted languages would be used in an embedded environment because all programming instructors I've ever had said that portability was the only real advantage to interpreted language. Of course, that outlook came from instructors who only programmed on computers, not embedded systems. Thanks for the eye-opener Paul!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Paul Baker

Yes the entire Spin language interpretor fits in the 496 instructions, Chip is a wiz at creating interpretors, he's the creator of the Stamp line.

Your assesment of the tradeoffs is essentially correct, it's a little more nuanced than that, but its not that important.

Interpretors on a full computer platform are ussually done for portability purposes, and back in the day it was done because it was faster than recompiling each time, but thats not much of an issue anymore.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10

Vampyr Noire

Wow...that's insane. Chip sounds like quite the genius, I've read a couple other things on these boards about things he has done.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

CHIPKEN

You have asked a question that I think needs to be address in regard to compiler vs interpretor code setups. I have never been totally satisfied with compilers mostly· because you don't know what's going on in the compiler when it·performs a·control program. Sometimes it appears that the control event is going around the world to get to the end and in some cases you may find other unplanned events are occuring (you call these small unknown bugs in the compiler). The interpretor is well defined and, I feel, a more reliable·setup for chip operation. This is the way the BASIC Stamp microcontroller is setup and it always works WELL. No one wants to do an interpretor chip because it takes more time to develop and the·programmers out there love C++ compilers·and their·baggage code. Keep the programming simple and an interpretor chip·will do the job with little problems.

Chuck