About the Spin interpreter in ROM

inaki

So the Spin interpreter itself is in mask ROM ?
I thought it was uploaded each time from the PC !
That would mean that even the minor change in the interpreter would require a new mask ROM ? :-(

Is not there a provision to replace the firmware interpreter with an 'external' updated version ?



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


Post Edited (inaki) : 4/10/2006 7:05:26 PM GMT

Paul Baker

this is a duplicate post, no the interpretor is in mask ROM and is permanent. Given the current capabilities of the Spin interpretor and the limitation of 512 instructions, there wouldn't be much likelyhood of an updated interpretor anyways. Though you could always write your own interpretor.

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

Post Edited (Paul Baker) : 4/10/2006 7:18:36 PM GMT

Phil Pilgrim (PhiPi)

The interpreter is actually a robust and throughly-debugged byte-code interpreter: in other words, a simulator for a virtual machine. Any changes to the Spin language itself can be accommodated by changing the PC-resident compiler, which produdes virtual machine code for the interpreter. The design of the ROM-resident interpreter doesn't need to change.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 4/11/2006 2:36:05 AM GMT

Jon Williams

This in fact was demonstrated by the PBASIC 2.0 to 2.5 "upgrade" -- the language got additions, but the interpreter stayed the same.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Bruce Bates

Jon -

In this context, how should one view the BS2-p changes to the I2C commands from V1.3 to V1.4 (I believe that's the proper nomenclature) where updates occurred in both the firmware (interpreter) and the IDE (PBASIC Editor)? Obviously this was a rare exception.

As I remember, this was where the WORD capability was added, but I stand to be corrected. It may have been some other change to the I2C address portion of the command.

The only reason I even mention this is that I had worked with PBASIC Stamps for nearly a decade when there was FINALLY a change which would require a firmware upgrade to incorporate it. I found that both incredible, and a real testament to the robust design of the PBASIC Stamp system in general.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

Jon Williams

I think there is a clear and obvious distinction between the BS2p 1.3 to 1.4 update and the PBASIC 2.0 to 2.5 update -- the first was a minor update for a target chip and affected one thing (I2C timing), the PBASIC 2.5 update (which is pertinent to this thread) is available to all BS2 Stamps, and included the the use of Word, as well as now "traditional" BASIC programming structures. To Phil's point, we were able to add the 2.5 features to the entire BS2 family without making changes to the firmware, the PBASIC compiler generated tokens that exist even in the original BS2.

The Propeller has a much smaller language in Spin, and Chip has been working with it and debugging it for over four years. Does that make it perfect? Probably not, but we feel confident it does what we say it will do, and it's flexible enough to extend to do what our customers are likely to want it to do.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Bruce Bates

Jon-

If you go back and read the ENTIRE thread, you will realize that BOTH are pertinant, especially to the original question, which questioned the "mask ROM". How one chooses to view it is certainly one's individual right and privledge.

Just to summarize, in almost all cases ONLY the IDE will need to have any changes or have updates made to it, but in rare and exceptional cases, the "mask ROM" may need to be changed. This rareness shows in the fact that while the PBASIC Stamp IDE may have reached Version 2.2.5 so far, and has been seen in a number of incantations, the PBASIC Stamp firmware revisons have never even reached 1.5 throughout the present LIFE of the PBASIC Stamp System.

That is quite a compliment and quite a feat where I come from, and something to be proud of! It's unfortunate you seem to feel differently. Stamps need no one to defend them, they do that very easily by themselves, and by their past history. Needless to say this is a direct and positive reflection on Chip specifically, and Parallax in general!

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

Jon Williams

I think Parallax has a lot to be proud of with the BASIC Stamp, a tribute to the amount of work Chip put into the original BS1 and BS2.· My point is that Spin is a much smaller language than PBASIC and is therefore less likely to require changes to the interpreter; the fact is Chip has spent a very long time on this because it is going to mask.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Paul Baker

Returning to a comment I made, there is nothing preventing someone from creating thier own customized Spin interpretor or interpretor for another language (PBASIC interpretor anyone?), you could even lift the ROM mask of the Spin interpretor as a basis for a new interpretor. Though given Chip's experience and skill, I don't think very many could improve on the existing Spin interpretor.

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

Tracy Allen

Bruce,
Notice that the BS2, BS2e and BS2sx are still on version 1.0. The upgrades to the later, SX based Stamps have had a few real bug fixes, having to do with timing in turbo mode and a couple of other things. Version 1.0 of the BS2p is not supported. Most of the later version changes had to do with support for advanced protocols like I2C and one-wire or even DTMF, which with respect to the first two of those at least are an evolving, moving target. Propeller makes no effort to support those protocols directly in the hardware. Those will be supported in PUBs that can adapt as need be. The Propeller is a lean and mean state machine.

That does not mean it was easy, far from it. Anyone who orders an inscription carved in stone better be careful that their spelling is right.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Kaos Kidd

Point well made and stated Tracy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Kevin Wood

How difficult would it be to port C to the Propeller? I'm not asking anybody to do it, but if it's possible, I wouldn't mind looking into myself.

Kaos Kidd

Please, someone correct me if I'm wrong...

#1: Unless Parallax places the "porting" into the "mask ROM" of the propeller, the ONLY languages the propeller chips will understand is propeller assembly (or more loosely refered to as machine code), and Spin basic.
#2: Yes, if there is a need for a "firmware" update, then the only way to achieve that is to replace the entire chip with a new chip.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Jon Williams

#1 While beyond my programming skills, I think it's possible for a programmer to create a compiler that will generate tokens compatible with the Spin interpreter (VM, if you will).

#2 Yes.· Please don't be nervous about this; Spin has been running in our office for over three years.· It's a fairly small language and Chip has spent a lot of time wringing everything out.· He designed the Propeller transistor-by-transistor and has really worked hard to make it safe for Parallax to invest in masking the interpreter.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Tom Walker

Hopefully without annoying any of the "purists"...

Creating a C compiler for the Propeller should not be any more difficult than creating one targeted for any other processor. I don't know of any advantage to creating a compiler that generates tokens, however. Going directly to machine code would seem the way to go. This would require a solid understanding of the Propeller's architecture, but should be a very doable task since the Propeller can run "assembly" code.

YMMV

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...

Jon Williams

The only issue with creating a C compiler that outputs Propeller assembly is that you're limited to the 2K cog RAM.· I suppose one could come up with a scheme to split a big program across multiple cogs.· Honestly, it seems like if one knows C one could learn Spin in about five minutes.· As I've said many times, it's a small language and just makes sense.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Martin Hebel

A benefit of a C compiler though would be a relatively easy to use language, and high speed as opposed to the simple, but interpreted, Spin. I think a C compiler would be very easy for those who do this sort of thing and provide yet another great, and conventional, programming route for the Propeller. Plus, you'd have the benefit of elimating the need for hub access in many cases to increase speed even more.

It's amazing what you can do with 2K in C is you stay away from heavy floating point math and heavy string use.

-Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Southern Illinois University Carbondale - Electronic Systems Technologies

Personal Links with plenty of BASIC Stamp info
StampPlot - Graphical Data Acquisition and Control

Kaos Kidd

Jon:
I'm quite comffie with the specs of the chip, ROM and all: I know Chip and all the folks at Parallax have done the best there is into the product.
I just can't wait until I get a chance a playing with it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Tom Walker

Jon:
I agree with you. Optimizing for 512 word chunks is not a task that I, personally, would want to undertake. I just wanted to point out that since he Propeller can run in a "native" machine mode, instead of being bound to a "token" interpreted world (in the realm of intellectual property), it "can" be done.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...

Jon Williams

And I sincerely hope that some clever program does create a C compiler for the Propeller.· While I'll always be content with Spin and working through Propeller assembly, I know that there are hoards of C devotes and it would be nice if that could use the Propeller with their favorite programming language.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Bill Henning

Guys, there are architectural issues with generating direct cog assembly code from C; and this is why Spin exists.

The spin/cog concept is a very clever way of hiding the fact that cogs local memory is·only long·addressable, and very limited in size, but hub memory is byte/word/long addressable. I'd be willing to bet that SPIN was designed at the same time as the hardware architecture; they go hand in hand, because otherwise writing larger code in spin assembly would be a pain in the posterior. Imagine manipulating strings when you had to go thru contortions to insert characters into a string! byte pointers are impossible to cog ram!

It would definitely be possible to write a C compiler that compiled to SPIN byte codes; just like it would be possible to target Pascal or Java to it (although Java is a bit heavy weight for 32k of hub memory). But it is fairly unlikely that such a compiler would produce much faster code than the spin compiler.

The cogs are just big enouch, with just enough local memory, to run a small VM for byte codes, or to emulate all sorts of neat hardware. For all intents and purposes, you can consider a propeller to be a "virtual" processor with virtual hardware.

Now, having said all that, it would also be quite possible to design a VM, with a minimal instruction set, that would efficiently execute C specific byte code out of hub memory.

I am not at all convinced that it would be any faster than SPIN, however without details of the SPIN VM and byte codes being made public, there would be no other choice for how to target a C compiler.

Mind you, the token threaded forth another forum member is writing could also be used as the "target" byte code for a C compiler!

If I had more time, I'd take up the challange of writing a C-code VM, but I've got too many projects on the go right now. (I've written small compilers and token threaded Forth interpreters before)