My take on C, PASM, Spin, etc

T Chap

I have no experience with micros beyond Spin (and a brief stint with a Stamp), so this is completely ignorant of reality. Zero C knowledge other than reading through the forum regarding the various issues with it.

My take is that the best use of programming time for a new tool would be to write a C and Spin app that allows a user to program in his preferred language(Spin or C), probably different apps for each, then press a button to convert that version of their program to PASM/Spin, or compile and run if the speeds and sizes were sufficient. In Spin or the Prop tool for example, ideally you would have a feature that converted your Spin functions(as desired) to PASM, and revealed the conversion, side by side would be nice. If programming in C, either compile and run as is, or port it to SPIN/PASM with side by side view for tweaking in PASM/Spin as needed.

This way, the argument for using old C libraries is handled, but without any costs that are inherent in C.

Post Edited (TChapman) : 4/5/2009 11:46:18 PM GMT

WNed

Having gotten a quick edumecation last night, I'll say that your use of the term "Spin/PASM" is incorrect, if you are thinking that one equals the other. While they are the two "native" Parallax languages for the Prop, in fact C is compiled down into PASM, and Spin is compiled down into bytecode, a set of codes that are, typically, one byte in length which is run by an interpreter that gets loaded into each Cog when it is started. The biggest controversy stems from the size and speed benefit of each. Spin bytecode is compact in size (nearly 1/4 the size of PASM, give or take), but the speed overhead of the interpreter makes it very slow. On the other hand, PASM/C operate much, much faster (compiled C is slower than straight PASM, but faster than Spin bytecode). Unfortunately, each PASM instruction takes at least 32 bits in memory as opposed to the typical 8 bits required by bytecode, so a program written in or compiled down to PASM may be nearly 4x bigger than an equivalent bytecode program.
So it's C/PASM vs. Spin - which one you choose will, as with any tool, will depend on the job and your comfort level with that tool.
As for the use of libraries, again, you have two seemingly opposing camps: C libraries people may have developed over time, and the Object Exchange objects. There are now at least two C compilers available for the Propeller, so C developers can start porting their libraries at any time. As I understand it, C on a microcontroller is by necessity less portable than general purpose computer C because of hardware intricacies, but the source can still be ported, and adapted to fit a particular uP. Unfortunately, if you want to program in C, you cannot take advantage of much of the array of objects already in the Obex, because there is no mechanism for, sort of, tacking Spin objects in. On the other hand, objects written entirely in PASM should be usable, with some tinkering, since Image Craft C (I don't know about Catalina C) is capable of assembling external PASM into a C program. Two ways you should be able to use PASM objects with ICC would be to edit the object to remove any reference to Spin, then save it as a ".s" file, which can be assembled into a C program, or second, (and you'd probably only want to do this with smaller objects...) you could open the object in an editor, then "copy and paste" it into your C source code using the ICC - asm("<string>"); functionality to use the PASM object as inline code within your source file. I have yet to actually try either method since I just realized you could use them while I was writing this, but I'll have a go at it this week.

...and that's what I learned this weekend!
Ned

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno

Post Edited (WNed) : 4/6/2009 2:18:38 AM GMT

jazzed

@Ned, Nice and concise assessment. Spin does use multi-byte bytecodes (think about all those long variables and word size pointers used for data), but as your understanding implies not much.

Added: @Ned in your expanded comments (now less concise) you left out my favorite way to use existing Spin / PASM ... just scrape the binary·into a C source array of longs and cognew it [noparse]:)[/noparse]

@TChapman, A proposed solution where a generic C to Spin translator is employed (rather than yet another compiler) would be provide a good environment for C and Spin coexistence although it would not do some of the wiz-bang stuff you mentioned. It took a while for C++ to be adopted for various reasons, but one reason it was adopted is that it allowed existing C libraries to be used as is ... which is very important to many (I suspect this is just an excuse mostly though because the best software engineers do a certain amount of re-write regardless of what managment wants). C# is also a success mainly because Java programmers can switch gears with zero sweat.

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


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Post Edited (jazzed) : 4/6/2009 2:06:23 AM GMT

T Chap

Yes Ned you have made great points. I am clear on the fact that C compiles to PASM with some extra baggage so to speak. What I was really trying to suggest was that C not really compile to PASM but rather convert to Spin/PASM where it could then be compiled natively. I am also suggesting that there be a process to convert Spin code to ASM pre-compile, in a side by side view manner, if such a thing is doable. My memory may not be clear but it seems there was something similar on the SX programming tool, where you could write in basic, but see the ASM result as well as edit the ASM result pre-compile. I may be off on this recollection. I do recall that the SXSim will show the ASM result and allow editing in advance of programming the chip, this is the concept I am speaking of, only the form of C>Spin>PASM or Spin>PASM.

In other words, write in C, convert to PASM, compile, or write in Spin, convert methods that could make use of ASM speeds, then compile.

Post Edited (TChapman) : 4/6/2009 2:18:31 AM GMT

RossH

Hi Ned,

Nice summary. Just to let you know, you can use SPIN/PASM obects unmodified in Catalina if they do not require VAR space at run time (using VAR space only during initialization is ok). You just add them into to a customized target file.

To incorporate low level PASM code, there is no need to use the platform-dependent 'asm' function - 'asm' is a convenient extension fo C offered by many compilers, but is it not part of ANSI C and is not supported in Catalina. However, it is not really necessary - you can always achieve the same result by linking your C program with a separate module written in assembly language, but this can be technically challenging with some C compilers. However, it is quite simple with Catalina because Catalina binds at the source level - so you can just include PASM code that will be bound and assembled along with your C code - Catalina even provides a 'dummy' file in each target intended for you to do exactly that.

Ross.

ImageCraft

"There is too much confusion..."

ImageCraqft C compiles C to assembly, which is then assembled and linked, so the users also have the option to write in LMM PASM. "Native" PASM must be cognew'ed. A bit confusing but we must support the target that is given to us, not the target that we wish to have, to misquote certain ex-US official.