Catalina - a C compiler for the Propeller (now with TriBladeProp support)
RossH
Posts: 5,520
NOTE: Catalina 2 has been released here. It completely replaces this beta release.
The fifth beta release of Catalina has been UPDATED . It now includes a target package for Cluso99's TriBladeProp.
Catalina is a FREE ANSI C compiler for the Propeller, based on LCC.
There are versions available for Windows and Linux. Read the enclosed documents for more details. There is a tutorial to get you started, as well as a technical description of various aspects of Catalina. Documents and demos are attached to this post. Binaries and sources for Win32 and Linux follow in the next posts.
With this release, Catalina is now even more complete
There was not expected to be another 'beta' release, but so much new functionality has been added that I decided it was too early to do an 'official' release. I expect the next release will be the first offical release.
Between now and then I will be concentrating on adding support for additional hardware configurations - mostly platforms with XMM hardware. Several people have agreed to provide me with Propeller platforms, and (assuming they actually arrive) Catalina will be 'offiicially' supported on all those platforms - and of course, it will continue to be supported on the Hydra (and now on the Hybrid!).
New features in beta 5 include:
Problems Discovered or Resolved Post-Release (fixes will be included in the next release):
[*] The tribladeprop support package has been updated to include a new PropTerminal compatible HMI plugin (and target and demo program). This update also fixs a problem with the EMM targets, and also a problem that may have prevented a blade rebooting properly after a program was loadedRoss.
Edit: A new version of beta 5 has been uploaded to fix the XMM kernel problem. If you downloaded beta 5 already, please download the binary release files again. The compiler source files are unaffected. Also, you should also re-download the demo programs.
Edit: A new target support package for Cluso99's TriBladeProp has been added to this thread. This package contains both Linux and Windows sources, and binaries for a slightly updated version of the Catalina Binder. However, this this is not a full release - it must be installed on top of an existing Catalina beta 5 source/binary installation.
Edit: updated the tribladeprop target support package to fix a couple of issues, and also add a new PropTerminal compatible HMI plugin (and a target and demo program that illustrate how to use it). Now PropTerminal can be used to allow a PC to be used as the screen, keyboard and mouse for Catalina programs. PropTerminal.exe is available from www.insonix.ch.
Edit: Catalina 2.1 has been released here. It completely replaces this beta release. I have removed the attachments from this thread as it seems people using the Parallax Search function are still finding this thread and not realizing there is a newer version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/2/2010 6:41:01 AM GMT
The fifth beta release of Catalina has been UPDATED . It now includes a target package for Cluso99's TriBladeProp.
Catalina is a FREE ANSI C compiler for the Propeller, based on LCC.
There are versions available for Windows and Linux. Read the enclosed documents for more details. There is a tutorial to get you started, as well as a technical description of various aspects of Catalina. Documents and demos are attached to this post. Binaries and sources for Win32 and Linux follow in the next posts.
With this release, Catalina is now even more complete
There was not expected to be another 'beta' release, but so much new functionality has been added that I decided it was too early to do an 'official' release. I expect the next release will be the first offical release.
Between now and then I will be concentrating on adding support for additional hardware configurations - mostly platforms with XMM hardware. Several people have agreed to provide me with Propeller platforms, and (assuming they actually arrive) Catalina will be 'offiicially' supported on all those platforms - and of course, it will continue to be supported on the Hydra (and now on the Hybrid!).
New features in beta 5 include:
- Added SD Card file system. Two I/O modes are now supported, selected by using different versions of the standard C library:
- libc : provides support for stdin, stdout & stderr only
- libcx : provides full SD Card file system support
- Added a Generic SD Loader, and a new XMM target for loading XMM programs from the SD Card (no modifications are required for LMM programs, and the loader can also be used to load SPIN programs).
- The Catalina Target Packages are now released under the GNU Lesser Public License. This applies to all the files in the target directory (unless they are already covered by another license, such as various Parallax files which are covered by the MIT license). This means that programs that are compiled with Catalina can now be distributed in binary form, without requiring them to be released under the GNU GPL. However, note the full GNU Public license STILL APPLIES to the Catalina Code Generator and Catalina Binder - if you use these components in your own product you are required to release that product in source form under the GPL.
- Added a new Target Package for the Hybrid. The default target directory is set up for the Hydra, but a new target_hybrid directory is also included. If you have a Hybrid, you may want to rename the default target directory to be target_hydra, and rename the target_hybrid directory to be target. On the Hybrid, you can use the SD Card and the Xrtreme XMM card at the same time - which means that lucky Hybrid owners are the first to be able to use the new Catalina SD Card file system!
- Added a new Target Package for the TriBladeProp. The default target directory is still set up for the Hydra, but a new target_tribladeprop directory is added. If you have a TriBladeProp, you may want to rename the default target directory to be target_hydra, and rename the target_tribladeprop directory to be target. On the TriBladeProp, you can use all three blades to execute Catalina programs at the same time - one blade has mouse, keyboard and screen support, two blades have XMM RAM and one has SD Card support - which means that TriBladePRop owners can also now use the new Catalina SD Card file system.
- Documentation update - the tutorial and reference documents have both been significantly enhanced (but are still far from complete).
- Various minor bug fixes:
- Peephole optimization sometimes didn't work, resulting in executables that were correct, but which were slightly larger than necessary.
- A problem that could cause programs to crash when using printf to print floating point numbers with the value NaN (Not a Number) or Inf has been fixed. Also, the t_float hmi function now correctly prints nan or inf when passed those values.
- A problem with complex expressions involving functions that return structures has been fixed. This would cause lcc to crash with an assertion failure.
- The sysplugin function call now returns -1 instead of 255 for errors such as 'plugin not found'. The previous error value (255) may have looked like a legitimate floating point value, whereas the new value (-1) ensures that any floating point operation will return NaN (Not a Number) if the floating point plugin is not present.
- The EMM and XMM Kernels are now loaded from within the target rather than from within the program code. This will make it easier to support multiple types of XMM. It is also simpler to understand than the previous method, where the compiler arbitrarily tacked the kernel onto the end of the program for no apparent reason.
- Fixed a potential problem with the EMM and XMM Loaders not loading the entire kernel - now they always load the maximum possible kernel size.
- Fixed a problem with malloc failing when managing blocks of memory of (different) small sizes.
- Fixed a problem in the coginit function. Added a new demo program 'test_coginit.c'.
- Fixed a problem in the XMM Kernel. This problem only affected C programs compiled as XMM - it did not affect LMM programs.
- Fixed a problem in the Generic SD Loader - interactive mode worked ok, but specifying a particular file to load on boot did not.
- Updated the demo progams - fixed a few minor issues with I/O and updated the information in the various README files.
- Peephole optimization sometimes didn't work, resulting in executables that were correct, but which were slightly larger than necessary.
Problems Discovered or Resolved Post-Release (fixes will be included in the next release):
[*] The tribladeprop support package has been updated to include a new PropTerminal compatible HMI plugin (and target and demo program). This update also fixs a problem with the EMM targets, and also a problem that may have prevented a blade rebooting properly after a program was loadedRoss.
Edit: A new version of beta 5 has been uploaded to fix the XMM kernel problem. If you downloaded beta 5 already, please download the binary release files again. The compiler source files are unaffected. Also, you should also re-download the demo programs.
Edit: A new target support package for Cluso99's TriBladeProp has been added to this thread. This package contains both Linux and Windows sources, and binaries for a slightly updated version of the Catalina Binder. However, this this is not a full release - it must be installed on top of an existing Catalina beta 5 source/binary installation.
Edit: updated the tribladeprop target support package to fix a couple of issues, and also add a new PropTerminal compatible HMI plugin (and a target and demo program that illustrate how to use it). Now PropTerminal can be used to allow a PC to be used as the screen, keyboard and mouse for Catalina programs. PropTerminal.exe is available from www.insonix.ch.
Edit: Catalina 2.1 has been released here. It completely replaces this beta release. I have removed the attachments from this thread as it seems people using the Parallax Search function are still finding this thread and not realizing there is a newer version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/2/2010 6:41:01 AM GMT
Comments
Note that you may have to manually create the installation folder structure described in the documentation.
Edit - A new version of beta 5 has now been loaded - if you downloaded the previous version, you only need to grab the binaries again - the compiler source files have not changed. Also, I have taken the opportunity to update the demo programs - get them from the first post in this thread.
Edit - Note that the source distrubution contains only the sources to the compiler and libraries - to run the compiler, you also need to get the binary distribution since it contains the 'target' directory.
Edit: Catalina 2.1 has been released here. It completely replaces this beta release. I have removed the attachments from this thread as it seems people using the Parallax Search function are still finding this thread and not realizing there is a newer version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 11/3/2009 2:00:54 AM GMT
The Linux source code is actually the same as the windows source code, but due to differences in the line handling between Linux and Windows it can cause problems if you mix win32 and linux source files. If I have indavertantly mixed some files up, some judicious use of the dos2unix and unix2dos utilties (not included) often sorts it out.
The files are zipped 'tar' files. When unzipping and un'tar'ing the files, make sure to use the -p option to tar to preserve the permissions of the files. Use commands like:
unzip catalina_linux_source.zip
tar xpvf catalina_linux_source.tar
unzip catalina_linux_binary_1.zip
tar xpvf catalina_linux_binary_1.tar
... etc ...
If the permissions are incorrect you may get errors when building Catalina - try 'chmod a+x' on the offending scripts. Also make sure you have '.' in your path.
Edit - A new version of beta 5 has now been loaded - if you downloaded the previous version, you only need to grab the binaries again - the compiler source files have not changed. Also, I have taken the opportunity to update the demo programs - get them from the first post in this thread.
Edit - Note that the source distrubution contains only the sources to the compiler and libraries - to run the compiler, you also need to get the binary distribution since it contains the 'target' directory.
Edit: Catalina 2.1 has been released here. It completely replaces this beta release. I have removed the attachments from this thread as it seems people using the Parallax Search function are still finding this thread and not realizing there is a newer version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 11/3/2009 2:01:25 AM GMT
Very cool.
Thank you very much for this.
TJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I owe everyone here a bunch, So thanks again for answering my dumb questions.
Projects. RG500 ECU system. PropCopter. Prop CanSat. Prop Paste Gun.
Suzuki RG500 in a RGV 250 frame.
Bimota V-Due (Running on the fuel injection system)
Aprilia RS250
I think a -p option on tar extractions will preserve execute permissions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I see that the "hard core" did not comment this.
I guess they don't want to step on some sore toes for the other C-compiler.
Thanks alot.
I'm not in to C, but this really did the "trick" to motivate me to explore it.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 3/29/2009 6:02:41 PM GMT
I don't have much time to check this out just now but my first thought is let's modify the LMM kernel so as to fetch code from the external RAM of Cluso's TriBlade Propeller board. May be a whole lot slower but a nice 1M byte space. Looks like your LMM kernel does not have even one free LONG so sadly this would require dropping floating point support.
Could you clarify the licensing. GCC, for example is released under the GPL however code compiled with it does not have to be GPL'ed unless it is linked with a GPL'ed library. With Catalina I would imagine, perhaps wrongly, that the same should be true BUT the compiled code cannot be run without the catalina LMM kernel which is GPL'ed. This is some form of weird "linking" which would seem to imply any code created with catalina and distributed with the catalina kernel must also be GPL'ed.
As you document says:
Is this really the intention here? Or should the kernel be LGPL? Or does using the kernel not really count as linking?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There's a lot to be said for developing/testing your algorithms on a PC, say, before moving them down to a tiny target system with poor debugging facilities.
There are a billion software engineers whom you can hire that can get on with your C code for you.
So, C for portability, ASM for speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Not trying to distract from your success, but I have to ask: Did you ever think about making the LCC create spin bytecode? I know a spin bytecode based C would run slower but that would not be a problem if it can be augmented with PASM. One could create more useful applications because the resultant source to binary ratio would be better. There are fundamental things that need to be done in C for the current Propeller that are just not feasible with current LMM ideas because of size. Even PropII will face this challenge, so a C tool chain creating spin bytecode compatible binaries is something to look at while your LCC aptitude is fresh. Food for thought.
Congrats on your results!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
@jazzed: Is there an official (or even unofficial) Spin bytecode reference?
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
heater - thanks for the tip on the '-p' tar option - I'll check it out. I am keen to explore multi-prop solutions, and will have a look at Cluso's tri-bladed prop. I don't want to drop floating point support, but the Catalina LMM Kernel is currently quite "bloated" and I'm sure I (or others) can still save quite a lot of space.
jazzed - I did indeed look at using LCC to generate bytecodes and then write a bytecode interpreter for the propeller - but I wasn't sure I could fit everything into a single cog (which was one of my design goals). Also, I really wanted "native" floating point support (another of my design goals) which reduces the space available even further. Also keep in mind that there is already a darn good bytecode interpreter available for the propeller - the built-in SPIN interpreter - and it would be relatively simple to have LCC generate the same bytecodes as SPIN (but again this would lack floating point!). I finally decided that if I was going to implement a bytecode interpreter I would implement one for Java, not C (codenamed project 'Jupiter'). But the real reason is that I just think the LMM is way cool and I wanted to play with it.
I anticipate licensing will come up several times yet, so here is a quick summary: Yes, I believe you would currently have to release your source code if you release a product that uses Catalina. This was intentional, and is partly to differentiate Catalina from other C compilers currently available for the propeller. Catalina is primarily intended for propeller-heads like me, and not for commercial applications. I don't want to undermine those who reasonably expect to make a profit for all the hard work they have put in to develop their compilers, so if you have a commercial product for the propeller and don't want to release the source code for it, all you have to do is pay a few lousy bucks for the compiler. Remember that if you pay for a compiler you are largely paying for (a) assurance that it is fit for purpose and has been thoroughly tested, and (b) assurance that you can get support if you need it, or if the compiler has a problem. You get none of these assurances with Catalina!
But I do want Catalina to be used as widely as possible. I am familiar with the issues surrounding the GPL and the GNAT Modified GPL (GMGPL) from the world of Ada - Ada compilers also have to issue a special exception to the GPL, and for the similar reasons - i.e. Ada 'generics' have to be released as source code. I may re-release the Catalina LMM Kernel under the GMGPL if there is sufficient interest.
Jonathan, the wiki has a listing and brief bytecode definition, the full interpreter has been posted, and Hippy made a disassembler. Seems like enough to get started for the adventurous.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
For more info on the spin bytecodes, see my code on the thread Faster Spin Interpreter (see link on Prop Tools in my signature to find the thread). I put the docs together from Hippy's work, Chip's source code and my decoding and rewriting of the interpreter. Alas, its unfinished, as I was distracted to other cool projects.
I am not a C programmer, so I cannot test it out.
I presume it would be a mammouth task to have your compiler run on a Propeller SBC platform???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Catalina is really only likely to fly well on the forthcoming Propeller II (more hub RAM - yay!) but in the meantime I'd certainly like to try to get it working on a multi-prop plaftorm. After all, the real Catalina had two props!
I'd consider trying out one of your tri-blade prop SBCs - they look great - but I doubt I would have either the time or the necessary skill to assemble it - I built my first computer 30 years ago, so my soldering days are loooooong gone!
What command line are you using - you need to specify the -lm and -lc options to include the appropriate libraries - if this still doesn't work, check you have installed the libraries in the correct (i.e. default) location. If not, use the appropriate lcc option to tell the compiler where to find them.
lcc test_leds.c -lc -Wl-a -Wl-ttv -oresult.spin
This makes the actual code for the lmm, but doesn't drop it inside of something ready to be run on the prop. To do that you take one the lmms, for example tv: lmm_tv.spin and in the OBJ section change Catalina : "Catalina" to Catalina : "result"
Catalina is completely compatible with the Prop Tool. After compiling your program, locate the Catalina target directory and load the appropriate target file (it's just a normal SPIN program) into the Prop Tool. Compile and load that file as usual.
The default target file is called lmm_default.spin.
Edit: just read your previous post. What you did will produce a Catalina LMM PASM file (which will compile using the Prop Tool) but by itself the result will not be executable since it doesn't have the other parts of Catalina it depends on - e.g. the Catalina LMMM Kernel and the various drivers.
Actually, the test_leds program doesn't need the full capabilities of the default target - it only needs the Kernel, so load the target file lmm_no_hmi.spin instead.
Post Edited (RossH) : 3/30/2009 8:32:24 AM GMT
Fantastic stuff and well done.You've got a lot further than I did but I'm glad to see that my instinct that LCC seemed to be the best way to go appears to have been confirmed here, and by the fact that ImageCraft's offering is also based upon LCC, though heavily modified ( which we will come back to ).
I really think you should make everything completely unrestricted, MIT or MIT-style, as far as is possible. That takes the politics out of it and opens the door to those who object to GPL licensing or the model proposed here.
I think it is essential to have a license that at least allows LCC to be run with -S without any impositions, preferably allowing use of the Catalina LMM kernel without restrictions as well. While my personal opinion might not count for much, having not been actively involved in any Propeller activities for a good few months now, not providing that would greatly subdue any interest I could have in moving Catalina forward.
I'd much prefer to see people working on a project in unison and harmony than anyone having to go their own way to circumvent licensing they don't want or don't like. My personal opinion is that if something ends up being commercially exploited and nothing comes back in return that's the way it is, at least people still benefit overall, the ethos should be about giving and spreading the knowledge not about withholding or seeking reward ( regardless of the ethos of others ), and it doesn't preclude the more open-source minded still working on their branch moving forward. I know others disagree, so just justifying my opinion than seeking to start a debate or, worse still, a flame war.
It worked well for me, although I'm only using the -S option to see the Catalina LMM output. Taking my recognition that it is beta code, I hope you find the following constructive or food for thought rather than outright criticism, and a number of these issues I've previously raised with respect to the ImageCraft compiler.
Falling at the hurdle of re-compiling LCC under Windows I went the LCC Quake-3 pre-compiled binary compiler route and used their bytecode output, translated to an optimised bytecode and had an interpreter for that rather than altering the code generator back-end, but the observations I had seem to be applicable here as well.
LCC in my experience is lacking in optimisation which leads to a lot of code bloat and is undoubtedly the area where ImageCraft through their efforts gain their commercial advantage over the LCC base. LCC plus Propeller LMM leads to quite large programs; current Catalina code for "int i; i=1;" is 5 PASM instructions, 40 bytes. This suggests there is a lot of scope for optimising but the question has to be how much should be done as within-LCC optimisation, how much by calling helper functions, and how much moved into the kernel.
I haven't looked at your Kernel ( I steer clear of looking at any GPL'd source lest doing so comes back to bite me in the future
One handy trick is to move code outside the kernel and execute that itself as LMM if Cog space is getting short. Knowing what calls are made into the kernel you can decide what gets included ( and how ) and what can be left out prior to linking it in.
It may also be worth looking at what LMM code you are actually generating. Given the work each instruction does, on a Propeller, being 32-bit wide, it often amounts to a large footprint for little work achieved; getting the contents of a variable from the stack takes three instructions so there's a candidate for optimising to a better LMM instruction ( "Get var from offset N on stack" ) and so forth. It is also worth considering if you could use a 16-bit word based LMM code ( LMM thumb-style as I call it ) to improve code density, or even 8-bit. The downside there is increased kernel complexity and slower execution. On the plus side, one can select which to have; full-width PASM as LMM and faster execution, or slower execution and far more compact object code.
Part of the issue is deciding what you are offering; super-fast C constrained by Propeller limitations, or opening the door to easy C programming ( against Spin et al ) where density outweighs execution speed. It should ultimately be possible to offer both and a half-way house in-between. As you note, the Prop II is better suited to 32-bit LMM execution, 64K instructions than the Prop I, 8K instructions, so you could choose to focus on the Prop II and call issues over code density moot. I'd disagree, and most of my effort was directed at low code density rather than maximal performance.
Though working with bytecode myself, I did consider generating LMM from that ( at various code densities as described ) and I found that to be an easier approach to code generation as it externalised optimisation and actual code generation to LCC, but I guess as in-LCC code generation is working with the same data set there's not a lot in it ( except having to understand what is happening within that code ). What did become very clear to me is that there are two approaches; the stack-based machine which the bytecode approach dictates and the register-based architecture the LCC code generator seems to use. I was not entirely convinced of the register approach, not in terms of small code footprint anyway.
Somewhere there's a perfect bytecode for minimal footprint LMM but 32-bit LMM / PASM isn't it IMO. For fastest execution it is the only choice, along with other tricks like reversed-LMM using a 'decrementing program counter' interpreter ( credit to Phil Pilgrim for that idea ).
For my bytecode approach it became clear that for minimal footprint a very compact instruction set was required, which interestingly tended to converge towards the Spin bytecode approach; specialised "PUSH #0" instructions etc. However, I wasn't convinced that trying to generate Spin bytecode was a worthwhile pursuit as that's a case of bashing a square peg into a round hole. Far better to translate LCC bytecode to my bytecode and design a kernel to suit.
All this builds on what you have and have achieved so don't get me wrong, I am not denigrating what you've done in any way, and you are free to choose how you want to go forward. As it is, you seem to have a very credible C to Propeller compiler and that's no small achievement in itself - I really do mean fantastic stuff and well done - and I look forward to seeing where this leads.
In theory it's a simple case of compiling its own source then you have the same compiler except written in LMM. With a few routines to make it run and the libraries modified to use the actual hardware available, that should be it on a platorm capable enough of having it execute.
This is often the way it's done to get an existing compiler to work natively on a new CPU or architecture.
It can however be easier said than done, and rests on the compiler source being written in the same language as the compiler can compile. I have no idea if LCC can self-compile.
this looks as the thing, that I have been looking for, when I played a little bit with smallC. But 32bit and with full floating point support, whow!!!! And it is great, that it can be combined with all the spin obex files!
Unfortunately I was not able to find the right command line using windows xp. I always get "invalid argument". Could you please give a complete example how to to compile a file, when I have the files under
("Catalina for dummies")
Thanks a lot, Christof
the problem was due to the short names. lcc assumes "progra~1" to be "program files" which was not the case here.
Christof
I believe from the start and still do that ImageCraft Propeller C ultimately will be successful only if the Propeller is successful in the commercial market place. The Catch-22 is that I believe and still do that Propeller will only be successful in the commercial marketplace if there is a solid C compiler.
How would a "free" C affect us? It may drive away some sales for the Non-Commercial use license, which we are already practically giving it away at $99 (plus with the support from Parallax, we give away the Prop Demo Board as a bundle), so we can't be happy about that. OTOH, people do what they want to do, and hacking a compiler can be fun, so it goes. Ultimately, it may help in the long run by making the Propeller even more popular among hobbyists, which may translate to commercial use, eventually and may be.
Meanwhile, we hunker down, and hope that more people will be contributing to the C Object Exchange, and hope that more commercial use for the Propeller pops up. Thankfully, Parallax is a good partner. To this date though, we are one of the few, if not the only, 3rd party commercial software providers for Propeller. Clearly I am ahead of the curve. Lets see how it translates in the future.
// richard
Thanks for your intelligent and thoughtful comments. I saw that you had done some work with LCC, but only after I had already started work. Rather than get diverted weighing up the merits of other's alternative approaches, I decided to just plough on with my own approach - after all, why should you have all the fun! [noparse]:)[/noparse]
I don't take any criticism from anything you have said - many of the issues you raised I considered as well. If I came to a different conclusion than you would have done on some issues then it is likley that our initial design goals were different.
For instance, there are several reasons why the Catalina LMM Kernel is quite large at present:
1. I wanted floating point "built in" to a single cog LMM Kernel. This requires nearly 200 longs, and meant some other "nice to have" features had to go.
2. I kept making changes to the kernel to solve issues that I couldn't easily solve with LCC - an example is the ability to load and save all the LMM registers using a single LMM PASM operation (push_m and pop_m). For this release, rather than get "hung up" on LCC code generation issues (and never get a result) I tended to just add another kernel operation to solve the problem and move on.
3. I have been concentrating on "completeness" and "correctness" (although I don't claim either!) for this release rather than optimization. The main reason this is a beta release is that I need to go back and refine both the code generator and the kernel.
For me the licensing issue is neither here nor there. The lesson of history is that useful software will get used. Time will tell if Catalina falls into that category. If there is enough interest, I will revisit the license when Catalina is ready for it's first non-beta release. My current inclination is to release at least the Catalina LMM Kernel under the GMGPL - this should satisfy everyone's needs.
I agree with most of your comments on the optimization of LCC. After deciding against byte coding I considered including some 16 bit "short form" instructions. This alone could reduce code sizes by 25-40%. But I decided against this as well - not just because of the impact it would have on the kernel, but also due to the difficulty that having both long and short instructions would have in other areas - for example, I would not be able to use existing assemblers or debuggers (so call me lazy!).
I also considered using Phil Pilgrim's ingenious "reverse execution" proposal for LMMs, but I couldn't face the thought of debugging both the code generator and the kernel if everything was executing backwards. I'm saving this one is a last resort if I need more speed once everything else is working. Or someone else can have a go at it.
I will revisit some of these decisions before releasing Catalina as a non-beta. My current belief is there's a lot of scope left for optimizing both the code generator and the kernel before there is a need to make significant architectural changes.
Ross.
Glad you got it working. I'll sort out the "Progra~1" vs "Progam Files" issue (curse you, Microsoft!) in the next release.
Ross.
P.S. There's a nice line in one of the recent John Birmingham books - I don't recall the exact wording, but it something like the Windows file system finally being recognized as a "crime against humanity".
I think we all agree that anything that gets more propellers sold is good for everyone in the long run. More propellers sold will naturally translate into ImageCraft selling more compilers.
BTW, is hippy correct in saying that the ImageCraft C compiler is also based on LCC?
Ross.
We licensed LCC back in 1994 so I don't have to write the front end. The back end has been heavily modified and we even added a function level optimizer for some targets.
"In the Long Run" may be a good thing, but what can I say. We will just continue to slough through...
// richard