catalina or imagecraft c compiler
Batang
Posts: 234
Has anyone have or done any comparisons between the catalina c compiler and the imagecraft one or which is the preferred one for propeller development.
Comments
If I could go back in time, I would seriously consider other options entirely.
Lots of gory details omitted ....
Thanks in advance.
I like an IDE/GUI based piece of software, I am not hard core liked jazzed, where dealing with a command prompt is an acceptable compromise. While I have dealt with command prompt type of software, it was for something that was quick, and dirty.
Ray
When you are working within the confines of a micro-controller the main issues are code size and execution time.
What difference does it make if one uses ones favourite editor to create the code along with make, or whether one uses whatever IDE comes in the package.
By the way, I understand Catalina does have an IDE now.
As a side question, I'm curious to hear of anyone who has used either compiler for a real Propeller project. Commercial or otherwise.
So far I have thought that C is not suitable for the Prop given it's propensity to eat space, whilst at the same time not delivering native execution speeds.
Yes, yes I know, "why are you working on Zog for zpu-gcc then, which is currently slower and bigger than Spin?" Well, you know, because it's there:)
ZOG is on my list because it was/is easier to incorporate my SDRAM solution there and it is a GNU/GCC tool chain which I prefer even though ZOG is still in development in some areas. Catalina is much more difficult to add the SDRAM platform code, and I have put off adding support because of Catalina's structural complexity. I've considered revisiting the concept for ICC, but my ZOG demo development is certainly more important than that. I will eventually finish the Catalina support if Ross is not too insulted by my sometimes less than tactful honesty.
The best C thing that Parallax can do IMHO is pay someone to provide a GNU tool-chain LMM port. That would show they are serious players. I doubt Parallax would ever do that though or even officially support a non SPIN/PASM tool chain except for that BASIC stuff which is really just a language variation of the same concept that serves Parallax's wider customers. SPIN/PASM is really the right fit for Propeller since it was designed to be that way from the start.
The current Propeller was not really designed for C - it's all kind of shoe-horned. The next generation Propeller will be a much better fit.
Fortunately, you don't really have to choose - if you use Catalina's catalina_icc.h header file in your program (to hide the difference between how ICC and Catalina handle the Propeller-specific operations and registers such as WAITCNT, LOCKNEW, INA, DIRA etc) - and otherwise restrict yourself to ANSI C - then you should be able to switch quite easily between the two compilers in most cases.
Heater mentioned the code size problem inherent in using LMM PASM. This affects both Catalina and ICC equally. But the next release of Catalina should go some way to resolving this. By offering a new two-phase loader, and also new smaller libraries, Catalina is down to using only a few hundred bytes of Hub RAM for a simple "hello world" C program - with the remaining Hub RAM (around 31kb) available for more C program code. This is better than either ICC or SPIN can currently achieve, since they both use the Parallax one-phase loader - which means that any space occupied in the binary by device drivers (e.g. display, keyboard, mouse, SPI, serial, etc) is unavailable as program code space. For example, if your program loads 7 cogs with drivers (using one for the main program execution) then this can consume up to 14kb of your Hub RAM - and this is the same whether you use Catalina, ICC or SPIN. However, with ICC or SPIN you would be left with only 18kb of Hub RAM available as program code space - but with Catalina you still have 31kb of Hub RAM available as program code space.
With this improvement, I think we may begin to see C being used more commonly for Propeller development - even on the Prop I. And of course my own view (completely unsupported by Parallax!) is that on the Prop II, C will become a complete no-brainer - after all, why would you use anything else? :smilewinkgrin: Except possibly for raw PASM when you absolutely need top speed (but this is always true on all architectures).
Ross.
P.S. for those who prefer to use an IDE over the command-line, Catalina offers Code::Blocks.
Just as an aside, to follow up on Jazzed "so that offers more flexibility and enables using OBEX C code at some point."
Do you think we might be getting close to asking parallax to host a C OBEX?
Dr A,
C code has been supported in the OBEX for a while:
Or where you thinking of a different type of hosting?
Cheers,
Jim
I agree with most of these comments (especially the "less than tactful honesty" part!
The only bit I'm not sure about is the utility of a GNU tool chain port. I was originally supportive of this idea (I considered doing one myself) but the more I learn about the Propeller, the more doubts I have about this being the right way to go. My current view is that yes this is the right approach for any general-purpose microprocessor, but no for a specialist microcontroller like the Propeller.
Catalina's complexity comes partly from my desire to make at least some use of all the Propeller's special features. A simple GNU port (i.e. one that doesn't do this, and instead simply targets a "vanilla" LMM VM) adds nothing to what Catalina can already do (or ICC for that matter) and could in fact be counterproductive. As soon as it appeared people would start wanting to port GNU-specific languages, libraries and applications to the Prop - and generally achieve very poor results. This could end up making the Prop itself look like it is the problem - and this would be grossly unfair!
Of course, we won't know for certain until someone actually finishes a GNU port. Zog looks like the likeliest bet here - but it still has a way to go yet!
Ross.
Regarding a "C" OBEX: yes, as Jim (hover1) points out there is already support for C in the OBEX. But it doesn't seem to get used much. I think this is partly because when using C one doesn't need as much support as you do when you are programming in SPIN or PASM. In those languages there is nowhere else you can go for support or code other than the OBEX (or these forums).
But when you are using ANSI C, the internet is in fact one vast OBEX!
Also, as Jazzed pointed out, Catalina is very complex - this partly because I tend to build everything you might ever need (device drivers, libraries etc) into Catalina itself - precisely so you never need to go to the OBEX.
Ross.
Of course I wouldn't claim Catalina's code generator to be better than (or even "as good as") GNU's code generator - but Catalina's Virtual Machine has been specifically tweaked to suit both the type of code generator that LCC mandates, as well as the types of programs that I want it to be good at executing - and also take advantage of the Propeller's special features where possible.
Between all of these (i.e. LCC, the Catalina code generator and the Catalina VM) - and especially with the Catalina Optimizer thrown into the mix - they do a pretty decent job.
But this is not a trivial task, and you would need to do the same with GNU - i.e. come up with a VM that is designed both to suit the GNU code generator and designed to take advantage of the Prop's special features wherever possible and designed to give good results for the type of program you intend to run.
A "vanilla" GNU port (i.e. one which targeted a fairly trivial LMM VM) could end up being quite inefficient in both performance and space.
Take Zog as a good example - it has the advantage that a bunch of people with a vested interest have spent some time working on a pretty good GNU code generator for it. But the ZPU "virtual machine" itself is not particularly well suited to being emulated on the Propeller. It was designed to require the least amount of silicon real estate rather than being a basis for a fast general purpose processor. The designers of the ZPU themselves say it is "not intended for sustained processing" and "not intended for Linux (or uCLinux)". It's architecturally unsuitable. That doesn't mean it can't be done - it just means it won't run as efficiently as you might like.
Ross.
Ok, I've gone through the obex and found a few C programs. I think jazzed has written most of them.
There are a few syntax things I'm not sure about, eg the dot thing which is in vb.net as well viz
gkb.tail = gkb.head; // reset queue
I'm not sure if the meaning of this is the same in C, but in .net, a . brings up a dropdown menu of choices, and hence helps glue lots of programs together.
It is exciting to see that C has made so much progress. When I first started programming the propeller, I was happy to make a led flash. Then I was happy with a keyboard. But now, I want more and more! For me, a 'minimum' program is something like KyeDOS, ie keyboard, mouse, vga display, fat32 drivers for an sd card, and the ability to chain other propeller binaries. I guess seeing all that working together is not just useful, but it gives a lot of clues about how to write more code. A particular example of that is how to combine pasm and another language.
As for imagecraft vs catalina, it is all a bit confusing at the moment. I need to do some more reading - C seems to be evolving in leaps and bounds.
In C this "." is struct (a cousin of class and object) notation. C# (step brother of C, C++, Java, and VB.net) uses "." for struct, class, and object. In ANSI C89 "//" is illegal but most decent compilers support it anyway.
I've never tried using any of the OBEX C code with Catalina ... it should be tested. Several examples use the in-line ASM syntax, so those will probably fail, and need to be re-written. Some of the examples such as the ASIO library will never work without the in-line ASM - the FDSerial library should be used instead.
This is all the diplomacy I can muster for tonight
The asm extension is always problematic. Any code that uses asm is (by definition) not portable - often not even between two compilers on the same machine. On the Prop it is even more problematic since each C compiler actually targets not only its own assembly language, but also its own virtual machine architecture! Instructions that are valid in one VM will be illegal in another - e.g. mov r23, #1 is valid LMM PASM for Catalina, but it is not valid for ICC, and can't even be expressed as an instruction in Zog!
The asm keyword is not included in the ANSI definition of C precisely because it is not portable - so naturally Catalina doesn't have it. I've thought about adding it (it's not that difficult) but I shy away every time - in my view, such language "extensions" always end up making programming harder, not easier. It is also a tactic some companies use to prevent you porting code away from their tools or platforms (I'm not implying this is ImageCraft's motivation - but there is a certain large and well known computer software vendor that is forever adding useless and non-standard extensions to all their tools and languages for exactly this reason).
Instead of asm, Catalina allows you to use standard C function call syntax, but write the body of the function in LMM PASM - and then use the inlining capabilities of the Catalina Optimizer to eliminate even the overhead of the function call. This gives you all the speed advantages of asm while leaving the C code as pure (and portable) as possible.
As far as I am aware, there is no Catalina-specific C code in the OBEX (strictly speaking, BlackCat is not written in Catalina C code - it is a tool that supports Catalina C code). All the existing C code in the OBEX is ICC-specific, and not much (if any) of it would be portable to any other C compiler.
While I'd like to see additional Catalina plugins in the OBEX, I'm not sure what category they should be in! They are SPIN/PASM code, not C - and will only support Catalina, not ICC. Should we then have ICC and Catalina specific sections of the OBEX? I don't think this is a good idea.
The OBEX is great for PASM and SPIN objects. I don't think it is extendable to other languages.
I honestly don't give a hoot if ASM is portable or not. At the time the code was written there was exactly one "native" LMM C compiler available for Propeller.
If you never intend to have Catalina share C code with/from the OBEX it is all irrelevant. This is of course a great disservice to open-ness.
No, Catalina doesn't have an inline keyword - the Catalina Optimizer statically analyzes the whole program as output by LCC (but before it is assembled by Homespun) and inlines wherever possible over the entire program - including any library code and hand-crafted LMM PASM. The Optimizer determines where it is safe to inline, and also where the resulting inlined version ends up smaller than the original version (i.e. it never inlines just to get a speed improvement - although I intend to add this option in a future release).
One day, I may have to add a means of instructing the Optimizer not to inline a particular function - but so far this has never been a problem. It would become a problem if (for example) another language wanted to call a C function that had been inlined.
Ross.
P.S. I think you may have misunderstood my post slightly - I'm not against putting C code in the OBEX - its just that most of the Catalina code I personally write ends up being included along with the compiler itself - so I have very little reason for doing so. I would certainly encourage others to contribute their C objects to the OBEX - but I think it is necessary to point out that unless the C code is strictly ANSI compliant, it probably won't compile under all the available C compilers. In such cases, perhaps we should make it a convention that the contributor include (in the description of the object) a list of the compilers the code is intended to be used with.
I do have the ICC. And I finished a substantial project with it. That was quite some time ago. 'Bout mid year of '09
During development, I found some bugs like that the float lib is always linked, even if it is not used. Or that the "optimizing" compiler adds something like ADD 0,#0 (completely useless).
I reported those errors about July '09 to imagecraft, but nothing happened (but I got replies).
> V7.04D March 26, 2009
That's the last version of ICC. I call this a dead product.
At that time, I tried Catalina but wasn't very happy. Now, I have to modify that ICC-code and I'll give Catalina a second try.
Nick
Let me know what problems you found with Catalina, and I'll see what I can do to fix them (they may already have been fixed - in mid '09 you would have been using quite an early version of Catalina!).
Ross.
I tried the trial version of ICC about a year ago, installation was simple, and straight forward. It has some example programs that you can just compile, and get the feel for how the software package would work for you.
With Catalina I started to read the instructions for installation, and that is where I quit. I did not want to invest the time in making sure the software was placed in the correct folder(s), and I did not want to deal with creating programs in some editor of choice, then deal with a tool chain of sorts to compile the program (a minimal batch file I suppose).
You will find that there is a lack of people that are developing programs in C for the propeller, and discussing it on the forum. So, if you run into any kind of problem, code wise, you may or may not get somebody to help you out. If you are a professional C programmer that may not be a concern to you.
Good Luck
Ray
Good advice.
Someone did create a Windows installer for one of the very early versions of Catalina (I can't remember who now) - but at the time Catalina was changing too rapidly to make it worth re-doing it for every release. Since the installation is fairly simple, I never bothered with an installer myself - but if you feel this to be a barrier for newcomers, I will consider doing one when I get time.
Ross.
My choice of words was "invest the time", not that it was a "barrier", lighten up on this fatalistic terminology, or the very least subtle implication that someone may not be smart enough. In 2010, most people, expect to double click on an installation icon, and then start the program up when the installation is complete. Again, keep thinking "invest the time".
Thanks
Ray
That was waaaaay too much back. I'll simply give it a fresh new try!
I think you made huge progress over one year. I'll report back ...
Nick
For sure that's true. And if you do it enough when developing code for different platforms it will eventually drive you insane.
Just now I have:
1) Propeller BST tool.
2) Android IDE for Java - basically Eclipse
3) Arduino IDE for C/C++
4) QtCreator for Qt C++ user interface development.
5) An IDE for C on STM32 ARM kit, works only on Windows, badly, and hence is not used and my STM 32 dev kit is useless brick.
5) IDE for C/C++/XC XMOS micro-controllers - basically Eclipse again.
etc etc
All of these IDEs have there own quirks require one to "invest time" to get used to. For example today I downloaded a new version of QtCreator that decided to put the compiled binaries in a new location causing some confusion for some time.
How much easier it would be just to use an editor of choice and the "make" command.
homespun.exe doesn't want to run:
OS: XP-pro, current patches.
homespun is 2009.10.05, size 144KB (from Catalina_2.6_Win.zip), patch 2.7 applied, but no newer version.
The message is (translated) something like "Application could not be properly initialized (0xc0000135)"
I'm sorry for such a low-lever question.
Nick