PDA

View Full Version : catalina or imagecraft c compiler



Batang
11-03-2010, 07:50 PM
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.

jazzed
11-03-2010, 09:01 PM
If I had to choose between the two, Catalina wins.
If I could go back in time, I would seriously consider other options entirely.

Lots of gory details omitted ....

Batang
11-03-2010, 09:17 PM
Does your view relate to code size, performance or other compiler issues i.e. bugs.

Thanks in advance.

Rsadeika
11-03-2010, 09:26 PM
If I had to choose, I would pick ICC.

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

Heater.
11-03-2010, 09:45 PM
I thought the question was about compilers not editors/IDEs.

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:)

David Betz
11-03-2010, 09:49 PM
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:)
Has anyone investigated building a GCC code generator that produces SPIN bytecodes? Is that even feasible?

jazzed
11-03-2010, 10:26 PM
Does your view relate to code size, performance or other compiler issues i.e. bugs.
My view relates to the perception that Catalina is alive and being constantly improved - I have always been disturbed by its complexity though. ICC is "what you see is what you get" and that's it; at some levels I prefer it's simplicity even with some of it's rough edges. I appreciate that ICC allows me to do what I want rather than using someone else's vision of what they think I need. Catalina has started using my method for including PASM blobs recently, so that offers more flexibility and enables using OBEX C code at some point.

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.

RossH
11-04-2010, 12:42 AM
If I had to choose between the two, Catalina wins.



If I had to choose, I would pick ICC.

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.

Bill Henning
11-04-2010, 02:30 AM
I think your two-phase loader is a HUGE win for Catalina.


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.

Dr_Acula
11-04-2010, 02:33 AM
I like catalina because the author is very responsive to adding new things.

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?

hover1
11-04-2010, 02:52 AM
I like catalina because the author is very responsive to adding new things.

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:

http://forums.parallax.com/attachment.php?attachmentid=74995&d=1288835735

Or where you thinking of a different type of hosting?

Cheers,
Jim

RossH
11-04-2010, 03:36 AM
My view relates to the perception that Catalina is alive and being constantly improved - I have always been disturbed by its complexity though. ICC is "what you see is what you get" and that's it; at some levels I prefer it's simplicity even with some of it's rough edges. I appreciate that ICC allows me to do what I want rather than using someone else's vision of what they think I need. Catalina has started using my method for including PASM blobs recently, so that offers more flexibility and enables using OBEX C code at some point.

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.

I agree with most of these comments (especially the "less than tactful honesty" part! :lol: ).

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.

RossH
11-04-2010, 03:46 AM
@Dr_Acula,

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.

David Betz
11-04-2010, 03:47 AM
RossH: Is there something inherently better about LCC that makes it better at developing an efficient code generate for the Propeller LMM or is it just that you've put a lot of effort into this and it's unlikely to be duplicated by someone building a backend to GCC? Is GCC just bad at targeting non-standard architectures?

RossH
11-04-2010, 04:42 AM
Hi David,

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.

Dr_Acula
11-04-2010, 05:09 AM
Thanks hover1.

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.

jazzed
11-04-2010, 05:36 AM
gkb.tail = gkb.head; // reset queue


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 :)

RossH
11-04-2010, 06:25 AM
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.

jazzed
11-04-2010, 06:36 AM
So you support the inline keyword (not ANSI-C89 either) ? If not, how do you inline?

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.

RossH
11-04-2010, 06:59 AM
Jazzed,

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.

Nick Mueller
11-04-2010, 12:42 PM
Hi!

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

RossH
11-04-2010, 01:47 PM
Hi 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.

Rsadeika
11-04-2010, 01:57 PM
@Batang, if you are serious about using C, I would suggest installing both products, and trying it out yourself.

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

RossH
11-04-2010, 02:06 PM
@Batang, if you are serious about using C, I would suggest installing both products, and trying it out yourself.

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.

Rsadeika
11-04-2010, 02:21 PM
"but if you feel this to be a barrier for newcomers, I will consider doing one when I get time."

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

David Betz
11-04-2010, 02:52 PM
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.
Yeah, that's kind of disappointing. I've seen a fair amount of discussion of how to implement C on the Propeller or discussing various implementations but not much evidence that anyone is actually writing significant C application code on the Propeller. I have Catalina C and like it very much. Unfortunately, my C code is too bloated to fit in 32k of hub RAM and I don't have a compatible external RAM that I can use to extend my address space.

Nick Mueller
11-04-2010, 03:07 PM
> Let me know what problems you found with Catalina,

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

Heater.
11-04-2010, 03:33 PM
Rsadeika,


In 2010, most people, expect to double click on an installation icon, and.....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.

jazzed
11-04-2010, 06:00 PM
How much easier it would be just to use an editor of choice and the "make" command.
Yup, and when you want to use the serial port *in the same window* just add that application to the build script. :!!


bstc.linux -ls -f -Orx -p0 -L ~/spin $1
nanocom /dev/ttyUSB0 -b 57600

Heater.
11-04-2010, 06:17 PM
Yep, been there done that, but with gtkterm in it's own new window.

Nick Mueller
11-04-2010, 07:04 PM
Ross, sorry, I didn't come too far.

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

ImageCraft
11-04-2010, 09:15 PM
ICC Development is on hold. As a commercial company, we need to pay bills with income from sales of our products. For the time being, Prop I C compilers are not entirely commercially viable, mainly due to factors beyond our control.

When Prop II is released, we will revisit the decision.

And I dispute greatly that a GCC port will help in any way. ZOG is all you need to move in their direction. So is ZOG a success for commercial development? If so, then yes, GCC is what people want.

A Prop 1.5 with 64 IO pins will greatly help in creating a usable fast expanded SRAM solution. However, that is unlikely to come from Parallax. So we will wait for Prop II, hopefully no like Godot :-)

// richard

dnalor
11-04-2010, 10:01 PM
... mainly due to factors beyond our control...
// richard

No! It`s because of the LMM.

Nick Mueller
11-04-2010, 10:22 PM
ICC Development is on hold.

May I put this in contrast to quotes from ImageCrafts home page?

"You are not buying a compiler, you are buying unparalleled support."
"Richard is maniacal in support." -- Jack P.
"Support from Imagecraft is second to none." -- Andrew

Until now, not even the included help files match those on the ICC web-site.
After more than a year.

And:
"optimizations"
I do not think a compiler site does optimizations when he links an unreferenced library (float) and emits useless opcodes. The linker only links complete compilation units, even unused functions.

Richard, if you don't fix those things (you got my list), "Prop I C compilers are not entirely commercially viable". No wonder.


Nick

jazzed
11-04-2010, 10:32 PM
@Nick, homespun requires .net ... do you have that installed?

@dnalor, can you explain what you mean?

Heater.
11-04-2010, 10:37 PM
Zog is very pleased to get so many mentions in a discussion between such esteemed participants. He will now get back to sleep contentedly in his iceberg.

Richard,


....mainly due to factors beyond our control.
I still maintain that:
1) We love the Prop and it's "out of the box" architecture.
2) Us hard core C heads love to have C on the Prop.
3) C is not actually practically useful on the Prop.

The thing that frustrates us is that 3) is due to 1).

C on the Prop is like a dog doing tricks, as they say, the wonder is not that it does it well but that it does it at all.

C on the Prop lacks the native speed that C users are used to whilst at the same time being rather wasteful of space. It's rather a hard sell when up against Spin and PASM.

The lack of a Prop I with 64 IO's and hence easy program space expansion is heartbreaking but I suspect it's time has well and truly passed.

We look forward to Catalina and ICC on the Prop II where C can breath more easily.

But watch out, Zog will be there watching you:)

David Betz
11-04-2010, 10:51 PM
Unfortunately, even with Prop II, it seems that C will still be challenged on the Propeller. Yes, we will have more hub RAM and more I/O to connect external RAMs. However, how fast will C code running from either run compared with C code running native on any other 32 bit or even 16 bit microcontroller. It may be that C is still not a viable language for the Propeller even with Prop II. I'd still like to see an architecture more like the Cell where the COGs are used for what they are good for, virtual peripherals, and a more standard CPU core (ARM maybe) is also available to run the main loop.

ImageCraft
11-04-2010, 10:57 PM
May I put this in contrast to quotes from ImageCrafts home page?

"You are not buying a compiler, you are buying unparalleled support."
"Richard is maniacal in support." -- Jack P.
"Support from Imagecraft is second to none." -- Andrew

Until now, not even the included help files match those on the ICC web-site.
After more than a year.

And:
"optimizations"
I do not think a compiler site does optimizations when he links an unreferenced library (float) and emits useless opcodes. The linker only links complete compilation units, even unused functions.

Richard, if you don't fix those things (you got my list), "Prop I C compilers are not entirely commercially viable". No wonder.


Nick

Nick, when you throw in real development budget and not get a reasonable return, then we can talk. We can do all those but it's throwing more money at a problem not by us.

And if anyone thinks LMM is the problem, they can feel free to hack small C or LCC to target COG.

C can shine on Prop 1.5 or Prop II. Until then.

Notice no one is making real money on software tools for the Prop, as far as I know. I might very well be wrong of course. Give me proof please.

We knew the risks coming in. We got burned. Not a problem. We win some, we lose some. Live and learn.

Anyone else who think they can solve the C for Prop problem for a commercially viable product, feel free. Go for it!

Nick Mueller
11-04-2010, 11:03 PM
@Nick, homespun requires .net ... do you have that installed?


Jazzed, you do have a perfect crystal ball!
It worx.


Nick

Nick Mueller
11-04-2010, 11:12 PM
Nick, when you throw in real development budget and not get a reasonable return, then we can talk.

Then you simply should stop selling ICC Prop. 272.51 waisted.
Also very simple: Lesson learned, no ImageCraft products.


Nick

Nick Mueller
11-04-2010, 11:21 PM
However, how fast will C code running from either run compared with C code running native on any other 32 bit or even 16 bit microcontroller. It may be that C is still not a viable language for the Propeller even with Prop II.

I don't think so, but I do like C.
ICC-code runs quite fast, compared to Spin. But of course, slower than ASM. If your code has a good balance between C and ASM you do have all advantages of both worlds. Extremely fast code in ASM that does some sub-tasks that are time-critical, yet small enough to be coded in ASM and on the other hand better abstraction with C.

C on the Prop is a failure like any other language. :smilewinkgrin:


Nick

ImageCraft
11-04-2010, 11:25 PM
Then you simply should stop selling ICC Prop. 272.51 waisted.
Also very simple: Lesson learned, no ImageCraft products.


Nick

I will refund your money. Email me.

Nick Mueller
11-04-2010, 11:38 PM
I will refund your money. Email me.

No thanks. I bought it, that's it. Lesson already learned.


Nick

RossH
11-05-2010, 12:01 AM
Ross, sorry, I didn't come too far.

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

Hi Nick,

No worries about the question. It's exactly things like this that I need to find out. In this case (as jazzed already pointed out) it's because you don't have .NET installed. You need to install the Microsoft .NET Framework Version 2.0 Redistributable Package (x86) (here (http://forums.parallax.com/Microsoft%20.NET%20Framework%20Version%202.0%20Red istributable%20Package%20%28x86%29)). Note that you need 2.0 even if you have a later version installed.

It never occured to me that someone might not have this installed under Windows. I'll add a note to the Catalina documentation.

Ross.

Phil Pilgrim (PhiPi)
11-05-2010, 12:18 AM
It never occured to me that someone might not have this installed under Windows.
A lot of us either can't install .NET (WinXP SP1) or simply refuse acquiescence to the bloat that it entails.

-Phil

David Betz
11-05-2010, 12:32 AM
I don't think so, but I do like C.
ICC-code runs quite fast, compared to Spin. But of course, slower than ASM. If your code has a good balance between C and ASM you do have all advantages of both worlds. Extremely fast code in ASM that does some sub-tasks that are time-critical, yet small enough to be coded in ASM and on the other hand better abstraction with C.

C on the Prop is a failure like any other language. :smilewinkgrin:


Nick

Well, not a failure, just not always the best choice I suppose. You have to match the language with the problem I guess. Spin and PASM will certainly be the best languages for the Propeller and probably also the Propeller II. It's just that sometimes you want to port something that was written in a more traditional language like C and then it helps to have that option available as well.

RossH
11-05-2010, 12:46 AM
Unfortunately, even with Prop II, it seems that C will still be challenged on the Propeller. Yes, we will have more hub RAM and more I/O to connect external RAMs. However, how fast will C code running from either run compared with C code running native on any other 32 bit or even 16 bit microcontroller. It may be that C is still not a viable language for the Propeller even with Prop II. I'd still like to see an architecture more like the Cell where the COGs are used for what they are good for, virtual peripherals, and a more standard CPU core (ARM maybe) is also available to run the main loop.

Hi David,

As you might guess, I disagree with this view :smilewinkgrin: (and also with Heater's comment that "C is not actually practically useful on the Prop").

I think C is quite functional on the Prop I for what the Prop was originally intended for - i.e. small embedded applications that need a very flexible microcontroller. The problem is that many of us (including me!) are trying to run operating systems and other large applications that are more suited to a microprocessor. And when the results are mediocre (compared to what is possible on other microprocessors) we tend to blame either the tools or the architecture of the Propeller - very few of us will acknowledge that we were probably being a bit dumb to attempt such things in the first place (including me, naturally!).

This is the point I was trying to make earlier about a GNU port to the Propeller - the first thing some of us would try to do is download the Linux sources and attempt to compile the Linux Kernel - and when this turns out to be impractical we will either blame the quality of the port or (worse!) blame the Propeller itself. The Propeller is not a general purpose microprocessor, and it is not a transputer. If what you really needed was one of those, then the Propeller is always going to be a second-best solution.

If you wonder why Parallax has not rushed off to do a GNU port then it may be because they knew this already, and also that they would be on a hiding to nothing.

I maintain that C is fine on the Prop I if used where it is appropriate to do so - and also that it will be even better on the Prop II!

Of course, I realize I am usually in a minority of one here - I'm used to that :lol:.

Ross.

RossH
11-05-2010, 12:48 AM
A lot of us either can't install .NET (WinXP SP1) or simply refuse acquiescence to the bloat that it entails.

-Phil

Hi Phil,

I can certainly understand this! Unfortunately, there's not much I can do about it right now. I have plans to also support bst as an alternative assembler to Homespun, but it's a matter of finding the time.

Ross.

Rayman
11-05-2010, 12:54 AM
ICC Development is on hold.

When Prop II is released, we will revisit the decision.

// richard

I think a C compiler will be a lot more important for Prop2.

David Betz
11-05-2010, 01:34 AM
I maintain that C is fine on the Prop I if used where it is appropriate to do so - and also that it will be even better on the Prop II!

Of course, I realize I am usually in a minority of one here - I'm used to that :lol:.

Ross.
I agree that C is fine on the Propeller for certain applications. It's just that the Propeller is not likely to be the best microcontroller for running C programs where very high performance is necessary.

ImageCraft
11-05-2010, 01:45 AM
No thanks. I bought it, that's it. Lesson already learned.


Nick

I can assure you that we learned our lessons much more with the money we spent on developing and support the Prop. If we have only lost $249.00....

jazzed
11-05-2010, 01:50 AM
If you wonder why Parallax has not rushed off to do a GNU port then it may be because ....

1) Parallax is primarily a BASIC/Delphi shop (core competency).
2) Propeller is only serious for small things regardless of what we do (right-sizing).
3) There are lots of alternatives that already do industry standard GNU (staying in the niche).
4) Basic stamp customers don't want to learn C (repeat customers)
5) Chip and others would have less creative outlet (happy staff).
6) Ross and Richard would have less opportunities to compete (vendor relationships).

David Betz
11-05-2010, 01:57 AM
I guess all of this talk has been hyphothetical. It would be nice to hear from people who are using C on the Propeller for something other than running benchmarks. What has your experience been like? Has it worked well for you? How could the various C compiler options be improved?

I haven't tried ICC but I have used Catalina and have been playing with GCC/ZOG and I've had a lot of fun with both. I have successfully built and run a simple Basic bytecode compiler under ZOG (had to split it into three phases to get it to fit in 64k of SPI SRAM). I'd love to try it under Catalina as well but I have to setup a system with a big external RAM before I'll be able to do that.

What projects have others done?

Bill Henning
11-05-2010, 02:10 AM
I simply use the tool that is required to accomplish the task at hand.

With the Prop, that usually means Spin+PASM, however I did play a bit with both Catalina and Gcc for Zog - and like both.

Right now, I am concentrating on hardware and consulting, so I have put PropellerBasic on hold - and frankly, I don't think there is a market for a commercial optimizing LMM Basic compiler yet.

As soon as I am done with the boards I showed at UPEW, I will resume work on a large VMCOG - which will support a mix of SPI ram/flash for a really big VM.


I guess all of this talk has been hyphothetical. It would be nice to hear from people who are using C on the Propeller for something other than running benchmarks. What has your experience been like? Has it worked well for you? How could the various C compiler options be improved?

I haven't tried ICC but I have used Catalina and have been playing with GCC/ZOG and I've had a lot of fun with both. I have successfully built and run a simple Basic bytecode compiler under ZOG (had to split it into three phases to get it to fit in 64k of SPI SRAM). I'd love to try it under Catalina as well but I have to setup a system with a big external RAM before I'll be able to do that.

What projects have others done?

RossH
11-05-2010, 02:16 AM
I guess all of this talk has been hyphothetical. It would be nice to hear from people who are using C on the Propeller for something other than running benchmarks. What has your experience been like? Has it worked well for you? How could the various C compiler options be improved?

I haven't tried ICC but I have used Catalina and have been playing with GCC/ZOG and I've had a lot of fun with both. I have successfully built and run a simple Basic bytecode compiler under ZOG (had to split it into three phases to get it to fit in 64k of SPI SRAM). I'd love to try it under Catalina as well but I have to setup a system with a big external RAM before I'll be able to do that.

What projects have others done?

... and suddenly was heard the sound of one hand clapping ... (http://wiki.answers.com/Q/What_is_the_sound_of_one_hand_clapping)

David Betz
11-05-2010, 02:16 AM
As soon as I am done with the boards I showed at UPEW, I will resume work on a large VMCOG - which will support a mix of SPI ram/flash for a really big VM.
Cool! That is just what I need to be able to merge my three phase compiler along with its VM and an editor back into a single executable that can live in flash. I'm looking forward to porting your large memory VMCOG to the C3!

jazzed
11-05-2010, 04:17 AM
Everything I've done for Propeller was in Spin/PASM except for porting some drivers for C. The problem is I constantly run out of memory ... LMM C can not compete with SPIN for compactness. Period. External memory platforms so far have horrible economics. So I slog on trying to find better solutions. Sorry I'm so hard to please.

This thread like many others on C can be entertaining, but they usually don't achieve anything good. So now my first comments on this thread can be taken in full perspective :)

What new things have we learned?

1) Catalina has made some progress with making more memory available.
2) ImageCraft states that ICC for Propeller is not a viable product.
3) Not everyone likes .net :)
4) Apparently there are very few people writing Propeller applications in C.

RossH
11-05-2010, 04:36 AM
Everything I've done for Propeller was in Spin/PASM except for porting some drivers for C. The problem is I constantly run out of memory ... LMM C can not compete with SPIN for compactness. Period. External memory platforms so far have horrible economics. So I slog on trying to find better solutions. Sorry I'm so hard to please.

This thread like many others on C can be entertaining, but they usually don't achieve anything good. So now my first comments on this thread can be taken in full perspective :)

What new things have we learned?

1) Catalina has made some progress with making more memory available.
2) ImageCraft states that ICC for Propeller is not a viable product.
3) Not everyone likes .net :)
4) Apparently there are very few people writing Propeller applications in C.

5. Lots of people want to use C on the Propeller (I and II)
6. Catalina will continue to innovate on the Prop I
6. Catalina will be the logical choice of language for the Prop II :)

Nick Mueller
11-05-2010, 08:24 AM
It would be nice to hear from people who are using C on the Propeller for something other than running benchmarks.

I have implemented a Modbus-client. This Modbus-interface does most of the digital IO for my MAHO 700C mill. 3.1 tons, not a toy! The original control was broken, so I replaced it with EMC2. Right now, I designed a different Modbus-interface (more compact, with LCD) that will go into the hand wheel (= remote handle with a jog wheel, some push buttons, rotary switches and LEDs).

Response time is critical in this application, so SPIN was no option for me (it isn't an option for me anyhow).

Extending the Prop with external RAM for code is -in my eyes- useless. It's a crutch. It works, but is not well integrated. It simply is beyond the capabilities of the Prop. Yes, some got this working. But that doesn't mean it's an elegant solution.


Nick

David Betz
11-05-2010, 02:52 PM
I have implemented a Modbus-client. This Modbus-interface does most of the digital IO for my MAHO 700C mill. 3.1 tons, not a toy! The original control was broken, so I replaced it with EMC2. Right now, I designed a different Modbus-interface (more compact, with LCD) that will go into the hand wheel (= remote handle with a jog wheel, some push buttons, rotary switches and LEDs).

Response time is critical in this application, so SPIN was no option for me (it isn't an option for me anyhow).

Extending the Prop with external RAM for code is -in my eyes- useless. It's a crutch. It works, but is not well integrated. It simply is beyond the capabilities of the Prop. Yes, some got this working. But that doesn't mean it's an elegant solution.


Nick
Which compiler did you use? I'm assuming you used ICC based on your earlier posts. I kind of agree that a compiler is less likely to be adopted if it puts constraints on the platforms it runs on. Requiring lots of external RAM probably eliminates a large part of the target audience. That's one reason I've been playing with GCC/ZOG. Even though I'm currently using 64k of external SPI SRAM, I have been able to write programs that run entirely in hub RAM. I guess internal memory space will improve with Propeller 2.

Nick Mueller
11-05-2010, 03:23 PM
I guess internal memory space will improve with Propeller 2.

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

Dave Hein
11-05-2010, 04:13 PM
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.

Dave

Nick Mueller
11-05-2010, 04:32 PM
This implies that they have very little interest in supporting C.

And the result will be less acceptance in the commercial field.


Nick

Leon
11-05-2010, 05:11 PM
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.

David Betz
11-05-2010, 09:09 PM
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.

RossH
11-06-2010, 01:22 AM
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.

RossH
11-06-2010, 03:01 AM
a) when will Prop II happen?
b) after a), how long will it take for the RAM to be insufficient again?
Nick

a) I reckon late next year for the Prop II.
b) Almost immediately :)



@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 (http://bytes.com/topic/c/answers/216333-binary-constant-macros):


/* 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))
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:

B8 = 00000055
B16 = 0000AA55
B32 = 80FFAA55This is why I love C!

ImageCraft
11-06-2010, 04:37 AM
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.

Phil Pilgrim (PhiPi)
11-06-2010, 04:56 AM
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.

-Phil

RossH
11-06-2010, 05:11 AM
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.

Ross.

Heater.
11-06-2010, 08:57 AM
Nick Mueller,



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.

Heater.
11-06-2010, 09:32 AM
RossH,



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 know, I know...just dreaming again.

RossH
11-06-2010, 10:19 AM
RossH,

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).

Ross.

Nick Mueller
11-06-2010, 10:47 AM
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.


Nick

RossH
11-06-2010, 11:33 AM
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.

Heater.
11-06-2010, 12:06 PM
RossH,

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:



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.

Dave Hein
11-06-2010, 12:50 PM
...
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.

David Betz
11-06-2010, 01:41 PM
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?

Heater.
11-06-2010, 03:39 PM
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:)

Nick Mueller
11-06-2010, 03:49 PM
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.


Nick

dnalor
11-06-2010, 05:02 PM
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).

Heater.
11-06-2010, 06:21 PM
Nick,




That is even worse than a p-machine. :)


Almost as bad as Java:)



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 (http://homepages.cwi.nl/%7Esteven/pascal/book/10pcode.html)

Bean
11-06-2010, 06:39 PM
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.

Bean

jazzed
11-06-2010, 07:12 PM
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.

Nick Mueller
11-06-2010, 07:40 PM
Almost as bad as Java

Haha! Good one!



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.


Nick

RossH
11-07-2010, 01:18 AM
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!).

Ross.

william chan
11-07-2010, 01:38 AM
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?

Heater.
11-07-2010, 01:47 AM
william chan


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.

RossH
11-07-2010, 03:04 AM
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.

Heater.
11-07-2010, 07:18 AM
RossH,

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.

RossH
11-07-2010, 09:14 AM
RossH,

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.

Dr_Acula
11-07-2010, 12:37 PM
Heater said By the way, I understand Catalina does have an IDE now.

Yes, here is a screenshot of one in action. See the Catalina thread for what it took to get this far.

1) One button to compile/download/save on an sd card/run
2) Code all running in external 512k sram
3) hub ram free for video buffers or other uses
4) two pass loader - load the cogs first, then reload hub ram. No wasted hub ram left over from loading cogs (which can be over 40% of the space in spin)
5) uses a vga display, keyboard, two serial ports and an sd card with gigabytes of storage

We may not have Big Spin, but we do now have Big C.

I was so excited when CP/M enabled C to go from 32k up to 50k of code space. But this takes it up to 512k. Who knows where it may end?

Heater.
11-07-2010, 01:44 PM
Dr_A,

That's great. I have been eagerly following your progress.

As you see, Catalina is a phenomenal piece of work. There is lot's of gold in it's huge directory tree. A compiler, loaders, lot's of platform support, most of an OBEX etc etc. I fear you might be giving up CP/M and BDS C very soon:)

One button compile will come to Zog when I get hold the Arduino IDE for ZPU but is not a high priority for me.

512K, pah small fry, Zog is living in 32MBytes:) But I still want to get Zog working on the DracBlade via VMCog.

Zog can have all HUB RAM free to.

VGA display is something Zog desperately needs.

Yep, we have had big C for some time. Looks like you are all set with Catalina.


Who knows where it may end?


Indeed, there is a lot happening here. Jazzed wants to get uCLinux running on the Prop, Crazy. I'd be happy with FreeRTOS. Whe we get to Prop II things will go orbital yet again.

RossH,

Happy birthday. Welcome to the "Old Geezers Club":)

David Betz
11-07-2010, 02:31 PM
Then it needs some file I/O which David has done again just using Spin for the FAT because it's there.
Actually, I'm using C code now to do FAT file I/O. I only use Spin code for raw sector I/O. The FAT code I'm using supports both FAT16 and FAT32 and can handle multiple open files at once. I didn't write it but I made a few minor changes to get it to compile cleanly.

jazzed
11-07-2010, 05:19 PM
Actually, I'm using C code now to do FAT file I/O. I only use Spin code for raw sector I/O. The FAT code I'm using supports both FAT16 and FAT32 and can handle multiple open files at once. I didn't write it but I made a few minor changes to get it to compile cleanly.
Very nice David! When will we see a new ZOG package with this?

David Betz
11-07-2010, 06:04 PM
Very nice David! When will we see a new ZOG package with this?
I have to figure out why my cache interface is flakey. I did some more testing and determined that it is the call to siprintf in hello.c that is failing. I suspect there is a bug in my cache code but I haven't been able to find it yet.

Bill Henning
11-07-2010, 06:56 PM
I feel your pain - I remember that VMCOG bug that took practically forever to find!


I have to figure out why my cache interface is flakey. I did some more testing and determined that it is the call to siprintf in hello.c that is failing. I suspect there is a bug in my cache code but I haven't been able to find it yet.

David Betz
11-07-2010, 07:00 PM
What terminal emulator are people using? It seems that all of the programs I download or get from other people assume they can send a linefeed character ("\n") to get to the start of the next line but the terminal emulators I use (putty), emulate a hardware terminal where it is generally necessary to send "\r\n" to get the start of the next line. I'd like a terminal emulator that works well with the Propeller conventions of just "\n" but also has a way to capture the terminal output so I can paste it into a forum message if necessary. Any suggestions?

Nick Mueller
11-07-2010, 07:14 PM
RealTerm is good and does a lot of things. But it looks a bit odd.


Nick

Dr_Acula
11-07-2010, 10:22 PM
@David, I wrote my own terminal emulator, but even when given the choice, I chose to copy standard terminal conventions rather than propeller conventions. My reasoning is that there are two different characters that come from the teletype/typewriter world. Linefeed means move up one line. Carriage return means move the carriage (the big thing that types on a typewriter) to the return position.

It has meant in the past that I've had to rewrite huge amounts of propeller code, but at least the code then works with all terminals (except the propeller one).

jazzed
11-08-2010, 05:10 PM
I'd like a terminal emulator that works well with the Propeller conventions of just "\n" but also has a way to capture the terminal output so I can paste it into a forum message if necessary. Any suggestions?
I've been using a custom variation of "nanocom" on linux (no windows) that has a "-n" option to allow LF->LF+CR newlines. It also has the ability to detect a user specified string and exit if found "-x string". That allows for timing measurements or just letting me get back to editing in the same window after I've seen enough output. Copy/paste is easy since the program runs in a command window.