Quick Status Update of ImageCraft Propeller C
ImageCraft
Posts: 348
Hi, just thought I owe you all a quick status update: ImageCraft Propeller C beta is late :-( Basically we had some resource scheduling issues and one of the main pieces that we were going to use (the assembler and linker), is based off a new asm/linker that we were developing for the ARM tools. The ARM asm/linker ran into some stability issues so everything just got bumped off down the road a bit. I have now re-allocated some resources and the Propeller C is the highest priority new development here at ImageCraft. When I have a better sense of when the beta will be available, I will post here.
Thank you for your patience. Feel free to contact me richard @ imagecraft.com if you have any comments and suggestions.
// richard
Thank you for your patience. Feel free to contact me richard @ imagecraft.com if you have any comments and suggestions.
// richard
Comments
****
The assembler handles
Instructions ( Cog Control, Flow control, Main Memory Access, Common Operations )
Relocation
Symbol resolution
Effects and Conditions
ORG Directive
Following are the TBD tasks:
Directives FIT and RES.
Process control instructions.
Unary and binary operators
Macros.
****
Some kind of alpha look-see may be available by the end of Dec. Since we are leveraging a lot of our existing code base, once things start moving, it should go pretty fast.
Will keep the forum updated as warranted. Thank you for your patience.
// richard
in my opinion 25%...50% of the strength of the propeller lies in this forum and the code: spin and assembler, that is already there for very different questions. Is there any chance to use the spin system and your compiler together? For example translate a c-source to a assembler module to be included into a spin program?
Christof
Thanks,
Joel
That's a laudable goal. In theory, one can take a C translated asm module, and if it doesn't use the C library functions, include it to their own spin/asm program. We will try to make our asm syntax as compatible as with the existing asm as possible, but the big issue is that we will (at first) generating Large Memory Model code, so the generated asm is relying on a C Virtual Machine (*) running on the COG.
Of course going the other way of incorporating existing asm modules into C projects are supported. In fact, the hope is that most existing Propeller objects will be translated for use under the ICC environment and we will do everything possible to facilitate that.
(*) Again, this is a low overhead VM and not a byte code interpreter ala SPIN. The performance goal is 2x to 4x slower than asm code.
We support most C99 functions except some esoteric math (bessel) and stdio where it relies of a file system. Most of our libraries are written in C and can be ported easily. We write certain heavily loop oriented functions like strcpy in asm to get the max. speed.
Since the SD interface seems to be popular, at some point, we will support that too, one way or another.
What is most exciting is that you appear to have filtered all of the feedback and come up with a development model that will not only speak to your customer base but also add real heterogeneity to the tool set. An introductory text-book to C based on your product would be
a real asset. Even professors are sometimes reluctant to embrace yet another new language. But given the opportunity of using the Prop and C together, I don't see how a real teacher could resist it.
Rich
I believe that "You can program it in C" draws people in and if they give Spin a try they will most likely switch to it since it is so well integrated with the hardware. I have had a hell of a time convincing friends to try the prop since it cannot yet be programmed in C from a Linux machine (yes... my buddies are purists).
Thanks,
Joel-
You misunderstand the relationship between Spin and Assembly language. Essentially there is no mechanism for interleaving C and Spin. Some of the assembly routines contained in the various I/O drivers could be copied over to ImageCraft's assembler and modified to use C interfaces rather than Spin interfaces, but that would have to be done by someone and probably would not be done for the initial releases because of the time and effort involved. ImageCraft has also talked about optionally targeting code that would run in a cog directly rather than by using the Large Memory Model interpreter. It's also not clear whether they will have that capability in initial releases although that would ease the conversion of many of the I/O drivers to a mixture of C and assembly.
My question about interleaving C and SPIN (not C and Assembly) isn't the main idea of the question.· That's just a non-compiler guy like me asking a question about how something will be implemented.· The main idea of the question is what library support is available to support the high level functions that we currently enjoy from the SPIN object exchange today.· If I write a program in C for the Prop, I really want access to high level functions to take advantage of the chip.· If I bother to use a C compiler, I expect that it will have a useful library of I/O functions that take advantage of the underlying hardware.· Some of the items in the object exchange would make a great set of primitives.·Based on the response so far, it appears that·there are no plans to provide this type of high level library support.· That is too bad.
In order for the C compiler to be useful to the general developer population, it needs some high level and interesting primitives to thrive.· I think the SPIN object exchange meets that need for all of us as SPIN developers.· But if you replace SPIN with C, you need something to replace those high level objects for the C developers.··
Joel-
·
Much as existing Large Memory Model ideas would co-exist alongside other Cogs running the Spin interpreter or Assembler, would C object code be usable in the same way ?
My large model work has been significantly hobbled by having to "trick" spin; that's why I've been working on a large model macro assembler / linker.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Well, Joel, the only official ImageCraft spokeperson is... me, so you couldn't have known what the official ImageCraft response is
First: I'd think everyone would agree that having the high level objects available to the C programmers would be a good thing. Regardless how it is implemented, they will appear to the C program as library functions.
As for How it will be implemented, my current understanding with SPIN / Propeller etc. is that a clean implementation in C or asm is probably what we are looking at, and not somehow executing SPIN code. This may change but my guess is that it is just a lot easier this way.
As for When and Who, our primary goal right now is get a working compiler. As you may know, we are sort of late already, so this is definitely not a First Release item. Once we get the compiler out the door, we will throw some resources at the problem, and who knows, may be we can even get some help from the community and may be even Parallax itself. We shall see.
Thanks for your interest.
// richard
The worst case scenario ( if there were address incompatibilities or conflicts ) would be someone had to write a Spin interpreter in C which would then run in its own Cog and interpret the embedded Spin .binary code making sure it didn't step on the C object code.
Alternatively, and perhaps easier ... if the ImageCraft object code is not encrypted or can be decoded it shouldn't be that hard to determine the C-kernel code or memory layout expected by it, modify/rewrite that, include and launch the new C-kernel from Spin and let it run. That's really no different to running any LMM code from a Spin program.
I do not see why Ram cannot be split between the two, Spin and C, and the two co-exist with their user PC and configuration dataset origins at different locations. Because the C implementation is entirely software that's likely the easiest to adjust. Only if the C object code used particular absolute addresses would there be an issue and even that could be overcome.
If ImageCraft and Parallax could work together on that it would save a lot of end-user hacking effort ( although some may relish the idea of achieving it themselves ! ). I wouldn't want to see the C compiler delayed though because of any integration issues, that can always be resolved and implemented later.
If any of that happens, it will be very unfortunate. We do not need more obscurity, ... in that case we are better with an open source approach.
Did anybody attempt a port of gcc to a new uP before ? (It is quite tricky).
edit: corrected lousy mistake.
Post Edited (Ale) : 12/5/2007 4:02:58 PM GMT
I certainly have not. However, regardless of the possibly gargantuan effort required to port gcc to the Prop, suppose for a minute it can be done. A well-working GCC port would be a _huge_ asset to anyone with an interest in the propeller (and assuming the architecture doesn't change overmuch, the prop2 as well).
That said, perhaps a less tricky option would be to port sdcc: sdcc.sourceforge.net/
However that would still require thousands of lines of laborious (and since it is gpl'ed, self-less) work.
Someone up to the challenge?
Nah, Propeller is relatively easy. The worst is designing the runtime architecture...
As for object code etc.: it's not encrypted.
As for integrating Spin and C: it may be possible, lets wait and see.
As for GCC and SDCC: feel free to try. Good luck.
Don't forget. The C compiler includes an assembler. A combination of C and assembly works just as well as a combination of Spin and assembly for drivers.
The C code, of course, still exists and presumably will run with the ImageCraft compiler.
A number of I/O drivers with tight timing constraints like the VGA/TV drivers will still need to have their assembly portions in assembly language. Since ImageCraft's C compiler includes an assembler, they should be convertable into a mixture of C and assembly with the assembly portion pretty much unchanged.
Compiler:
- All non-floating point operations supported
- need to do: function entry / exit code
- need to do: register allocator tuning, peephole, codegen optimizations
Assembler:
- all instructions, effects etc. supported
- most directives supported. Memory area attributes need to be done
- operators not yet supported
Linker:
- Most relocations done
- need to support library files
Library
- at the minimum, need to support mul and div/mod
C machine LMM kernel
- Design mostly complete, coding to be started
IDE
- not yet started, need Propeller download utility
// richard
Programming in C
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK