the merits of using SPIN vs. translating existing objects TO SPIN

Ari

as a general topic of question....

how would YOU (opinions welcome) describe the merits of

1. translating existing objects to SPIN (using a automated translator) and then correcting possible errors
2. simply rewriting your object base (library) in SPIN from the get go

which do you believe would require less effort, time and/or frustration?


let's assume the OBEX doesn't exist.....and that you have a large number of objects in your possession....in your existing language of choice....


this is an open ended topic, and I have no qualms with the nature of the topic shifting/evolving

after all this is one approach to a problem, and possibly not the most efficient....so alternate scenarios are encouraged and welcome....

also please excuse any logical errors due to my ignorance of SPIN/propeller....I am neophyte to this community and the prop (not StaMp though)....but am well versed in other engineering disciplines

thank you

:nerd::cool:

ctwardell

It seems to me to depend on the original target of the existing objects, the Prop is unlike (for the most part) any other MCU from a hardware point of view. If the existing objects are dependent on hardware items such as UARTS, I2C, SPI, Timers, PWM, etc. then the prop code not only needs to handle the code making use of those objects, but has to emulate the hardware items as well.

Here are some of the issues that I see off the top of my head:

1) Most hardware peripherals present in other MCU's must be emulated.
2) Most "other" MCU's make fairly extensive use of interrupts to handle interaction with peripherals, the Prop does not support interrupts.
3) The "memory map" of the Prop is typically very different than that of other MCU's

That said, I think that even if a fairly direct translation could be made it would miss out on the very things that make the prop, well, the prop.

C.W.

localroger

Ari, I'm not quite sure what you're getting at here. Many of the most important objects in the OBEX, such as the TV, VGA and serial drivers, depend intimately on PASM for accurate high-speed timing. If those objects weren't available, there's nothing in the world you could even use as a basis to start a translation from some other language. You might have bit-banging UART code from another CPU, but you won't be able to automatically translate it; the other CPU will probably have an interrupt system and support inline assembly language, where the Propeller requires you to have standalone PASM assistants that hand off data to Spin code by dropping it in Hub RAM.

Spin was designed as a teaching language, and some of its more annoying features, such as using indentation as syntax, are meant to force you to learn to do things right so that they will work. Spin is also designed to be very compact so that you can get much more code into 32K of Hub RAM than you could of, for example, compiled x86 object code. The Spin expression evaluator is more powerful than any other I've ever used, and I've used a lot of programming languages in the last 30 years. But in some ways it's also a total rethinking of how such things should work, and stuff that works in Spin isn't possible in other languages and a lot of stuff that is done in other languages could be done much more efficiently in Spin if you rethink how it's done. That's the kind of optimization a translator can't do; Spin is meant to be written by humans so that the humans will learn how the computer works.

I once wrote a full interrupt-driven bit-banging serial driver for the Intel 8051 for A Controller Which Shall Remain Unnamed. I used it for years. It was written in 8051 assembly language and communicated with the 8051's BASIC via a Propeller-like dropping of variables into shared RAM. That code was essentially the 8051 equivalent of fullduplexserial. And the chance of "porting" that code via an automatic translator to the Propeller would be just about exactly zero. Both the 8051 and Propeller have complex non-CPU resource such as counters and timers and bears, oh my, but they're completely different so the tricks that work with one are meaningless to the other. You might use the 8051 code to achieve an understanding of what needs to be done, but in the end you will be writing new code that exploits the Propeller's architecture. And Watson notwithstanding, computers themselves aren't anywhere near being able to do that without human help yet.

Ari

excellent, this addresses some concerns of mine (both replies).....so in the event that a translation was available...it would be much more troublesome to sift through and correct assumptions (or emulate, which i would never attempt to do).....

so for example....with a PIC xyz (and movable jumpers) you could easily port the code from any language base available to any other (oo)....and then with jumper reassignment you could simply flip incorrect pin designations in the physical topology (rather than correct all associated strings in the logical topology)

OUCH!!!!

kudos to the future race that invents the "smart logical translator".....I suppose that is the point where programming will be marginalized to the extent that physical engineering has today....double OUCH!!!

I think I'll go peel me a grape

Mike G

Hope I don't get blasted for this but I write a lot of my code in C. Not all the code just pieces. The debugging tools are better and for some reason I can write C faster with less errors than SPIN. Translating from C to SPIN is generally pretty straight forward.

Ari

Mike G wrote: »

Hope I don't get blasted for this but I write a lot of my code in C. Not all the code just pieces. The debugging tools are better and for some reason I can write C faster with less errors than SPIN. Translating from C to SPIN is generally pretty straight forward.

hardware topological issue non-withstanding....or are we talking C code in relation to SPIN code in relation to prop.....

what I mean is the hardware is consistent across this entire method?

Mike G

Like I said just small snippets of code. Mostly related to processing information in memory. Then I'll move the SPIN code to PASM. I could be weird but... it works for me.

Ari

Mike G wrote: »

Like I said just snippets of code. Mostly related to processing information in memory. Then I'll move the SPIN code to PASM. I could be weird but... it works for me.

gotcha....

jazzed

Mike G wrote: »

... and for some reason I can write C faster with less errors than SPIN.

Using Spin often makes my C programming skills suffer.
Using C often makes my Spin programming skills suffer.
Reading the Propeller forum too much impacts everything

Mike G wrote: »

Translating from C to SPIN is generally pretty straight forward.

Dave Hein wrote a C to Spin translator.

Mike G

jazzed wrote:

Using Spin often makes my C programming skills suffer.
Using C often makes my Spin programming skills suffer.
Reading the Propeller forum too much impacts everything

lol;

Dave Hein

Ari,

cspin would help to translate existing C code to Spin. It does have a lot of deficiencies, but it will work with simple C programs. Part of the problem with translating C to Spin is where Spin has similar functionality, but not exactly the same. An expression like "if (x && y++)" is not the same as "if x and y++" in Spin because the "y++" will be conditionally executed in C, but not in Spin. Of course, the C code could be implemented in Spin with extra "if" statements, but then it doesn't look like the original C code, and it may not be as efficient.

I'm starting to think what we really need is a C compiler that generates Spin bytecodes directly without generating an intermediate Spin language file. This would provide all the power of the C language, but still have the compactness of Spin bytecodes. If we had a C compiler like that I would probably not use Spin much anymore. The C compiler would need to have a Spin compatibility mode so that it could link to Spin objects from the OBEX.

Dave

Ari

Dave Hein wrote: »

Ari,

cspin would help to translate existing C code to Spin. It does have a lot of deficiencies, but it will work with simple C programs. Part of the problem with translating C to Spin is where Spin has similar functionality, but not exactly the same. An expression like "if (x && y++)" is not the same as "if x and y++" in Spin because the "y++" will be conditionally executed in C, but not in Spin. Of course, the C code could be implemented in Spin with extra "if" statements, but then it doesn't look like the original C code, and it may not be as efficient.

I'm starting to think what we really need is a C compiler that generates Spin bytecodes directly without generating an intermediate Spin language file. This would provide all the power of the C language, but still have the compactness of Spin bytecodes. If we had a C compiler like that I would probably not use Spin much anymore. The C compiler would need to have a Spin compatibility mode so that it could link to Spin objects from the OBEX.

Dave

yes I can see where the contextual problems would lay / lie....since languages are so character dependent (and in some cases formatting dependent)...

funny thing is I thought all along that is what a translator did was binary reorganization....I did not realize how limited it was....

what is to stop a program from being "smart" and correcting syntax and then simply spitting out low level information? please excuse my over simplistic notions about this....but that seems the most logical....why not just reach down to the lowest level from the get go....why implement intermediary process? aside from the mathematical implications I just described

Mike Green

It's simpler often to let an existing compiler do a lot of the work like doing type checking, allocating storage for variables, generating code for various structures, etc. When translating C to Spin, you can let Spin keep track of what's bytes / words / longs. You just have to pass the right word along. Since most of the operators are the same except for slight differences, you can pass expressions mostly unchanged to Spin. To put out Spin bytecodes, you need the whole compiler. For example, there are short forms of many of the operations. Common small constants and short relative jumps are encoded in very compact bytecodes. If you're producing Spin source, you don't have to deal with these.

Ari

so really we are making things more complex by not just adopting SPIN, since everything else will just be an intermediary with syntax errors....along thew way to PASM

SPIN really isn't the problem, it's the interpreter....and there is no way around that....and furthermore, why would you want to do away with it, it's purposely designed to help us....

It's really becoming painfully obvious to me that my complaints about SPIN are really complaints about my own failures to think outside of the box....

potatohead

Even then, you've got choices with that interpreter. It can be loaded into the HUB, and there is at least one modified version of it that runs faster than the "in the box" ROM version. Some other versions allow for other fancy things, like in-line PASM, or some other special things, and they do it by removing something rarely used from the original image, or making that thing slower with LMM or something.

It's not like you have to use the one in the chip. It just costs the least.