ImageCraft Propeller C Compiler

woodrowg

www. Imagecraft.com

Propeller C Compiler.

Beta version is now available.

Would anyone like to open this can of worms?
wg

Bob Lawrence (VE1RLL)

Can is already open

http://forums.parallax.com/showthread.php?p=722470

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob

Mike Green

There's not much in the way of "worms". There's been open discussion of the beta's capabilities and limitations all along. It's a work in progress and ImageCraft has a reputation for delivering quality C implementations for other microcontrollers.

woodrowg

Thanks for pointing me to the existing thread. I must have searched on wrong keywords.

To Mike Green:
'Can of worms' was not intended to disparage the effort. Just a figure of speech. I'm looking forward to learning to use the compiler. No doubt there will be worms (or bugs) to discuss as the project moves forward.

Some of the caveats in readme file were somewhat disappointing, such as problem launching more than two COG's and lack of a printf function. But I am hopeful these issues will be resolved soon.

My comment in previous thread about tradeoffs of more HUB RAM vs. more COGs for Prop II was related to another statement in ImageCraft readme file about LMM.
"LMM VIRTUAL MACHINE:
To bypass the 512 long words limitation of a COG RAM program, ICCProp uses
a Large Memory Model (LMM) scheme, originally proposed by Bill Henning. The
basic idea is that instructions in HUB RAM is fetched into the COG RAM, and
then executed inline."

It would seem intuitive that the C compiler's use of system resources will probably be much more efficient if the size of HUB RAM is increased, giving weight to the argument to add more RAM space in Prop II.
wg

ImageCraft

woodrowg said...
...

Some of the caveats in readme file were somewhat disappointing, such as problem launching more than two COG's and lack of a printf function. But I am hopeful these issues will be resolved soon.
...

The problem with launching more than 2 cogs is not a limitation, it's a matter of debugging what's going on. The major problem is there is no way to peek inside the COG per se. Remember, the basic COG launching does it, the COGINIT instruction, bam, and you are good to go. Except in this case, we are launching a LMM kernel and then it has to bootstrap itself before fetching and executing user code. In fact, the biggest complexity of Propeller C is designing and tuning the compiler and LMM interface and the LMM coding itself. This lack of ability to see what's going on is one reason why we use GEAR, except that when a problem occurs, we have to determine whether it's a GEAR bug or our bug, or something we don't understand about the Propeller. Right now, our test program shows that after 2 COGs are launched, the 3rd one doesn't seem to work. It may even be the fault of the test program, who knows, but it's something we need to figure out. Suffice to say, at production time, there won't be any limitations like that.

As for printf, that's a non-issue. It's written in C. Once we got everything working well, a recompile does it.

Is Propeller C production quality, no, hence it's a BETA.

woodrowg

Many of us were weened on the use of printf as a poor man's debugger. Particularly in multi-threaded code development. To leave it out of the Beta release would seem to limit potentially constructive criticism from highly motivated users.

On the other hand, a well designed cross-compiler for a 32 bit processor for $200 is certainly a bargain.

I would not want to waste your time with excess noise until you feel the product is ready for release. That may very well hinge on solidification of the Prop II specification. This could be a proverbial Catcha II, II conundrum. Hope you can work it out to the satisfaction of both parties.

Will you post a copy of the printf function for Prop I when it sees the light of day?
Thank you

Mike Green

woodrowg,
Do keep in mind that the Propeller, like other microcontrollers, doesn't have a "standard console". You may still have your PC connected via the downloading serial port and be willing to use some kind of terminal emulator, but you may just as well want to use a TV display or VGA display or, for that matter, a small LCD display for debugging purposes. sprintf is likely to be a more useful tool than printf and, truthfully, neither are present currently. It's a trivial effort to add simple hex and decimal output formatters since they only take a few lines of code, whether in Spin or C.

woodrowg

I believe they (ImageCraft) said they have no plan to support inline Spin code. I'm not yet clear on why they would make such a statement, but I suspect it has to do with support for small memory models, eg, 512 x 32 bits, within a single COG. I am not so well versed in the instruction set but at present, that does not make sense to me.

You have a history here, well meaning, a voice of reason, but sometimes I don't understand your point of view.
wg

hippy

It would be difficult to handle inline Spin code as that compiles to bytecode entirely different to the C-LMM instruction set, the ImageCraft Virtual machine would have to handle C-LMM plus Spin bytecode and that's not easy in practice, plus the C compiler would have to be a Spin compiler as well. Even supporting launching Spin in a separate Cog run by the Chip's in-built Spin Interpreter would be challenging because the memory usage models are (probably) very different.

With the fullness of time there may become ways to integrate C and Spin ( or vice-versa ), but it makes sense to get C working as C first which is the business ImageCraft are into.

Mike Green

I hope hippy's explanation made sense. The Spin interpreter is written in assembly language and completely fills a cog's memory. It is copied from ROM to a cog's memory during the Propeller's initialization or anytime the Spin interpreter executes a particular form of the COGNEW / COGINIT statement. It can also be initiated from assembly language using a COGNEW / COGINIT instruction with a particular set of parameters. The memory usage parameters are indeed different from the LMM interpreter's although theoretically a block of memory within a C program could be set aside for the use of a Spin interpreter and not interfere with an LMM interpreter running in another cog. I don't believe it's been tried yet. In any event, without a Spin compiler that generates LMM assembly code, it doesn't make sense to have in-line Spin code.

ImageCraft has talked about generating code for direct execution within a cog. Bill Henning's original LMM kernel had provisions for copying a block of code from hub memory to a buffer in the LMM interpreter for direct execution. This was intended for some operations, particularly very time dependent I/O functions, that would benefit from this arrangement. ImageCraft has dropped this for the initial release of the compiler because it requires a different code generator and optimizer, but they would like to eventually have this capability. It probably would be added first to just the assembler and linker since that's simpler.

stevenmess2004

On using spin code, it should be possible to start a new cog in spin from c but you would have to use some assembler and you would have to use an already compiled object. Maybe that can be my project. It would take a bit of mucking around though and there wouldn't be much (if any) support for calling the methods in the spin cog etc.

ImageCraft

woodrowg said...
Many of us were weened on the use of printf as a poor man's debugger. Particularly in multi-threaded code development. To leave it out of the Beta release would seem to limit potentially constructive criticism from highly motivated users.

On the other hand, a well designed cross-compiler for a 32 bit processor for $200 is certainly a bargain.

I would not want to waste your time with excess noise until you feel the product is ready for release. That may very well hinge on solidification of the Prop II specification. This could be a proverbial Catcha II, II conundrum. Hope you can work it out to the satisfaction of both parties.

Will you post a copy of the printf function for Prop I when it sees the light of day?
Thank you

I am not sure how PropII fit into this ICC for Propeller will be released relatively shortly. The issues with multi-COG launching or printf are not showstoppers. We just need to debug what's wrong, there is nothing fundamentally broken that we need to wait until PropII.

Remember, ICC for Propeller is not built from scratch per se. 95% of the IDE is common code with our existing products that we have been shipping since 2000. Likewise, 90% or more of the compiler is the same as the first compiler we shipped in 1994. The asm and linker are relatively new, but they are built from the same code base as our ARM asm/linker that we started shipping in 2006. The LMM kernel is completely new of course, but it's only ~200 longs, how difficult can it be? (a joke )



// richard

jazzed

Steven,

I've also considered using a precompiled object for my DRAM expansion project.
I plan to dump a binary into an include file as an ascii-hex array to run native asm in a cog:

od -v -t x4 PasmTest.binary | sed "s/ /, 0x/g" | cut -d" " --fields 2,3,4,5
0x04c4b400, 0x0010dc6f, 0x0034002c, 0x00380024
0x0002001c, 0x00000014, 0xa0ffec01, 0x6cffe801
0x5c7c0001, 0x3508c734, 0x0000322c
(I guess awk would be better than cut for formatting ... using Cygwin).

Problem is in interfacing with the rest of the program. The ImageCraft cognew library function
does not pass the address of parameter to the new cog. Normally one would just use a
global variable, but in this case the binary is not aware of C namespace. I had considered
mucking with the linker script or crtprop.s to define a predefined .shared data area.
Would this work? Is there a better way to share parameter address in this case?

Being able to do this may allow previously designed native asm only drivers to be used with C.

Would be nice to get VGA fast and free Richard [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley

Traffic is slow at times, but Parallax orders·always get here fast 8)

ImageCraft

jazzed said...
...

Problem is in interfacing with the rest of the program. The ImageCraft cognew library function
does not pass the address of parameter to the new cog. Normally one would just use a
global variable, but in this case the binary is not aware of C namespace. I had considered
mucking with the linker script or crtprop.s to define a predefined .shared data area.
Would this work? Is there a better way to share parameter address in this case?

Being able to do this may allow previously designed native asm only drivers to be used with C.

Would be nice to get VGA fast and free Richard [noparse]:)[/noparse]

We will change the native asm COGNEW library to accept one parameter to be placed in the PAR register. Do remember that C does not allow optional argument except in the case of stdarg function, so you will have to always pass something to it, e.g. 0. So the new function signature will be

int cognew_native(void (*func)(), int par);

I will let you know when we get it done.

Thanks.

// richard