ICCV7 ImageCraft vs Catalina
Mike Huselton
Posts: 746
I am building a decision matrix to help me decide the pro's and cons of each compiler. Assume ICCV7 is free for argument's sake.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Comments
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
Still, someone asked the other day if my C-based spin debugger could be compiled with Catalina. The debugger is built with several .c files which makes it easy to build for Linux/Cygwin or Windows. Looking at the demo examples, I did not find one compiling and linking more than one file, so my first impression is that Catalina can not compile and link two or more files. RossH, if this is wrong, please correct me by offering an example.
RossH has worked out how to do XMM and the EMM Propeller specific mode with Catalina. This is theoretically possible with ICC too and I have some running XMM examples, but it's such a PITA, that I gave up ... the reward (apparently nothing because most Propeller heads don't seem to care) is not worth the effort. Maybe Nick would like to try [noparse]:)[/noparse]
These are just highlights that are important to me. I haven't used Catalina enough to know its issues (if any). Neither are GNU of course.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
The EMM? No, I won't try that!
For my application, that would be too slow. I parted the one program into two. Nice fit. One setup and one core that actually does the work.
I'd like to implement a few more commands, but I'm running out of space. I hope that Richard fixes two points I showed him. Until then, I can well live with it the way it is. I still could squeeze out some hundred words with storing the COG-ASM in EEPROM and loading that into COG-RAM when I start the COGs.
I guess that Richard is faster than Parallax with its Prop II.
I wanted to try Catalina, but then decided to stay with ImageCraft, because it worked. That doesn't mean that Catalina doesn't work! I simply didn't want to spend time switching the compiler in the middle of development.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Suffice to say that we support a whole bunch of micros from the 8 bits AVR to the 32 bits ARM and we know how to tune a compiler for performance. Full featured, high performance, at low price (for professional development). While not free, the non-commercial version is only $99. We continue to make improvements to our products, for example, we have a new C preprocessor that will work on assembler files - not as useful to Propeller users, but just a data point to show that we improve our products based on customers' needs (in this case, for other micros).
// richard
You really want that Richard? It might be better to remain disengaged.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 8/30/2009 7:36:13 PM GMTTime is too short for competitive analysis. We purposefully take pain to make our demo fully functional so potential users can be their judges.
If there are improvements I should make to our compilers, I'd like to hear it. Obviously for the Propeller, it's a) better IDE, b) uses less code space, and c) more free. Anything else?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
a)
a1) Fix the ridiculous bug with the quotes in the include path. I give you 10 minutes.
a2) allow longer defines. That entry box with 10 visible chars is far out. My suggestion is to allow to include a file with the @. 3 hours.
That's it for the IDE for me. I don't care about that. I spend most of the time thinking, not typing.
b)
b1) Yes, yes, yes. No float when not needed. I give you 4 hours for that work.
b2) remove that stupid "debug" stuff, when there is no debugger. Even if it doesn't change things. I give you 30 minutes.
b3) Remove the useless OPs I showed you. 1/2 a day.
b4) Remove unused code, or don't link it. Will take longer, you can postpone that to september.
c) "more free"?
b1) free what? Beer? That's OK for me!
d) "Anything else"
d1) update the zip with the HTML-helpfiles to the ones on your domain. wget didn't help me.
Nick
PS:
Did you notice that you got a registration from Germany a few weeks ago? I warned you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I bet it is small....judging from the amount of C chatter on this board.
Your ARM compilers are probably your biggest sellers.
They are well made and create small object files.
The cost is big for a lone developer or hobbyist but
for a business the cost is negligible when compared to
even a small amount of programmer hours saved, and
there is the value of smaller code files and greater speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Some mornings I wake up cranky.....but usually I just let him sleep -
OK, almost all your complaints have to do with the ineffectiveness of the assembler/linker, which if you recall, we we discussed privately, wasn't one of the better decision I have made regarding its development. That will be addressed, whether it's the next two months, or 4-5 months, depending on the email I just sent you
For undo/redo, try Options->General, "undo across save," or something like that. That should do the trick.
The define is a pain: getting a usable GUI for a list of define is a pain, pain, pain. The other ones will be done..., except fpr the unused code bits. I will push that technology through first with the other compilers to make sure it works well.
Thank you for your support. Our German distributor does sell Propeller licenses now and then, and I didn't catch your name there. Thanks.
You woulnd't write compilers if you would be a GUI-guy!
May I repeat my suggestion, maybe you got me wrong...
I would be happy with even a hack! The idea is:
If I enter "@path/fileName" into the define-box, it just opens that single file and uses that for all (allowing a mix would only add bells and whistles) #defines. I even wouldn't ask for a browser for that! I know where the file is or will be. A popup "Can't open file 'blabla'" would be more than enough in case of an error!
It would be natural for me, if that file uses the '#define <WhatEver>' -syntax. Just like a header-file with only defines that is kinda "injected" before parsing. In effect, it would behave as if I have written an '#include <WhatEver>' at the first line of every file.
Thanks for your support!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Ah, got it. How about this, I will add a
-inc:<file>
to the C preprocessor, which will effectively do a
#include <file>
in the source. On the GUI side, I will add a browse and button for
[noparse][[/noparse] ..Add Implicit Include File..] [noparse][[/noparse] browse ]
or something like that. What to do think?
p.s. I am taking my long suffering wife for a date, so DON'T EXPECT any reply from me until Monday night or so
Thanks.
I'm not going to contribute much to this thread since it seems to be mainly about the ImageCraft GUI and not about either of the compilers themselves. But I will answer a couple of specific questions and then give a brief update on Catalina.
Specific questions:
@Wned - yes. I don't know much about Eclipse, but I had a version of catalina running under Code::blocks. I never released it since I don't have enough time to support both the GUI and the compiler. Buf if someone else wants to take this on, I'll support them to whatever extent I can.
@jazzed - yes. Just put multiple C files on the command line. Or if you have lots of files then create a user-defined library. This is covered in the tutorial document - a (trivial) example is included with the demo programs (my_prog.c, my_func.c).
A quick update on what's coming in the next Catalina release:
The biggest change is that I have done away with all the myriad target files. I kept adding more and more target files for more and more platforms (and specific configurations of those platforms) until I finally realized this was just plain silly - just testing each release was taking so much time that I had none left to add any new functionality (and I always seemed to miss one or two). However, this change is not only for my own benefit - it also makes it much easier for others to support new Propeller platforms.
Now there is only one target directory and only four target files - lmm_debug, lmm_default, emm_default and xmm_default. These target files work on all the supported platforms - but you are still free to create your own target if you have an unsupported plaform or unusual hardware configuration. The debug target is the only slightly unusual one (since it has to include the POD debugger).
The targets are now generic, and any specific target configuration can be done on the command line. I have also rewritten catalina.exe to turn it into a more "user-friendly" front end to both LCC and the binder, eliminating the command line complexity of the beta releases. Catalina also now makes use of environment variables, which simplifies things even further.
For example, to compile a C program to run on Blade #1 of the TriBladeProp using a high resolution TV driver in NTSC mode, and also include the real-time clock plugin, you just define the symbols TRIBLADEPROP, BLADE_1, HIRES_TV, NTSC and CLOCK and then compile your program.
You can do this on the command line as:
But if this represents your standard configuration which you intend to use for multiple compilations, it is much easier to set up a CATALINA_DEFINE environment variable:
Then you can can compile all your programs with very simple commands, such as:
All targets support the same configuration options, so to compile for exactly the same configuration but as an EMM program or XMM program, you would just say:
Or:
I have also reworked all the XMM code and also extended the Catalina XMM kernel in preparation for the forthcoming "large" memory model - i.e. 16Mb code, data and heap and 32kb stack (for the Prop I - on the Prop II this will become 16Mb code, data and heap and 256Kb stack).
Oh, and lots of other minor improvements and a few bug fixes.
I hope to release all these changes in the first "official" Catalina release sometime in the next few weeks. The "official" status just means that I believe this version works correctly on all the supported platforms, and that it will remain functionally stable for some indefinite time to come - probably until the Prop II arrives.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 8/31/2009 1:47:52 AM GMT
> -inc:<file>
For me, absolutely OK!
I've eMailed you with more details.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO