Jazzed said...
Next you'll imply that Linux is irrelevant too [noparse]:)[/noparse]
Linux is irrelevant too.
Neither LINUX nor GCC have anything to do with C. Yes, I'd love to see LINUX on the Prop. But LINUX depends on "extensions" to the C language implemented specifically for it in GCC. And anyway, Linux on an 80Mhz Propeller would probably run about as well as Windows does on a 3GHz quad-core Intel - i.e. like a small furry quadruped.
Anyway, who needs an operating system on a microcontroller? C has a long history of being used in bare-metal embedded processors. It's the only relatively high-level (compared to assembler), mainstream, portable, widespread language that can make that claim - which is precisely why it is ubiquitous in that market.
Ross.
P.S. Ray - actually, neither Jazzed nor I are probably "right" - it's a judgment call, and depends on your application. For what I want to do, C on the Prop is a the perfect answer. For what others want to do, maybe not. C is never going to "replace" SPIN or PASM - it just provides an alternative.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I absolutely agree with much of what you said and that running Linux on the current Propeller is irrelevant (too slow, too small, not enough pins, no ANSI C99 tool-chain like GNU C) ... it is after all just a microcontroller. It will also be irrelevant on the next Propeller because of lack of GNU C. In the mean time AVR32 (which is also just a microcontroller) generates lots of interest because it is not irrelevant.
By being influenced to be not interested GNU tools, Parallax will suffer market share opportunity loss, but that is also apparently irrelevant.
The AVR32 is a microprocessor rather than a microcontroller. I expect both microcontrollers and microprocessors to support C - but I wouldn't necessarily expect (or need, or want) a microcontroller to support either GCC or Linux.
Ross.
P.S:
[noparse][[/noparse]pedantry] Although it's close enough for most purposes, GCC is only partially ANSI C99 compliant - and will never be fully compliant as some of its extensions conflict with the C99 standard - see here [noparse][[/noparse]/pedantry]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
RossH said...
[noparse][[/noparse]pedantry] Although it's close enough for most purposes, GCC is only partially ANSI C99 compliant - and will never be fully compliant as some of its extensions conflict with the C99 standard - see here [noparse][[/noparse]/pedantry]
This is a good reference point, so I conceed to it. However, momentum·is not with you beyond the bounds of this forum.
As far as the other "thing", I'll just post this edited snippet from the manufacturer's web site and try to avoid further references to it out of respect to the Parallax forum owners/contributors. "The 32-bit *** UC3 microcontrollers deliver high computational throughput, deterministic real-time control, low power consumption, low system cost, high reliability and ease of use." GNU is certainly supported on much of their 8 bit stuff of course.
From the manufacturer's "architecture document" (emphasis mine, with names changed to FOOBAR out of deference to our hosts):
"FOOBAR is a new high-performance 32-bit RISC microprocessor core ... FOOBAR complements the current FOO microcontrollers ... Through the FOOBAR family, the FOO is extended into a new range of higher performance applications that is currently served by 32- and 64-bit processors ... The FOOBAR is a new innovative microprocessor architecture."
The problem is that there is no strict definition of what is a controller vs what is a processor - but I'll agree that this chip probably sits on the boundary - it claims to be a microprocessor core in a microcontroller package. For my money, a microcontroller is essentially designed to be self-sufficient. If a processor has external memory and data buses (as the FOOBAR does), it's a microprocessor - and is designed to compete with other processors. The fact that they also sell it in a variant that doesn't externalize these bus pins doesn't really change that. By that definition I could package up any chip and call it a "microcontroller" - but that doesn't mean it's a competitor to chips like the Propeller, or that the Propeller needs to slavishly support everything such a chip can do - like use GCC or run Linux.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
- but that doesn't mean it's a competitor to chips like the Propeller, or that the Propeller needs to slavishly support everything such a chip can do - like use GCC or run Linux.
Of course [noparse]:)[/noparse] It is certainly competing for my attention right now though considering the alternatives (or lack thereof). Yes, the definition of microcontroller can be illusive. BTW, I haven't started on that project yet, but will get to it for sure. Cheers.
Funny here FOOBAR is called microcontroller on line 1. Mixed message .... [noparse]:)[/noparse]
Sorry for wandering so far off course Ray. Clearly advances in C like anything else can be complicated.
I found that the discussion was relevant for this thread. It is almost boiling down to the merits of why somebody should use C with the propeller.
I need some explanation for this quote:
"SPIN is interpreted, C (even under LMM) is native. And C runs 4 times faster than SPIN."
Does C run four times faster only when it is using LMM, or is this for every condition. I thought that ICC, or for that matter, any C compiler 'converts' the code to asm, and then does what ever it does with that. The quote above is almost implying that the ICC compiler is NOT optimizing the code enough? So, what would be gained by using some of the other compilers mentioned, code gets optimized better, and it will now run twenty times faster than the Spin code. What is the comparison between PASM and ICC, or any C compiler, from speed factor. In other words how much faster does the PASM program run when compared to some C code, apples to apples please.
Rsadeika said...
I found that the discussion was relevant for this thread. It is almost boiling down to the merits of why somebody should use C with the propeller.
I need some explanation for this quote:
"SPIN is interpreted, C (even under LMM) is native. And C runs 4 times faster than SPIN."
Does C run four times faster only when it is using LMM, or is this for every condition. I thought that ICC, or for that matter, any C compiler 'converts' the code to asm, and then does what ever it does with that. The quote above is almost implying that the ICC compiler is NOT optimizing the code enough? So, what would be gained by using some of the other compilers mentioned, code gets optimized better, and it will now run twenty times faster than the Spin code. What is the comparison between PASM and ICC, or any C compiler, from speed factor. In other words how much faster does the PASM program run when compared to some C code, apples to apples please.
Ray
I'm a convert to the idea that Spin is better for the Propeller than C. Personally, the only reason today for me to use C on Propeller is for XMM ability. If I need speed, I use PASM, otherwise I use Spin mainly because Spin is smaller than PASM and C.
Trying hard to answer all your questions in a fair way here:
The Propeller runs PASM in one or more COGs. Each COG has 512 code registers or memory locations. For C or any other language needing > 512 longs to work, it uses LMM which was suggested for Propeller by Bill Henning. Normally a C compiler creates native ASM code for the CPU; in this case it creates LMM. LMM uses most PASM instructions. LMM and PASM are different because of the fetch and jump mechanisms. LMM is an interpreter running in a COG in a similar way that Spin is an interpreter running in a COG. LMM uses a loop to fetch and executes instructions. The LMM loop takes at minimum 3 instructions or 16 clock cycles to execute just one PASM instruction. Any jump instruction (jmp,jmpret,tjz,tjnz,djnz) must be replaced by a macro and interpreted by LMM.
It is not necessarily the case that C needs to optimize more, it just has to use the LMM method to run programs that are greater than 512 instructions. This makes C 4 times slower than PASM, but faster than Spin (and unfortunately over 3 times bigger than Spin). Here is a table I produced last year showing apples to apples measurements.
SPIN/PASM/ICCPROP Comparisons
SPIN PASM ICCPROP *1 - Condition
25us 200ns 1.04us - Bit toggle while loop cycle *2 time.
40us 420ns 2.1us - Bit toggle while loop set by if-else loop with ndx & 1.
50us 520ns *3 2.9us - Bit toggle while loop set by if-else loop with ndx & 1 + increment.
40us 420ns 3.8us - Function call bit toggle while loop cycle time.
26s 800ms 14s - Fibo29 test (relative ... not necessarily the best performance measure).
Notes:
1. ImageCraft C default LMM unrolled by 4 and uncached.
2. A cycle is a transition from state 1 to state 2 back to state 1. Some "periods" of cycles are asymetrical.
3. Asymetrical comparison if_z, if_nz, then increment.
4. Performance for Catalina not known but should be comparable to ICC.
ICC claims to be optimized in some ways over the LCC implementation. Assuming Catalina does not have these optimizations, it may result in marginally bigger and slower code. I've asked for competitive comparisons before, but no one wants to do it for some reason.
C on other processors will run at the ASM rate which would be about the clock rate in some cases. C on Propeller is 16 times slower than the clock rate. Other compilers such as GNU GCC do have various optimization levels, but they are mostly trade-offs between size and speed. Some optimizations eliminate "redundant operations" which can be bad for device drivers accessing the same register 4 times in a row (the volatile keyword is used to force no optimizations in such cases). There should be only marginal differences in generated code size between compilers although ICC claims to produce 20% smaller code than GNU GCC. The main thing gained by using GNU GCC is that it will compile more code than ANSI C89 including the Linux operating system.
Rsadeika: Put simply: If you compile C to native PASM instructions you are stuck with the fact that a COG can only hold 496 instructions at one time. A COG cannot execute it's native PASM instructions from HUB. It's kind of pointless to have a C compiler for such small programs. So you might think of working around the 496 limit by using overlays as was done in the days of 8 bit processors with limited RAM.
Enter Bill Henning. He basically realized you could make the "overlays" only one PASM instruction long. That is have you C code compiled to PASM that sits in HUB RAM. Then have a little "kernel" program running in the COG that loads the instructions one at a time and executes them. With tight coding you can do that with an over head of 4 instructions executed in kernel for each instruction fetched and executed from HUB. This trick works nicely for the Prop as all the instructions are 32 bits wide.
The rest is history, this Large Memory Model (LMM) technique is used by the ICC and Catalina compilers.
It then leads to the idea that you can have the C PASM ops in an external RAM instead of HUB for much bigger programs. Catalina can do this. No idea about ICC.
As you might start to realize, there is no "apples to apples" comparison of performance between C and PASM on the Prop like you might expect of a normal micro-processor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
... As you might start to realize, there is no "apples to apples" comparison of performance between C and PASM on the Prop like you might expect of a normal micro-processor.
My performance comparison table fails to achieve this? If so, how?
The subject of LMM, which has been mentioned a few times, is not strictly a method for using an expanded memory module (my name for it), is it? I looked at the examples that were provided by ICC, and I did not recognize any programs that were using it. So, if cog ram is in short supply, and if you want to increase it, you would use the LMM to grab some of the hub ram to do so. It would be nice to see LMM in action.
As for PASM, their is no method of increasing cog ram? It seems that if you need to access more ram than the cog has, then C is the only way to go, at a cost of slower speeds, but faster than Spin. I was looking at the propeller manual, noticed that hub ram is 32kb, and it included the 32kb of ROM (Read Only Memory). Has anybody thought about how that could be used for a programming advantage?
Rsadeika said...
The subject of LMM, which has been mentioned a few times, is not strictly a method for using an expanded memory module (my name for it), is it? I looked at the examples that were provided by ICC, and I did not recognize any programs that were using it. So, if cog ram is in short supply, and if you want to increase it, you would use the LMM to grab some of the hub ram to do so. It would be nice to see LMM in action.
LMM is used by ICC and Catalina ... when you run your C program, you are watching LMM in action.
Expanded memory or XMM (provided by an added chip) can be accessed with LMM with the right C LMM interpreter "kernel". Catalina provides this XMM in its distribution. ICC does not provide XMM, although I have code for it that works ... It is excruciatingly slow in any form for me though. I'm working on alternatives.
Some features that would be nice for the ICC IDE:
1. On/off line numbers that would also show where the error(s) occurred.
2. Display of RAM and cog(s) used, plus program size.
3. Close the file at the tab.
Both heater and jazzed have answered most of your points, but I think it's worth summing up ...
For LMM C, I find that the following is a reasonable set of metrics to keep in the back of your mind (for "real world" cases):
LMM C is about 4 times faster than SPIN.
LMM C is about 4 times larger than SPIN
LMM C is about 4 times slower than PASM.
Jazzed's figures show a wide variation between SPIN and ICC for particular language constructs - but I'm talking about averages over large programs that make use of many constructs (for example, Jazzed's figures show that ICC performs 20 times faster on some bit operations, but only 2 times faster on some recursive operations). And of course there are variations between ICC and Catalina. I have done some informal comparisons of the two compilers, and it turns out that Catalina is faster than ICC on some things, and ICC is faster than Catalina on others. This is what you would expect given that the initial design goals and implementations are so different, even though they are both based on the same "free" compiler (i.e. LCC). But even with all the variations, I think the above metrics are a reasonable "rough guide".
That's for LMM programs. For XMM the situation is more complex. SPIN can't execute from XMM, so we have to compare C executing from XMM RAM with SPIN executing from Hub RAM. So there's another metric:
XMM C is currently about 4 times slower than SPIN
However, I believe that having C programs execute from XMM RAM at speeds compariable to SPIN is quite achievable - given suitable hardware and a bit of software optimization. That's why I emphasise "currently"
So - is C useful on the Prop? Well - if you want to use a standard high-level language that executes many times faster than SPIN, then the answer is yes. If you are expecting to achieve PASM speeds (as C can do on some other platforms), then no - the achitecture of the Prop precludes that (except in trivially small cases).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Jazzed: Nothing wrong with your performance comparison table. What I meant by "there is no "apples to apples" comparison of performance between C and PASM" is simply this:
On a typical computer can choose to create your program in ASM or create the same functionality in C. No matter if the program ends up as a 10 byte executable or a million or whatever.
On the Propeller you do not have that choice. Over a certain size raw PASM is out of the question.
Hence this kind of direct speed comparison, "apples to apples" has a lot less meaning on the Prop than a naive newcomer might expect.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Since I sort of freed up a VGA monitor, close to where I work with the demo board, I would like to use that instead of the serial terminal program. The only problem that I see is the 15x32 character set, I may be going blind, but I am not there yet LOL. So, I guess I need to gather some information as to how to get the character set down to maybe 24x80. I think that would be easy enough to read on the VGA monitor. At first I thought it would be as easy as changing two lines in the VGA header file, but that did not work. I guess I need more information. Since jazzed is the author of the VGA program, I guess this is directed at him, but others can join in.
Rsadeika said...
Since I sort of freed up a VGA monitor, close to where I work with the demo board, I would like to use that instead of the serial terminal program. The only problem that I see is the 15x32 character set, I may be going blind, but I am not there yet LOL. So, I guess I need to gather some information as to how to get the character set down to maybe 24x80. ...
Go find a VGA driver in the OBEX or on the forum that does what you need in one COG. Then I'll help you convert the PASM for ICC to use. I don't have an ICC license right now because of my computer crash last year, so it may be up to you to do the work. Hi-res VGA if I remember correctly needs like 5 COGs ... that could be done with my method, but it's uncharted territory.
I just downloaded the VGA Hi-Res Text driver, it uses two cogs. I just looked at your C code for the 15x32, and the Hi-res Spin stuff, it is way over my head. I will still keep looking at it, but I doubt that I will be able to come up with anything. Hopefully, maybe one of the other active C programmers will put something in the Obex. Speaking of the Obex, I noticed there is a lot more C programs there, the last time I check, I think there were about four programs. So, C is making some progress in the Propeller world.
Catalina supports the VGA Hi_Res Text driver (as well as the VGA Low-Res driver and TV driver). I'm sure someone will develop an ICC version, but in the meantime you could continue your investigations with C Catalina.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Comments
Linux is irrelevant too.
Neither LINUX nor GCC have anything to do with C. Yes, I'd love to see LINUX on the Prop. But LINUX depends on "extensions" to the C language implemented specifically for it in GCC. And anyway, Linux on an 80Mhz Propeller would probably run about as well as Windows does on a 3GHz quad-core Intel - i.e. like a small furry quadruped.
Anyway, who needs an operating system on a microcontroller? C has a long history of being used in bare-metal embedded processors. It's the only relatively high-level (compared to assembler), mainstream, portable, widespread language that can make that claim - which is precisely why it is ubiquitous in that market.
Ross.
P.S. Ray - actually, neither Jazzed nor I are probably "right" - it's a judgment call, and depends on your application. For what I want to do, C on the Prop is a the perfect answer. For what others want to do, maybe not. C is never going to "replace" SPIN or PASM - it just provides an alternative.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
By being influenced to be not interested GNU tools, Parallax will suffer market share opportunity loss, but that is also apparently irrelevant.
The AVR32 is a microprocessor rather than a microcontroller. I expect both microcontrollers and microprocessors to support C - but I wouldn't necessarily expect (or need, or want) a microcontroller to support either GCC or Linux.
Ross.
P.S:
[noparse][[/noparse]pedantry] Although it's close enough for most purposes, GCC is only partially ANSI C99 compliant - and will never be fully compliant as some of its extensions conflict with the C99 standard - see here [noparse][[/noparse]/pedantry]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
As far as the other "thing", I'll just post this edited snippet from the manufacturer's web site and try to avoid further references to it out of respect to the Parallax forum owners/contributors. "The 32-bit *** UC3 microcontrollers deliver high computational throughput, deterministic real-time control, low power consumption, low system cost, high reliability and ease of use." GNU is certainly supported on much of their 8 bit stuff of course.
We could argue this back and forth all day
From the manufacturer's "architecture document" (emphasis mine, with names changed to FOOBAR out of deference to our hosts):
"FOOBAR is a new high-performance 32-bit RISC microprocessor core ... FOOBAR complements the current FOO microcontrollers ... Through the FOOBAR family, the FOO is extended into a new range of higher performance applications that is currently served by 32- and 64-bit processors ... The FOOBAR is a new innovative microprocessor architecture."
The problem is that there is no strict definition of what is a controller vs what is a processor - but I'll agree that this chip probably sits on the boundary - it claims to be a microprocessor core in a microcontroller package. For my money, a microcontroller is essentially designed to be self-sufficient. If a processor has external memory and data buses (as the FOOBAR does), it's a microprocessor - and is designed to compete with other processors. The fact that they also sell it in a variant that doesn't externalize these bus pins doesn't really change that. By that definition I could package up any chip and call it a "microcontroller" - but that doesn't mean it's a competitor to chips like the Propeller, or that the Propeller needs to slavishly support everything such a chip can do - like use GCC or run Linux.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Funny here FOOBAR is called microcontroller on line 1. Mixed message .... [noparse]:)[/noparse]
Sorry for wandering so far off course Ray. Clearly advances in C like anything else can be complicated.
Post Edited (jazzed) : 2/17/2010 2:40:33 AM GMT
I need some explanation for this quote:
"SPIN is interpreted, C (even under LMM) is native. And C runs 4 times faster than SPIN."
Does C run four times faster only when it is using LMM, or is this for every condition. I thought that ICC, or for that matter, any C compiler 'converts' the code to asm, and then does what ever it does with that. The quote above is almost implying that the ICC compiler is NOT optimizing the code enough? So, what would be gained by using some of the other compilers mentioned, code gets optimized better, and it will now run twenty times faster than the Spin code. What is the comparison between PASM and ICC, or any C compiler, from speed factor. In other words how much faster does the PASM program run when compared to some C code, apples to apples please.
Ray
I'm a convert to the idea that Spin is better for the Propeller than C. Personally, the only reason today for me to use C on Propeller is for XMM ability. If I need speed, I use PASM, otherwise I use Spin mainly because Spin is smaller than PASM and C.
Trying hard to answer all your questions in a fair way here:
The Propeller runs PASM in one or more COGs. Each COG has 512 code registers or memory locations. For C or any other language needing > 512 longs to work, it uses LMM which was suggested for Propeller by Bill Henning. Normally a C compiler creates native ASM code for the CPU; in this case it creates LMM. LMM uses most PASM instructions. LMM and PASM are different because of the fetch and jump mechanisms. LMM is an interpreter running in a COG in a similar way that Spin is an interpreter running in a COG. LMM uses a loop to fetch and executes instructions. The LMM loop takes at minimum 3 instructions or 16 clock cycles to execute just one PASM instruction. Any jump instruction (jmp,jmpret,tjz,tjnz,djnz) must be replaced by a macro and interpreted by LMM.
It is not necessarily the case that C needs to optimize more, it just has to use the LMM method to run programs that are greater than 512 instructions. This makes C 4 times slower than PASM, but faster than Spin (and unfortunately over 3 times bigger than Spin). Here is a table I produced last year showing apples to apples measurements.
ICC claims to be optimized in some ways over the LCC implementation. Assuming Catalina does not have these optimizations, it may result in marginally bigger and slower code. I've asked for competitive comparisons before, but no one wants to do it for some reason.
C on other processors will run at the ASM rate which would be about the clock rate in some cases. C on Propeller is 16 times slower than the clock rate. Other compilers such as GNU GCC do have various optimization levels, but they are mostly trade-offs between size and speed. Some optimizations eliminate "redundant operations" which can be bad for device drivers accessing the same register 4 times in a row (the volatile keyword is used to force no optimizations in such cases). There should be only marginal differences in generated code size between compilers although ICC claims to produce 20% smaller code than GNU GCC. The main thing gained by using GNU GCC is that it will compile more code than ANSI C89 including the Linux operating system.
Enter Bill Henning. He basically realized you could make the "overlays" only one PASM instruction long. That is have you C code compiled to PASM that sits in HUB RAM. Then have a little "kernel" program running in the COG that loads the instructions one at a time and executes them. With tight coding you can do that with an over head of 4 instructions executed in kernel for each instruction fetched and executed from HUB. This trick works nicely for the Prop as all the instructions are 32 bits wide.
The rest is history, this Large Memory Model (LMM) technique is used by the ICC and Catalina compilers.
It then leads to the idea that you can have the C PASM ops in an external RAM instead of HUB for much bigger programs. Catalina can do this. No idea about ICC.
As you might start to realize, there is no "apples to apples" comparison of performance between C and PASM on the Prop like you might expect of a normal micro-processor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As for PASM, their is no method of increasing cog ram? It seems that if you need to access more ram than the cog has, then C is the only way to go, at a cost of slower speeds, but faster than Spin. I was looking at the propeller manual, noticed that hub ram is 32kb, and it included the 32kb of ROM (Read Only Memory). Has anybody thought about how that could be used for a programming advantage?
Ray
Expanded memory or XMM (provided by an added chip) can be accessed with LMM with the right C LMM interpreter "kernel". Catalina provides this XMM in its distribution. ICC does not provide XMM, although I have code for it that works ... It is excruciatingly slow in any form for me though. I'm working on alternatives.
1. On/off line numbers that would also show where the error(s) occurred.
2. Display of RAM and cog(s) used, plus program size.
3. Close the file at the tab.
Just a few, maybe more.
Ray
Both heater and jazzed have answered most of your points, but I think it's worth summing up ...
For LMM C, I find that the following is a reasonable set of metrics to keep in the back of your mind (for "real world" cases):
- LMM C is about 4 times faster than SPIN.
- LMM C is about 4 times larger than SPIN
- LMM C is about 4 times slower than PASM.
Jazzed's figures show a wide variation between SPIN and ICC for particular language constructs - but I'm talking about averages over large programs that make use of many constructs (for example, Jazzed's figures show that ICC performs 20 times faster on some bit operations, but only 2 times faster on some recursive operations). And of course there are variations between ICC and Catalina. I have done some informal comparisons of the two compilers, and it turns out that Catalina is faster than ICC on some things, and ICC is faster than Catalina on others. This is what you would expect given that the initial design goals and implementations are so different, even though they are both based on the same "free" compiler (i.e. LCC). But even with all the variations, I think the above metrics are a reasonable "rough guide".That's for LMM programs. For XMM the situation is more complex. SPIN can't execute from XMM, so we have to compare C executing from XMM RAM with SPIN executing from Hub RAM. So there's another metric:
- XMM C is currently about 4 times slower than SPIN
However, I believe that having C programs execute from XMM RAM at speeds compariable to SPIN is quite achievable - given suitable hardware and a bit of software optimization. That's why I emphasise "currently"So - is C useful on the Prop? Well - if you want to use a standard high-level language that executes many times faster than SPIN, then the answer is yes. If you are expecting to achieve PASM speeds (as C can do on some other platforms), then no - the achitecture of the Prop precludes that (except in trivially small cases).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 2/18/2010 1:59:12 AM GMT
On a typical computer can choose to create your program in ASM or create the same functionality in C. No matter if the program ends up as a 10 byte executable or a million or whatever.
On the Propeller you do not have that choice. Over a certain size raw PASM is out of the question.
Hence this kind of direct speed comparison, "apples to apples" has a lot less meaning on the Prop than a naive newcomer might expect.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ray
Ray
Catalina supports the VGA Hi_Res Text driver (as well as the VGA Low-Res driver and TV driver). I'm sure someone will develop an ICC version, but in the meantime you could continue your investigations with C Catalina.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina