I'm a C programmer, but most of what I've done on the Prop has been in Spin with some PASM. I have tried the Catalina compiler, and it worked OK for the few test programs that I wrote. If I had to choose between the Catalina compiler or the Imagecraft compiler I would go with Catalina -- mostly because it's free.
My biggest concern with C on the Prop is the lack of interest shown by Parallax. It will be hard to draw in more C programmers to use the Prop unless Parallax shows that they will support C. Parallax started a thread about 6 months ago where they discussed the possibility of developing a limited C to Spin converter. After the discussion they held an internal meeting and generated a long list of prioritized tasks, with the C converter at the end. This implies that they have very little interest in supporting C.
a) when will Prop II happen?
b) after a), how long will it take for the RAM to be insufficient again?
@Ross:
Puliiiiize! I want binary constants. '0b0010' for example. The compiler says: "Is a preprocessing constant (so does recognize it?) but invalid integer constant".
They are very handy when programming µC, albeit not part of the standard (C99, C89).
Nick
Write your own preprocessor (I'd use m4) to convert those strings to standard C and run the code through that before compiling it.
It may be that C is still not a viable language for the Propeller even with Prop II.
I suppose it's bad form to comment on my own post but I think I misspoke when I made my original post. I didn't really mean to say "C is not a viable language for the Propeller". What I meant to say is "C is not an optimal language for the Propeller". In fact, I have more than a dozen Propeller chips, some on boards and some waiting to be built into projects. I think it is a very interesting chip and am planning to do a lot more with it including using it to run C code. However, it isn't its ability to run C that really interests me. It's the unique architecture and the multiple CPU cores that make it interesting to me. I'll use C so that I can use code I've written before and also so I can reuse some of the code I write for the Propeller in other possibly non-Propeller projects. That's why I want C even if it isn't optimal in performance or space utilization. As has been said many times before, C is the universal assembly language.
I suppose it's bad form to comment on my own post but I think I misspoke when I made my original post. I didn't really mean to say "C is not a viable language for the Propeller". What I meant to say is "C is not an optimal language for the Propeller". In fact, I have more than a dozen Propeller chips, some on boards and some waiting to be built into projects. I think it is a very interesting chip and am planning to do a lot more with it including using it to run C code. However, it isn't its ability to run C that really interests me. It's the unique architecture and the multiple CPU cores that make it interesting to me. I'll use C so that I can use code I've written before and also so I can reuse some of the code I write for the Propeller in other possibly non-Propeller projects. That's why I want C even if it isn't optimal in performance or space utilization. As has been said many times before, C is the universal assembly language.
I agree with everything you said, David. Even I don't claim that C is "optimal" on the Prop (well, not too often!). But it's good to have it available for those of us who much prefer it to the alternatives.
The main disadvantages of C on the Propeller are well known, and have been discussed endlessly - i.e. it's slower than PASM, and C programs are larger than SPIN programs. But in many cases this is more than compensated for by the advantages of C - i.e. it's much faster than SPIN, and you can write much larger and more complex programs than you can in PASM. Plus the fact that - as you point out - you often don't need to write them at all since they may already exist (in whole or part).
But there is presently another drawback of C - one which also affects SPIN as well as all the other high level languages on the Propeller. This is that it is not easy to take advantage of all the unique facilities the Prop has to offer - which after all is why we all get drawn to the Prop in the first place! Currently, PASM is the only practical language for this. SPIN can do a bit, but is generally too slow - which is why so much code still ends up being written in PASM.
My aim with Catalina is to make a high level language that is functional enough and fast enough to allow all the fascinating features of the Prop to be explored easily - without having to resort to PASM (or at least not very often). It's come some way towards this - and the forthcoming release will take it a bit further still. Of course it still has a fair way to go, but I think that an implementation of C based on LMM PASM (as both ICC and Catalina are) is the right approach.
To bring the thread (in a very longwinded way) back to the original topic, I think this is why Catalina is the best alternative for someone who wants to use C on the Propeller - despite all Catalina's rough edges and flaws. Zog may eventually be a useful C toolchain if all you really want is C - but in that case then you probably should be using a different microprocessor than the Propeller (sorry Heater!).
@Ross:
Puliiiiize! I want binary constants. '0b0010' for example. The compiler says: "Is a preprocessing constant (so does recognize it?) but invalid integer constant".
They are very handy when programming µC, albeit not part of the standard (C99, C89).
Nick
I try to resist non-ANSI extensions - not only because it's hard (it requires changing too much of LCC code) but also because it encourages non-portable programming. But google turns up this:
/* Binary constant generator macro
By Tom Torfs - donated to the public domain
*/
/* All macro's evaluate to compile-time constants */
/* *** helper macros *** /
/* turn a numeric literal into a hex constant
(avoids problems with leading zeroes)
8-bit constants max value 0x11111111, always fits in unsigned long
*/
#define HEX__(n) 0x##n##LU
/* 8-bit conversion function */
#define B8__(x) ((x&0x0000000FLU)?1:0) \
+((x&0x000000F0LU)?2:0) \
+((x&0x00000F00LU)?4:0) \
+((x&0x0000F000LU)?8:0) \
+((x&0x000F0000LU)?16:0) \
+((x&0x00F00000LU)?32:0) \
+((x&0x0F000000LU)?64:0) \
+((x&0xF0000000LU)?128:0)
/* *** user macros *** /
/* for upto 8-bit binary constants */
#define B8(d) ((unsigned char)B8__(HEX__(d)))
/* for upto 16-bit binary constants, MSB first */
#define B16(dmsb,dlsb) (((unsigned short)B8(dmsb)<<8) \
+ B8(dlsb))
/* for upto 32-bit binary constants, MSB first */
#define B32(dmsb,db2,db3,dlsb) (((unsigned long)B8(dmsb)<<24) \
+ ((unsigned long)B8(db2)<<16) \
+ ((unsigned long)B8(db3)<<8) \
+ B8(dlsb))
Ross. look at lex.c, just duplicate the code for octal handling and make 2 or 3 simple obvious mods. You should add a flag to handle extension, but it's up to you.
I will send you the mods but a) it's really simple, and b) I spent mucho $$ and energy to develop ICC Prop and all I got was kick in the pants, so you can have all the glories.
When Prop II takes off, we will take a look then. Until then, it's AVR, M8C and Cortex M for us. Heck, I even just finished off the XGate support for the CPU12 and some 430X support for the MSP430 even though it only benefits a small number of users, but we do take care of our customers. It's not a lot of fun when you work until 4AM in the mornings every day to get blasted in a public forum.
It's not a lot of fun when you work until 4AM in the mornings every day to get blasted in a public forum.
The problem is neither that Parallax forumistas are unappreciative (we aren't), nor that you have a bad product (you don't). The problem is, rather, that it's C. For the Propeller. AND that a pure software play -- for profit -- will always be a hard sell amongst a crowd of independent-thinking iconoclasts, which pretty much defines the Propeller crowd. -- at least those who hang out here.
I have a feeling that bringing traditional programming tools to Prop users will always be a bigger challenge than bringing Prop users to less conventional tools like Spin and PASM.
Ross. look at lex.c, just duplicate the code for octal handling and make 2 or 3 simple obvious mods. You should add a flag to handle extension, but it's up to you.
I will send you the mods but a) it's really simple, and b) I spent mucho $$ and energy to develop ICC Prop and all I got was kick in the pants, so you can have all the glories.
When Prop II takes off, we will take a look then. Until then, it's AVR, M8C and Cortex M for us. Heck, I even just finished off the XGate support for the CPU12 and some 430X support for the MSP430 even though it only benefits a small number of users, but we do take care of our customers. It's not a lot of fun when you work until 4AM in the mornings every day to get blasted in a public forum.
Hi Richard,
Thanks for the tip - I'll look into it and see if I want to go down that path.
I'm in the fortunate position of doing this just because I like learning how it's done - I don't have to make a living at it (which is just as well - if I had to depend on Catalina to earn even beer money I would have had to give it up long ago).
I sympathise with you about how unappreciated C seems to be in the Parallax forums. We've had lots of discussions about it, but I still don't really understand it. The topic would never even arise in conjunction any other micro - it would just be understood that of course you can offer other languages, but you absolutely must offer an industrial grade C compiler. Paid ones with full support, as well as freebies.
Maybe the Prop II will be a game changer for Parallax. Or maybe not.
Puliiiiize! I want binary constants. '0b0010' for example.
Puliiiiize! No.
I understand your desire for convenience here and one can always think of nice features to add to any programming language. But at the end of the day having a standard to work to is of greater value. What happens when I take a module using such non-standard extensions and try to compile it to run on my PC for testing?
My biggest concern with C on the Prop is the lack of interest shown by Parallax. It will be hard to draw in more C programmers to use the Prop unless Parallax shows that they will support C.
No. C does not need the support of Parallax.
Consider this:
The Propeller is not suited to C.
Parallax has better things to use their resources on. Like the Prop II for example.
C was developed by users (AT&T Bell Labs) of a PDP-7 with out any help from the Digital Equipment Corporation.
Everyone uses C on their Intel based PCs every day. But how much of that is using the Intel C compiler? (Also called "ICC" by the way) In fact Intel processors were around for a long time before any C from Intel.
C already has plenty of support from RossH and ImageCraft.
If C users want C on a processor it will be. Regardless of what the chip vendor does. If C on the Prop made any sense there would be hoards of users using it and clamouring for support. ImageCraft would have the incentive to move it along.
Zog may eventually be a useful C toolchain if all you really want is C - but in that case then you probably should be using a different microprocessor than the Propeller (sorry Heater!).
No apologies required.
I agree, if one wants to run a lot of C code efficiently one does not want to look at the Prop. However I'm not sure why you single out Zog here. Same applies to Catalina and ICC.
Which brings me to my current "dream processor".
What we want is a micro-controller for our gadgets. We want lot's of I/O, we want timers, we want video, we want all those cores and their deterministic execution timing.
But hey, whilst we are using all that we find we have too much of a program to fit, or we'd like to reuse C code or just use C because that's what we use.
So the "dream processor" is a Propeller and something like an ARM core on the same chip. The ARM gets its memory from piles of external SDRAM/FLASH and runs at some hundreds of megahertz like the one in my mobile phone. Needless to say it runs Linux, perhaps Android.
Given the constraints on die space of the Prop II I'm sure an ARM would not fit. But...
How about deleting one COG and replacing it with a ZPU?
The ZPU probably uses less logic than a COG and would fit nicely.
The loss of a COG would not hurt as their is generally one used for some top level Spin code anyway. Might as well be a full up processor running C.
I agree, if one wants to run a lot of C code efficiently one does not want to look at the Prop. However I'm not sure why you single out Zog here. Same applies to Catalina and ICC.
While I agree that none of them are particularly efficient implementations of C - I do differentiate Zog from Catalina and ICC - because the former generates instructions for an emulated processor (and a processor with a completely different architecture to a Propeller cog) while the latter essentially generate PASM (after all, 80% of LMM PASM is just PASM being executed from Hub RAM rather than cog RAM).
Both Catalina and ICC are quite "close" to being true native compilers - they are in fact both pretty much as close as is possible on the Propeller (a true compiler would generate PASM and not LMM PASM - but it would also be limited to 496 instructions and would therefore not be a lot of use).
To illustrate why this is important, consider the multithreading additions I have made to Catalina - they are implemented in a way that is quite "natural" for the Prop - and also quite efficient. I have not had to modify the kernel much since everything that was needed can be quite efficiently expressed in LMM PASM (although I do push some of this into the kernel for efficiency reasons). But you can't do this in native ZPU, since native ZPU doesn't give you access to the special features of the Propeller. You could modify the ZPU instruction set to add some Propeller-specific primitives, but this would also require you to modify the GNU code generator - whereas I have not had to modify Catalina's code generator at all.
With Zog you would probably be tempted to instead compile a Linux version of the pthreads library and leave it at that - but this would be quite a "heavy" solution, and also not very sympathetic to the Propeller way of doing things.
This is not intended to be a criticism of Zog - it is just a difference between the way you tend to do things in Zog versus the way you would tend to do them in Catalina (or ICC).
What happens when I take a module using such non-standard extensions and try to compile it to run on my PC for testing?
You'll discover that many compilers do have this feature. gcc, Keil, Microchips' C32, ... Especially when working with micro controllers.
It doesn't break anything, it just adds.
But I can add that by compiling my own version.
not only because it's hard (it requires changing too much of LCC code)
That should be just a very localized addition in the tokenizer.
"0x...", "0b..."
The main disadvantages of C on the Propeller are well known, and have been discussed endlessly - i.e. it's slower than PASM, and C programs are larger than SPIN programs.
That is not a problem of C, but its implementation. SPIN is smaller than C (with the two existing implementations for the Prop) because SPIN generates code for a virtual machine ("P-code"). If such a C-compiler would exist for the Prop, you'd have almost the same advantages and disadvantages.
I imagine, that a C-compiler could be built that generates SPIN byte-code. But I won't proof.
That is not a problem of C, but its implementation. SPIN is smaller than C (with the two existing implementations for the Prop) because SPIN generates code for a virtual machine ("P-code"). If such a C-compiler would exist for the Prop, you'd have almost the same advantages and disadvantages.
I imagine, that a C-compiler could be built that generates SPIN byte-code. But I won't proof.
A C compiler that generates SPIN byte codes could be built - this has been proposed before. But SPIN is already many times slower than LMM C, and C that had to be implemented using only SPIN bytecodes would be several times slower still. This is because the SPIN bytecodes are intended (naturally enough) to map efficiently to SPIN language elements - they do not map particularly efficiently to C language elements. C is a "bigger" language than SPIN, with low level features (types, arrays, bit fields etc) that SPIN doesn't have.
While a C that runs that slow might find some applications, it would be fairly limited. I want a C that can concievably compete with PASM, not one that would struggle even to compete with SPIN. As David Betz pointed out - C is the nearest thing we have to a universal assembler. If that's not the case (and it's already marginal with LMM C), then the case for C at all is a bit thin.
"LMM PASM is just PASM being executed from Hub RAM rather than cog RAM".
Strictly LMM PASM is not being executed from HUB RAM any more than my PC is executing instructions from it's hard drive.
Nick Mueller:
If such a C-compiler would exist for the Prop, you'd have almost the same advantages and disadvantages.
Such a C compilers does exist, its GCC for the ZPU bytecodes. Interpreted by Zog on the Prop.
And yes, it has the same disadvantages as Spin.
I suspect compiling C to Spin byte codes is not going to work very well. But I also have a suspicion that a better byte code could be defined for C. I can't imagine anyone is up for that task though.
...
I suspect compiling C to Spin byte codes is not going to work very well. But I also have a suspicion that a better byte code could be defined for C. I can't imagine anyone is up for that task though.
I think compiling C to Spin byte codes would have the same performance as compiling Spin to Spin byte codes as long as the C code uses the same data types -- unsigned char, unsigned short and int. Using signed char, signed short or unsigned int will generate extra operations, and it will be slightly less efficient.
The Spin interpreter could be modified slightly to improve C performance by using a few temporary registers instead of forcing everything to go in and out of the stack. It's also feasible to compile C to SpinLMM, which would provide the best of Spin bytecodes and LMM Pasm. A pragma could be used to force the compiler to use Spin bytecodes, LMM Pasm or even pure Pasm for different sections of the code.
Of course, this is all academic without support from Parallax. If Parallax was to support a C development system it would bring in more C developers, and it would improve their market share. Without Parallax support, C will just play a minor role in software developement for the Prop.
Such a C compilers does exist, its GCC for the ZPU bytecodes. Interpreted by Zog on the Prop.
And yes, it has the same disadvantages as Spin.
I suspect compiling C to Spin byte codes is not going to work very well. But I also have a suspicion that a better byte code could be defined for C. I can't imagine anyone is up for that task though.
Is the Spin VM a stack machine or a register machine? It seems like a register machine would perform better since it wouldn't always have to go to hub memory to fetch operands. I guess you could cache the top few entries on the stack in COG RAM but that would complicate the VM implementation. Does ZOG do this?
The Spin interpreter is stack based according to what I have read around here. I guess it is not a register machine or using a cache in COG because it only just fits in COG as it is.
The ZPU is stack based, probably for similar reasons, although in this case it is to minimize logic block usage in an FPGA rather than COG registers.
The Zog interpreter only caches the top of stack value in a COG register (tos).
So for example a ZPU ADD operation does not do a sequence like:
POP x
POP y
ADD x, y
PUSH x
Which is 3 trips to the stack memory, but rather:
zpu_add call #pop
add tos, data
jmp #done_and_inc_pc
Which is only one stack read.
All this was inspired by Bill Henning who also convinced me that trying to cache any more stack in COG would consume more cycles than it saves. Which is just as well as managing to getting this right was enough for me.
There is one use case where Zog ought to be able to give Catalina and ICC a bit of competition in the speed stakes.
That is to have the byte codes out in external memory with stack and data in HUB. This has the advantage over LMM solutions in not needing to fetch 4 bytes for every instruction.
Really must get down to understanding those linker scripts:)
Such a C compilers does exist, its GCC for the ZPU bytecodes. Interpreted by Zog on the Prop.
That is even worse than a p-machine.
You are interpreting code that was not designed to be compact.
I asume you know what p-code, p-machine and UCSD-Pascal is.
Both Catalina and ICC are quite "close" to being true native compilers - they are in fact both pretty much as close as is possible on the Propeller (a true compiler would generate PASM and not LMM PASM - but it would also be limited to 496 instructions and would therefore not be a lot of use).
Both are not close enough. 496 instructions are surely not much, but you can do a lot of things with it.
PropBASIC for example does exactly what I would expect from an "compiler" for the prop: A few register for function parameters (all longs), a few extra definitions for the special features of the propeller (coginit, HUB memory access...), and a description of the limitations of the compiler. End of story.
A C compiler that generates SPIN byte codes would be an addon, only necessary because of the small memory of the prop.
BTW. Im not really enthusiastic about propII. 256kb is better then 32 but really not enough if you want do a graphic-user-interface. Let`s talk about 512.
The other way is what imagecraft did: LMM + fcache.
But they did it bad. As a programmer I want to have the possibility to decide what goes in the fcache. An automatic is not enough. Especially if it is not well documented and not predictable. And the fcache has to be big enough (let`s say about 100 instructions).
LMM in my opinion is compromise. And not a good one. What you get is maybe fully bloated C, but with the big disadvantage of slowness without the advantage of spin (saving memory).
Quote:
What happens when I take a module using such non-standard extensions and try to compile it to run on my PC for testing?
You'll discover that many compilers do have this feature. gcc, Keil, Microchips' C32, ... Especially when working with micro controllers.
It doesn't break anything, it just adds.
But I can add that by compiling my own version.
Non-standard extensions in in C compiler for microcontroller are not a exception. It`s because every microcontroller has its special features.
Somthing like that is very common,
#if (PIC == TRUE)
do this
#elif (M16 == TRUE)
do that
#else
make it this way
#endif
if you have same files for different microcontrollers.
...As has been said many times before, C is the universal assembly language.
Exactly. Nothing more. C is not linux, nor printf or something else. It`s there that I have not to learn 10 different assembly dialects. I have one language for all my microcontrollers and I can use programming examples from others (e.g. for an external hardware).
You are interpreting code that was not designed to be compact.
Actually compact code is somewhere in the ZPU design requirements. After all if you are minimizing space usage in an FPGA that includes trying to keep the use of RAM blocks down.
Zylin seem quite pleased with ZPU code density claiming "Codesize 80% of ARM thumb".
Zylin are now looking at targeting LLVM at the ZPU with a view to shrinking code an increasing performance.
p-code, p-machine and UCSD-Pascal
Ah yes, had a Tiny Pascal p-code system for a TRS-80 back in the day. And I have wondered about a Pascal/p-code machine for the Prop. However it looks like a p-code interpreter won't fit in a COG. At least from cursory view of this one: http://homepages.cwi.nl/~steven/pascal/book/10pcode.html
Both are not close enough. 496 instructions are surely not much, but you can do a lot of things with it.
PropBASIC for example does exactly what I would expect from an "compiler" for the prop: A few register for function parameters (all longs), a few extra definitions for the special features of the propeller (coginit, HUB memory access...), and a description of the limitations of the compiler. End of story.
The other way is what imagecraft did: LMM + fcache.
But they did it bad. As a programmer I want to have the possibility to decide what goes in the fcache. An automatic is not enough. Especially if it is not well documented and not predictable. And the fcache has to be big enough (let`s say about 100 instructions).
LMM in my opinion is compromise. And not a good one. What you get is maybe fully bloated C, but with the big disadvantage of slowness without the advantage of spin (saving memory).
I don't want to hijack this thread, but I wanted to point out that PropBasic allows you to mix both native and LMM code very easily by just adding "LMM" to the code header (PROGRAM or TASK).
PropBasic generated pretty tight PASM code, so yes you CAN do quite a bit in 496 instructions.
I don't use C, but being able to generate both native and LMM code would be pretty high on my list of features for any compiled language for the propeller.
Native code is needed for video drivers and such, and LMM for the "meat" of the program that could be quite large.
Again I know very little about C, so I don't mean to cast stones.
A big problem with PropBasic or C (or any other language for the propeller) is that interfacing with spin is not easy or seemless. This makes much of the OBEX useless for other language users.
A big problem with PropBasic or C (or any other language for the propeller) is that interfacing with spin is not easy or seemless. This makes much of the OBEX useless for other language users.
I plugged TV_Text_Half_Height.spin as a character device into ZOG this week with very little effort. Interfacing with it as a block/memory device will take a little more work. I also plugged in my TwiKeyboard.spin painlessly yesterday.
ZOG makes many things possible because ZOG can use Spin to add objects.
Actually compact code is somewhere in the ZPU design requirements. After all if you are minimizing space usage in an FPGA that includes trying to keep the use of RAM blocks down.
Naa, the p-machine was really compact. The op-codes (like div mul add etc) worked on chars, ints, floats, pointers, ... and knew how to treat them properly. On the Apple ][ you could write really huge programs (but maybe my definition of "huge" changed over time :smhair:) with 64k. But the p-code interpreter wouldn't fit inside a cog (I guess).
I doubt I still have the book "Inside the p-machine". Don't remember the title that well, just the cover showing an old couple in front of a tree.
I don't want to hijack this thread, but I wanted to point out that PropBasic allows you to mix both native and LMM code very easily by just adding "LMM" to the code header (PROGRAM or TASK).
PropBasic generated pretty tight PASM code, so yes you CAN do quite a bit in 496 instructions.
I don't use C, but being able to generate both native and LMM code would be pretty high on my list of features for any compiled language for the propeller.
Native code is needed for video drivers and such, and LMM for the "meat" of the program that could be quite large.
Again I know very little about C, so I don't mean to cast stones.
A big problem with PropBasic or C (or any other language for the propeller) is that interfacing with spin is not easy or seemless. This makes much of the OBEX useless for other language users.
Bean
Hi Bean,
I wouldn't worry about hijacking the thread - or casting stones either. Us non-SPIN Propeller users soon develop thick skins, or we don't last long
I'm doing some thinking about how to integrate SPIN with Catalina C - but I've not come up with anything worthwhile yet. SPIN was not really designed with such integration in mind (and nor was Catalina!).
A big problem with PropBasic or C (or any other language for the propeller) is that interfacing with spin is not easy or seemless. This makes much of the OBEX useless for other language users.
Bean
This is a big problem, because without sample Obex codes, I can't use PropBasic or C.
Why can't Spin run in one cog while PropBasic or C run in another cog?
Why can't Spin run in one cog while PropBasic or C run in another cog?
It can. When running C programs under Zog the initial start up spin code continues to run. One can therefore add to ones application in C or Spin.
I started on a loader for Zog that completely removes any Spin from the Prop leaving most of the 32K HUB free for C. There does not seem to be much call for this.
It can. When running C programs under Zog the initial start up spin code continues to run. One can therefore add to ones application in C or Spin.
I started on a loader for Zog that completely removes any Spin from the Prop leaving most of the 32K HUB free for C. There does not seem to be much call for this.
Interstingly, Catalina takes the opposite approach - i.e. it uses SPIN during initialization (which allows me to use some of the OBEX objects with only trivial modifications), but after the initialization phase it blows away the SPIN subsystem entirely and starts executing only PASM (in the various plugin cogs) and C code (in the LMM Kernel cogs).
While it would be relatively easy to have Catalina leave a SPIN interpreter running simply by reserving one or more cogs and some Hub RAM for SPIN use only, I haven't found much reason for offering such a capability. This is an interesting difference between Zog and Catalina - I guess it depends on my mindset and perspective compared to Heater's!
What we can probably both agree would be really useful is to be able to have C and SPIN actually integrate - i.e. to be able to call SPIN methods from C, or call C functions from SPIN - and also pass arguments and share global variables between them. But SPIN is not designed to make a method easily "callable" from outside the SPIN subsystem (something that is relatively easy in C - in a way, all C functions are designed to be externally called - this is why the C main function always has arguments).
However, when you spend some time trying to figure out the "plumbing" that would be required to make this work, it just seems a whole lot easier to program everything in either SPIN or C. The best idea I have come up with so far entails adding a "SPIN" subsystem to Catalina, to allow Catalina to load and run a SPIN interpreter the same way it can load and run a C kernel to execute a C function in another cog. But this would have to be a modified SPIN interpreter - i.e. one that accepted information from the caller when started (such as arguments and memory layouts), was able to access shared memory locations defined at compile time (global variables), and also return results to the caller.
If someone wanted to volunteer to work on such a SPIN interpreter, I'd be interested in hearing from them!
The Zog approach of having ZPU cogs and Spin cogs running at the same time just evolved rather than being designed.
Whilst creating the Zog interpreter one needs a way to see what it is doing and debug it. So it starts out being wrapped up in Spin (debug_zog.spin).
Then it needs some console I/O which gets hacked on by providing virtual I/O ports, that are implemented in Spin and end up using FullDuplexSerial.
Then it needs some file I/O which David has done again just using Spin for the FAT because it's there.
And so it goes.
As I said I do have an alternative Spin free approach working (run_zog.spin), to some extent, that blows away Spin entirely and gives Zog all the HUB address space. From there Zog can start other COGs as required. Currently only FullDuplexSerial and VMCOG.
Comments
My biggest concern with C on the Prop is the lack of interest shown by Parallax. It will be hard to draw in more C programmers to use the Prop unless Parallax shows that they will support C. Parallax started a thread about 6 months ago where they discussed the possibility of developing a limited C to Spin converter. After the discussion they held an internal meeting and generated a long list of prioritized tasks, with the C converter at the end. This implies that they have very little interest in supporting C.
Dave
And the result will be less acceptance in the commercial field.
Nick
Write your own preprocessor (I'd use m4) to convert those strings to standard C and run the code through that before compiling it.
I agree with everything you said, David. Even I don't claim that C is "optimal" on the Prop (well, not too often!). But it's good to have it available for those of us who much prefer it to the alternatives.
The main disadvantages of C on the Propeller are well known, and have been discussed endlessly - i.e. it's slower than PASM, and C programs are larger than SPIN programs. But in many cases this is more than compensated for by the advantages of C - i.e. it's much faster than SPIN, and you can write much larger and more complex programs than you can in PASM. Plus the fact that - as you point out - you often don't need to write them at all since they may already exist (in whole or part).
But there is presently another drawback of C - one which also affects SPIN as well as all the other high level languages on the Propeller. This is that it is not easy to take advantage of all the unique facilities the Prop has to offer - which after all is why we all get drawn to the Prop in the first place! Currently, PASM is the only practical language for this. SPIN can do a bit, but is generally too slow - which is why so much code still ends up being written in PASM.
My aim with Catalina is to make a high level language that is functional enough and fast enough to allow all the fascinating features of the Prop to be explored easily - without having to resort to PASM (or at least not very often). It's come some way towards this - and the forthcoming release will take it a bit further still. Of course it still has a fair way to go, but I think that an implementation of C based on LMM PASM (as both ICC and Catalina are) is the right approach.
To bring the thread (in a very longwinded way) back to the original topic, I think this is why Catalina is the best alternative for someone who wants to use C on the Propeller - despite all Catalina's rough edges and flaws. Zog may eventually be a useful C toolchain if all you really want is C - but in that case then you probably should be using a different microprocessor than the Propeller (sorry Heater!).
Ross.
a) I reckon late next year for the Prop II.
b) Almost immediately
I try to resist non-ANSI extensions - not only because it's hard (it requires changing too much of LCC code) but also because it encourages non-portable programming. But google turns up this:
I just tried it, and from this code:
printf("B8 = %x\n", B8(01010101)); printf("B16 = %x\n", B16(10101010,01010101)); printf("B32 = %x\n", B32(10000000,11111111,10101010,01010101));I get: This is why I love C!I will send you the mods but a) it's really simple, and b) I spent mucho $$ and energy to develop ICC Prop and all I got was kick in the pants, so you can have all the glories.
When Prop II takes off, we will take a look then. Until then, it's AVR, M8C and Cortex M for us. Heck, I even just finished off the XGate support for the CPU12 and some 430X support for the MSP430 even though it only benefits a small number of users, but we do take care of our customers. It's not a lot of fun when you work until 4AM in the mornings every day to get blasted in a public forum.
I have a feeling that bringing traditional programming tools to Prop users will always be a bigger challenge than bringing Prop users to less conventional tools like Spin and PASM.
-Phil
Hi Richard,
Thanks for the tip - I'll look into it and see if I want to go down that path.
I'm in the fortunate position of doing this just because I like learning how it's done - I don't have to make a living at it (which is just as well - if I had to depend on Catalina to earn even beer money I would have had to give it up long ago).
I sympathise with you about how unappreciated C seems to be in the Parallax forums. We've had lots of discussions about it, but I still don't really understand it. The topic would never even arise in conjunction any other micro - it would just be understood that of course you can offer other languages, but you absolutely must offer an industrial grade C compiler. Paid ones with full support, as well as freebies.
Maybe the Prop II will be a game changer for Parallax. Or maybe not.
Ross.
Puliiiiize! No.
I understand your desire for convenience here and one can always think of nice features to add to any programming language. But at the end of the day having a standard to work to is of greater value. What happens when I take a module using such non-standard extensions and try to compile it to run on my PC for testing?
No. C does not need the support of Parallax.
Consider this:
The Propeller is not suited to C.
Parallax has better things to use their resources on. Like the Prop II for example.
C was developed by users (AT&T Bell Labs) of a PDP-7 with out any help from the Digital Equipment Corporation.
Everyone uses C on their Intel based PCs every day. But how much of that is using the Intel C compiler? (Also called "ICC" by the way) In fact Intel processors were around for a long time before any C from Intel.
C already has plenty of support from RossH and ImageCraft.
If C users want C on a processor it will be. Regardless of what the chip vendor does. If C on the Prop made any sense there would be hoards of users using it and clamouring for support. ImageCraft would have the incentive to move it along.
No apologies required.
I agree, if one wants to run a lot of C code efficiently one does not want to look at the Prop. However I'm not sure why you single out Zog here. Same applies to Catalina and ICC.
Which brings me to my current "dream processor".
What we want is a micro-controller for our gadgets. We want lot's of I/O, we want timers, we want video, we want all those cores and their deterministic execution timing.
But hey, whilst we are using all that we find we have too much of a program to fit, or we'd like to reuse C code or just use C because that's what we use.
So the "dream processor" is a Propeller and something like an ARM core on the same chip. The ARM gets its memory from piles of external SDRAM/FLASH and runs at some hundreds of megahertz like the one in my mobile phone. Needless to say it runs Linux, perhaps Android.
Given the constraints on die space of the Prop II I'm sure an ARM would not fit. But...
How about deleting one COG and replacing it with a ZPU?
The ZPU probably uses less logic than a COG and would fit nicely.
The loss of a COG would not hurt as their is generally one used for some top level Spin code anyway. Might as well be a full up processor running C.
I know, I know...just dreaming again.
While I agree that none of them are particularly efficient implementations of C - I do differentiate Zog from Catalina and ICC - because the former generates instructions for an emulated processor (and a processor with a completely different architecture to a Propeller cog) while the latter essentially generate PASM (after all, 80% of LMM PASM is just PASM being executed from Hub RAM rather than cog RAM).
Both Catalina and ICC are quite "close" to being true native compilers - they are in fact both pretty much as close as is possible on the Propeller (a true compiler would generate PASM and not LMM PASM - but it would also be limited to 496 instructions and would therefore not be a lot of use).
To illustrate why this is important, consider the multithreading additions I have made to Catalina - they are implemented in a way that is quite "natural" for the Prop - and also quite efficient. I have not had to modify the kernel much since everything that was needed can be quite efficiently expressed in LMM PASM (although I do push some of this into the kernel for efficiency reasons). But you can't do this in native ZPU, since native ZPU doesn't give you access to the special features of the Propeller. You could modify the ZPU instruction set to add some Propeller-specific primitives, but this would also require you to modify the GNU code generator - whereas I have not had to modify Catalina's code generator at all.
With Zog you would probably be tempted to instead compile a Linux version of the pthreads library and leave it at that - but this would be quite a "heavy" solution, and also not very sympathetic to the Propeller way of doing things.
This is not intended to be a criticism of Zog - it is just a difference between the way you tend to do things in Zog versus the way you would tend to do them in Catalina (or ICC).
Ross.
You'll discover that many compilers do have this feature. gcc, Keil, Microchips' C32, ... Especially when working with micro controllers.
It doesn't break anything, it just adds.
But I can add that by compiling my own version.
That should be just a very localized addition in the tokenizer.
"0x...", "0b..."
That is not a problem of C, but its implementation. SPIN is smaller than C (with the two existing implementations for the Prop) because SPIN generates code for a virtual machine ("P-code"). If such a C-compiler would exist for the Prop, you'd have almost the same advantages and disadvantages.
I imagine, that a C-compiler could be built that generates SPIN byte-code. But I won't proof.
Nick
A C compiler that generates SPIN byte codes could be built - this has been proposed before. But SPIN is already many times slower than LMM C, and C that had to be implemented using only SPIN bytecodes would be several times slower still. This is because the SPIN bytecodes are intended (naturally enough) to map efficiently to SPIN language elements - they do not map particularly efficiently to C language elements. C is a "bigger" language than SPIN, with low level features (types, arrays, bit fields etc) that SPIN doesn't have.
While a C that runs that slow might find some applications, it would be fairly limited. I want a C that can concievably compete with PASM, not one that would struggle even to compete with SPIN. As David Betz pointed out - C is the nearest thing we have to a universal assembler. If that's not the case (and it's already marginal with LMM C), then the case for C at all is a bit thin.
OK, fair points.
With one little nit pick:
"LMM PASM is just PASM being executed from Hub RAM rather than cog RAM".
Strictly LMM PASM is not being executed from HUB RAM any more than my PC is executing instructions from it's hard drive.
Nick Mueller:
Such a C compilers does exist, its GCC for the ZPU bytecodes. Interpreted by Zog on the Prop.
And yes, it has the same disadvantages as Spin.
I suspect compiling C to Spin byte codes is not going to work very well. But I also have a suspicion that a better byte code could be defined for C. I can't imagine anyone is up for that task though.
The Spin interpreter could be modified slightly to improve C performance by using a few temporary registers instead of forcing everything to go in and out of the stack. It's also feasible to compile C to SpinLMM, which would provide the best of Spin bytecodes and LMM Pasm. A pragma could be used to force the compiler to use Spin bytecodes, LMM Pasm or even pure Pasm for different sections of the code.
Of course, this is all academic without support from Parallax. If Parallax was to support a C development system it would bring in more C developers, and it would improve their market share. Without Parallax support, C will just play a minor role in software developement for the Prop.
The ZPU is stack based, probably for similar reasons, although in this case it is to minimize logic block usage in an FPGA rather than COG registers.
The Zog interpreter only caches the top of stack value in a COG register (tos).
So for example a ZPU ADD operation does not do a sequence like:
Which is 3 trips to the stack memory, but rather:
zpu_add call #pop add tos, data jmp #done_and_inc_pcWhich is only one stack read.
All this was inspired by Bill Henning who also convinced me that trying to cache any more stack in COG would consume more cycles than it saves. Which is just as well as managing to getting this right was enough for me.
There is one use case where Zog ought to be able to give Catalina and ICC a bit of competition in the speed stakes.
That is to have the byte codes out in external memory with stack and data in HUB. This has the advantage over LMM solutions in not needing to fetch 4 bytes for every instruction.
Really must get down to understanding those linker scripts:)
That is even worse than a p-machine.
You are interpreting code that was not designed to be compact.
I asume you know what p-code, p-machine and UCSD-Pascal is.
Nick
Both are not close enough. 496 instructions are surely not much, but you can do a lot of things with it.
PropBASIC for example does exactly what I would expect from an "compiler" for the prop: A few register for function parameters (all longs), a few extra definitions for the special features of the propeller (coginit, HUB memory access...), and a description of the limitations of the compiler. End of story.
A C compiler that generates SPIN byte codes would be an addon, only necessary because of the small memory of the prop.
BTW. Im not really enthusiastic about propII. 256kb is better then 32 but really not enough if you want do a graphic-user-interface. Let`s talk about 512.
The other way is what imagecraft did: LMM + fcache.
But they did it bad. As a programmer I want to have the possibility to decide what goes in the fcache. An automatic is not enough. Especially if it is not well documented and not predictable. And the fcache has to be big enough (let`s say about 100 instructions).
LMM in my opinion is compromise. And not a good one. What you get is maybe fully bloated C, but with the big disadvantage of slowness without the advantage of spin (saving memory).
Non-standard extensions in in C compiler for microcontroller are not a exception. It`s because every microcontroller has its special features.
Somthing like that is very common, if you have same files for different microcontrollers.
Exactly. Nothing more. C is not linux, nor printf or something else. It`s there that I have not to learn 10 different assembly dialects. I have one language for all my microcontrollers and I can use programming examples from others (e.g. for an external hardware).
Almost as bad as Java:)
Actually compact code is somewhere in the ZPU design requirements. After all if you are minimizing space usage in an FPGA that includes trying to keep the use of RAM blocks down.
Zylin seem quite pleased with ZPU code density claiming "Codesize 80% of ARM thumb".
Zylin are now looking at targeting LLVM at the ZPU with a view to shrinking code an increasing performance.
Ah yes, had a Tiny Pascal p-code system for a TRS-80 back in the day. And I have wondered about a Pascal/p-code machine for the Prop. However it looks like a p-code interpreter won't fit in a COG. At least from cursory view of this one: http://homepages.cwi.nl/~steven/pascal/book/10pcode.html
I don't want to hijack this thread, but I wanted to point out that PropBasic allows you to mix both native and LMM code very easily by just adding "LMM" to the code header (PROGRAM or TASK).
PropBasic generated pretty tight PASM code, so yes you CAN do quite a bit in 496 instructions.
I don't use C, but being able to generate both native and LMM code would be pretty high on my list of features for any compiled language for the propeller.
Native code is needed for video drivers and such, and LMM for the "meat" of the program that could be quite large.
Again I know very little about C, so I don't mean to cast stones.
A big problem with PropBasic or C (or any other language for the propeller) is that interfacing with spin is not easy or seemless. This makes much of the OBEX useless for other language users.
Bean
I plugged TV_Text_Half_Height.spin as a character device into ZOG this week with very little effort. Interfacing with it as a block/memory device will take a little more work. I also plugged in my TwiKeyboard.spin painlessly yesterday.
ZOG makes many things possible because ZOG can use Spin to add objects.
Haha! Good one!
Naa, the p-machine was really compact. The op-codes (like div mul add etc) worked on chars, ints, floats, pointers, ... and knew how to treat them properly. On the Apple ][ you could write really huge programs (but maybe my definition of "huge" changed over time :smhair:) with 64k. But the p-code interpreter wouldn't fit inside a cog (I guess).
I doubt I still have the book "Inside the p-machine". Don't remember the title that well, just the cover showing an old couple in front of a tree.
Nick
Hi Bean,
I wouldn't worry about hijacking the thread - or casting stones either. Us non-SPIN Propeller users soon develop thick skins, or we don't last long
I'm doing some thinking about how to integrate SPIN with Catalina C - but I've not come up with anything worthwhile yet. SPIN was not really designed with such integration in mind (and nor was Catalina!).
Ross.
This is a big problem, because without sample Obex codes, I can't use PropBasic or C.
Why can't Spin run in one cog while PropBasic or C run in another cog?
It can. When running C programs under Zog the initial start up spin code continues to run. One can therefore add to ones application in C or Spin.
I started on a loader for Zog that completely removes any Spin from the Prop leaving most of the 32K HUB free for C. There does not seem to be much call for this.
Interstingly, Catalina takes the opposite approach - i.e. it uses SPIN during initialization (which allows me to use some of the OBEX objects with only trivial modifications), but after the initialization phase it blows away the SPIN subsystem entirely and starts executing only PASM (in the various plugin cogs) and C code (in the LMM Kernel cogs).
While it would be relatively easy to have Catalina leave a SPIN interpreter running simply by reserving one or more cogs and some Hub RAM for SPIN use only, I haven't found much reason for offering such a capability. This is an interesting difference between Zog and Catalina - I guess it depends on my mindset and perspective compared to Heater's!
What we can probably both agree would be really useful is to be able to have C and SPIN actually integrate - i.e. to be able to call SPIN methods from C, or call C functions from SPIN - and also pass arguments and share global variables between them. But SPIN is not designed to make a method easily "callable" from outside the SPIN subsystem (something that is relatively easy in C - in a way, all C functions are designed to be externally called - this is why the C main function always has arguments).
However, when you spend some time trying to figure out the "plumbing" that would be required to make this work, it just seems a whole lot easier to program everything in either SPIN or C. The best idea I have come up with so far entails adding a "SPIN" subsystem to Catalina, to allow Catalina to load and run a SPIN interpreter the same way it can load and run a C kernel to execute a C function in another cog. But this would have to be a modified SPIN interpreter - i.e. one that accepted information from the caller when started (such as arguments and memory layouts), was able to access shared memory locations defined at compile time (global variables), and also return results to the caller.
If someone wanted to volunteer to work on such a SPIN interpreter, I'd be interested in hearing from them!
Ross.
The Zog approach of having ZPU cogs and Spin cogs running at the same time just evolved rather than being designed.
Whilst creating the Zog interpreter one needs a way to see what it is doing and debug it. So it starts out being wrapped up in Spin (debug_zog.spin).
Then it needs some console I/O which gets hacked on by providing virtual I/O ports, that are implemented in Spin and end up using FullDuplexSerial.
Then it needs some file I/O which David has done again just using Spin for the FAT because it's there.
And so it goes.
As I said I do have an alternative Spin free approach working (run_zog.spin), to some extent, that blows away Spin entirely and gives Zog all the HUB address space. From there Zog can start other COGs as required. Currently only FullDuplexSerial and VMCOG.
My plan is to continue down that Spin free path.
As for linking C and Spin, No thanks.
The purist part of me agrees - but the realist part of me says that this is the way to get C used more widely on the Propeller.
It might get done one day - we'll see.
Ross.