PDA

View Full Version : Catalina - a C compiler for the Propeller (now with TriBladeProp support)



RossH
03-29-2009, 09:25 PM
NOTE: Catalina 2 has been released here (http://forums.parallax.com/showthread.php?p=844004). 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 http://forums.parallax.com/images/smilies/hop.gif

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
The SD Card file system supports FAT12, FAT16 and FAT32 cards. There is a test program called test_fs.c that reads and writes files on the SD card. There is a new SD plugin that must be loaded to support access to the SD card file system.

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.

For more details, see the Catalina documents.


Problems Discovered or Resolved Post-Release (fixes will be included in the next release):
All problems have been fixed in the newly uploaded beta 5

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 (http://forums.parallax.com/showthread.php?p=844004). 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 (http://forums.parallax.com/showthread.php?p=844004)

Post Edited (RossH) : 4/2/2010 6:41:01 AM GMT

RossH
03-29-2009, 09:28 PM
Windows binaries and source code.

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 (http://forums.parallax.com/showthread.php?p=844004). 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 (http://forums.parallax.com/showthread.php?p=844004)

Post Edited (RossH) : 11/3/2009 2:00:54 AM GMT

RossH
03-29-2009, 09:38 PM
Linux binaries and source code.

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 (http://forums.parallax.com/showthread.php?p=844004). 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 (http://forums.parallax.com/showthread.php?p=844004)

Post Edited (RossH) : 11/3/2009 2:01:25 AM GMT

TJHJ
03-29-2009, 11:15 PM
RossH,
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

heater
03-29-2009, 11:19 PM
Fantastic, I always wanted to go for a spin in a Catalina. Will for sure try it out.

I think a -p option on tar extractions will preserve execute permissions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

KIH
03-30-2009, 12:44 AM
Very nice! http://forums.parallax.com/images/smilies/smilewinkgrin.gif
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. http://forums.parallax.com/images/smilies/rolleyes.gif
Thanks alot.
I'm not in to C, but this really did the "trick" to motivate me to explore it. http://forums.parallax.com/images/smilies/yeah.gif

Phil Pilgrim (PhiPi)
03-30-2009, 12:56 AM
KIH said...
I see that the "hard core" did not comment this.

Don't despair, RossH. From my own experience, Sunday morning is probably the worst time to introduce something new. Most forum denizens are out doing other things. Just keep the thread alive until tonight or tomorrow morning, and you'll see some real action! Congratulations, BTW. This project looks like a real tour de force! I wonder what other "stealth" projects are out there. http://forums.parallax.com/images/smilies/smile.gif

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 3/29/2009 6:02:41 PM GMT

heater
03-30-2009, 01:32 AM
Yes, RossH you are a dark horse.

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:

catalina.pdf said...
...a product that incorporates or uses Catalina (or a modified version of
Catalina, or some portion of Catalina) must itself be released under the GNU GPL."



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.

FearTurtles
03-30-2009, 01:55 AM
What exactly is the advantage of C over spin and Assembily? This of course speaking as a person who wouldn't know C if it bit me on the nose.

heater
03-30-2009, 02:03 AM
There are C compilers available for a huge number of different computers from main frames to 8 bit micro-controllers. If you can write your code in C quite likely you can migrate the non-hardware dependant parts of it from one architecture to another, from one micro-controller to another.

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.

jazzed
03-30-2009, 03:00 AM
Nice work Ross.

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://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Bill Henning
03-30-2009, 03:08 AM
Very very cool! Can't wait to try it out...


RossH said...
Here's a program I've been working on for a couple of months. Catalina is an ANSI C compiler for the Propeller, based on LCC. This is a beta release.

There are versions for Windows and Linux. Read the enclosed document for more details. There should be enough in there to get most people up and running.

The demo program is quite cute - it's a version of the classic game of Othello, written in C. If you are lucky enough to have a Hydra you can just download the binary. Otherwise you may need to reconfigure one of the Catalina compiler targets to suit your propeller platform.

Documents and demos are attached to this post. Binaries and sources for Win32 and Linux will follow in the next posts.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

lonesock
03-30-2009, 05:20 AM
@RossH: Nice job! I will definitely be playing with this. Note that since you GPL'd your LMM kernel I can not use this for work [8^(

@jazzed: Is there an official (or even unofficial) Spin bytecode reference?

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

RossH
03-30-2009, 06:12 AM
Hi all,

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.

jazzed
03-30-2009, 07:10 AM
Ross, nice to read some musings over implementation ideas. I was thinking just compile C to bytecode and let the onboard interpreter do the rest ... that way spin and C would be on par for memory use at least. Interesting you're thinking about Java .... I worked on Java a machine and thought my next foray in that area might be to attempt a 32 bit JAVA2 interpreter that could run code on external memory. Alas my recent XMM C effort kind of burned me out for now.

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://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Cluso99
03-30-2009, 10:12 AM
Congratulations Ross http://forums.parallax.com/images/smilies/smile.gif

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 (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

RossH
03-30-2009, 11:06 AM
Hi Cluso,

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!

Jetfire
03-30-2009, 12:23 PM
I can't get anything to compile, this is in windows. When trying to compile hello_world_1.c I get back "C_t_string undefine". Compiling test_fprintf.c I get "C_cos undefined", "C_fprintf undefined", and "C___stdout undefined".

RossH
03-30-2009, 12:29 PM
Hi jetfire,

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.

Jetfire
03-30-2009, 01:57 PM
Adding -lc allowed it to continue. I don't have bstc installed, can it be run to create Prop Tool compatible spin instead of going to a binary or eeprom?

Jetfire
03-30-2009, 03:02 PM
I think this is what I'm looking for:

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"

RossH
03-30-2009, 03:11 PM
Jetfire,

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

hippy
03-30-2009, 11:36 PM
KIH said...
I see that the "hard core" did not comment this.

It sometimes takes more than three hours for people to wake up, let alone notice something wonderful has happened http://forums.parallax.com/images/smilies/smile.gif


RossH said...
Here's a program I've been working on for a couple of months. Catalina is an ANSI C compiler for the Propeller, based on LCC.

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


RossH said...
I believe you would currently have to release your source code if you release a product that uses Catalina ... Catalina is primarily intended for propeller-heads like me, and not for commercial applications ... But I do want Catalina to be used as widely as possible ... I may re-release the Catalina LMM Kernel under the GMGPL if there is sufficient interest.

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.


RossH said...
This is a beta release.

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 http://forums.parallax.com/images/smilies/smile.gif ) but the impression I get from an earlier comment is that it isn't small. As I didn't look, I'm not sure why that is, but it may be worthwhile examining how your LMM-code and kernel tie together.

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.

hippy
03-31-2009, 12:08 AM
Cluso99 said...
I presume it would be a mammouth task to have your compiler run on a Propeller SBC platform???


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.

Christof Eb.
03-31-2009, 02:40 AM
Hi RossH,
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 D:\Catalina ?
("Catalina for dummies")

Thanks a lot, Christof

Christof Eb.
03-31-2009, 03:20 AM
Hi again,
the problem was due to the short names. lcc assumes "progra~1" to be "program files" which was not the case here.
Christof

ImageCraft
03-31-2009, 03:48 AM
As the provider of the commercial C compiler, let me just add some general comments:

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

RossH
03-31-2009, 05:56 AM
Hi hippy,

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

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.

RossH
03-31-2009, 06:00 AM
Hi Christof

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

RossH
03-31-2009, 06:12 AM
Hi richard,

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.

ImageCraft
03-31-2009, 07:30 AM
RossH said...
Hi richard,

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

Chuck Rice
03-31-2009, 07:54 AM
Cool! The Linux version compiles with no changes on an intel Macontosh, but when I try to compile othello, I get:

--(255)> catalina -d -d othello.c
diagnostic level 1
arg: -d
switch: -d
diagnostic level 2
arg: othello.c
catalina: Catalina Binder (version 1.0)
output file = a.out
initial file = /usr/local/lib/catalina/target/catalina_progbeg.s
binding
processing input file /usr/local/lib/catalina/target/catalina_progbeg.s
cannot open input file /usr/local/lib/catalina/target/catalina_progbeg.s

catalina done

Post Edited (Chuck Rice) : 3/31/2009 12:59:25 AM GMT

RossH
03-31-2009, 08:11 AM
Hi Chuck,

I don't know much about the Mac, but it appears the target directory is not where catalina thinks it should be.

The target directory is actually included the binary distribution file, not the source file. Did you download both or just the source?

Can you actually locate the file 'catalina_progbeg.s' in directory /usr/local/lib/catalina/target and open it in a text editor?

If your target directory is actually elewhere, try using the -T option to catalina to specify a different target path. e.g:

catalina -T /mypath/to/target

Let me know how you go. If you find any Max specific issues, I'll include notes about them in the next release.

Ross.

Edit: Chuck, I just reread yor email - you cannot run catalina on a 'C' source file - the program called catalina is actually the binder. The compiler is lcc, which you must compile first. So your initial command should look something like

lcc othello.c -lc

Post Edited (RossH) : 3/31/2009 1:28:59 AM GMT

heater
03-31-2009, 02:58 PM
I am very interested in the idea of enabling Catalina or ImageCraft C compilers to execute code from external RAM. The ability to have a megabyte or so of code/data on the Prop is very tempting especially that we now have a very nice platform to do this on in the form of Cluso's TriBladeProp.

In order to do this it will be necessary to add external RAM access functions to the LMM kernel and as it stands there is no room at all. I concur that dropping floating point to make space is not desirable. One of the main attractions of C here over SPIN is floating point support. I'm also not keen on farming the floating point functions out to another COG. COGs are precious and passing data between COGs has it's own overheads.

One could implement the float functions in LMM as well but that is slow.

I suggest adopting the overlay technique developed on this forum and perfected by Cluso. With this the float functions code would be loaded into COG from HUB as fast as it is possible on the Propeller from which they are executed at full PASM speed. Given that functions for multiplication, division etc are quite "loopy" the overlay technique can be faster than LMM as it only loads the code once rather than for once for each execution of an instruction.

In order to get my Z80 emulator into the Prop of have spent a lot of time experimenting with LMM, reverse LMM, overlays and multiple COGs. For sure reverse LMM can be a win for small functions with no jumps or loops AFTER you have fully debugged them. Multiple COGs I gave up on as the speed gains were marginal and wasting the COGs for it did not appeal. The overlay technique has proved very easy to work with enabling a complete Z80 emulation to be implemented in one COG with good performance.

As for licensing. I don't think you should worry about stepping on ImageCraft's toes and they should not worry about you as competition. Quite the opposite. Having multiple C compilers shows the world that people take the Propeller very seriously. It can "grow the market" as they. Consider that Catalina may encourage development of more C objects for OBEX which will further increase the interest of C users in the Propeller. This would surely grow the market for Parallax and ImageCraft. Commercial developers will feel more comfortable with the polish and support of ImageCraft.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
03-31-2009, 03:17 PM
heater said...
I am very interested in the idea of enabling Catalina or ImageCraft C compilers to execute code from external RAM. ...

heater, I have ICCPROP running programs from external RAM for a board I built. The ICC kernel was pretty loose (no more ... squeek, squeek). LMM optimization goes out the door for my loader. There are some hurdles that need to be overcome for a "solution", and with one issue in particular,∑I keep banging∑my head∑:<∑ I'm handing the ball to Richard tomorrow. I've been using Propalyzer for the effort, and∑would have never gotten too far without it ....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

heater
03-31-2009, 03:41 PM
jazzed, As usual no sooner do I think of something than I find someone has gone and done it already:) Excellent.

Still that leaves Catalina to get working with ext RAM.

By the way how compatible are the C objects in OBEX between ICCPROP and Catalina?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed
03-31-2009, 03:59 PM
I'm worried about portability. I let go of my discipline and ended up with sprinklings of asm("..."); statements in some modules ... should be a cinch to correct but time is precious. The propeller.h header will also have to be ported. It is yet to be shown if the ascii-byte array approach to running native pasm will work, but theoretically it should be fine ... Ross has some of the key drivers covered already via HMI calls. I'm still quite busy and am not sure when I can get serious with Catalina, but now that I know more than one platform will fly, I have no choice but write perfectly portable code from here.

On my external RAM or XMM effort, there are still some issues as I said, so it's not yet ready for prime time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
03-31-2009, 05:13 PM
heater, jazzed ...

I'm fairly sure I can save a couple of dozen longs in the Catalina Kernel by some simple optimization. How many instructions do you think would be needed to fetch data from external RAM? Perhaps jazzed could let us know how many longs his existing code requires?

If anyone wants to experiment, have a look at the Catalina "debug" target - it throws floating point operations out to an external cog to make room for POD, and therefore also makes a good base for experimenting - I just did enough work on it to make enough room for POD itself, and I just noticed today that I haven't even removed the unused Pack and Unpack support routines - so there are probably 50-odd longs in there that can be used to experiment with. Ultimately I don't want to lose the floating point - I find that omission from SPIN extremely frustrating - but when we know exactly how much room is required in the Kernel, I can "tweak" the code generator to eliminate some other operations instead - for instance, I have 6 "branch" instructions (for speed) where in fact 2 or 3 would be almost as fast if I generated the code slightly differently.

As for compatibility, both Catalina and ImageCraft are based on the same ANSI-compliant front end (LCC), so the compatibility at the source code level should be high. Of course, we may have different library routines (e.g. for cog functions), but the operations required are determined by the Propeller itself, so while I haven't checked ImageCrafts libraries, I can't imagine they'd be functionally much different to mine - a couple of #if .... #endif statements is probably enough to cope with the differences.

Ross.

hippy
03-31-2009, 07:11 PM
@ RossH : Thanks for taking the time to give comprehensive answers to the points raised. I respect your decisions and I would not venture to say you were wrong, and I think you are quite right in one important aspect ... something which works ( and works right ) is far better than anything else which does not.

Beyond that it is all optimisation, tweaking and trying clever things to improve this or that as things progress. Having solid foundations is the key and that's where you are rightly heading at present ( seem to have reached from what I've seen ).

On external memory access - When I looked at it, this seemed to be little more than changing RDLONG etc to calls which interfaced with that external memory so technically just a small change excluding the support code.

On kernel size - That's always a problem. After a number of VM's I've come to the conclusion the best approach is to start with everything as LMM kernel extensions. Either execute them as LMM or page them in as necessary though I found paging took longer overall if it's not looping code. Keep the kernel as empty as possible to start with so plenty of space to add essentials which need the speed then decide what to move in from LMM later.

On speed ( which relates to the above ) - IMO, put that as a secondary issue for now, accept things like FP may be painfully slow to start with using LMM kernel extensions. Basically; don't let whatever you do now lock you into something which you cannot change later, or makes ongoing progress more difficult than it needs to be. I'm sure it goes against the grain as much for you as it did for me, but ignoring execution speed was quite liberating in removing a lot of worry on 'how to' and allowing more rapid development. It is hard though to resist the 'this would be much quicker if in the kernel' temptation.

On non-PASM LMM - Thumb-style LMM, I agree a big obstacle is in not having sub-compilers and assemblers which support whatever code/syntax you dream up. Some interaction there with other component authors and adding simple macro commands which can do bit-field shuffling of parameters should be able to fix that. This is where two or more projects can each drive each other along, the whole being greater than its component parts - not just software modules, but also XMM / external Ram extensions as well.

On ImageCraft - I think we all have a great deal of sympathy for Richard & Co, who have put in a lot of work and thrown their commitment behind the Propeller and it seems have not so far seen a lot in return. It must be at least a bit depressing to see people get excited by new 'free-offering competion' but hopefully this will sort itself out long term. Commercial and non-comercial offerings have been able to exist along side each other elsewhere. This may be one area where licensing may be important in order not to lock ImageCraft out of any great ideas that arise along the way. I think it's clear that the intention is not to set Catalina against ImageCraft but to provide an alternative. However it goes, I'm sure we all want to see a benefit to the wider Propeller community and everyone playing their part in it.

Cluso99
03-31-2009, 08:33 PM
I have published the driver for block transfers to/from SRAM to cog. Also see the ZiCog code I published today which shows the instruction fetching routine for the z80 emulator. Be aware though, that this access uses all the I/O prop pins except the 2 serial. I have a latch which extends some pins, but this can/will conflict with other access. If you have to use locks you will lose all the speed.

Blade #1 (prop) has some I/O available (vga/tv/kbd/mouse) by using a latch to hold the upper address lines (2048KB blocks without requiring the latch to change). This however, will be somewhat slower.

This is why I saw the need to use multiple props... and tomorrow they will be US$8 http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

hippy
04-01-2009, 12:50 AM
If nothing else, I'm now able to compile LCC under Windows XP, so many thanks for that.

I don't like make files so I now have an MS-DOS batch file which does that - works for me anyway, YMMV. This still requires MinGW to be installed but may help people who are looking to using other Win32 compilers - just change the two calls to GCC in theory.

Drop MAKE.BAT in the .\Catalina\Source\Lcc directory alongside Build_Lcc.Bat, run it from there. Will need to edit the "Set MINGW=" to point to where MinGW is installed.

jazzed
04-01-2009, 01:37 AM
Ross, my XMM 32 bit instruction fetch for the board I'm using takes 23 longs ... unfortunately that's not all I need for my current approach.

The XMM "kernel" I have is based on the idea that it will startup running from LMM Propeller memory, load the target program to the XMM external memory, and switch to running the program from XMM external memory. This method is not restartable without system reset but does not need to be. The program .text segment lives in XMM, the .data/.bss segments live in LMM Propeller memory. Having to do the switchover makes the XMM "kernel" a bit more complicated than I would like. For example one has to decide when to load from XMM or Propeller LMM. One could arrange to have separate "kernel" cogs I guess to simplify this since there is room for two kernel modules in the loader assuming the loader can read from SDCARD or net boot, etc ... of course this is "sort of an optimization" beyond getting something to work. Once the optimization is available, one can discard the original. I still see the XMM only "kernel" as being bigger than the 32 bit XMM fetch code because of slight complications.

It's easy to say "all you have to do is" ... then you find the devil in the details. One detail I found that has to change is using RDLONG PC,PC in the compiled LMM asm source. A special branch LMM primitive needs to be invoked instead.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
04-01-2009, 05:22 AM
hippy,

Good work on the batch file - I'll incorporate it into the next release. I'll try the same approach for getting the c89 library to compile - I couldn't get the Makefile to work under Windows. This will greatly simplify things for anyone who wants to experiment.

jazzed, cluso,

I'm working on a few optimizations to the code generator at the moment, but I hope to get a chance to look at loading a Catalina LMM PASM program from external RAM on the weekend.

Ross.

hippy
04-01-2009, 07:44 AM
@ RossH : I didn't have any problem with the makefile as is and even cheated by using "Build_Lcc.Bat > MAKE.BAT" on a clean build and then edited MAKE.BAT, so that might be a useful trick.

For Win98SE/XP rather than XP only, replace "DEL /Q %BUILD%\*" with "FOR %%F IN (%BUILD%\*.*) DO DEL %%F"

jazzed
04-01-2009, 10:53 AM
The∑solution∑for my XMM issue occured to me∑while chatting with Richard at Starbucks :)



Loading xmm application
Starting xmm application ....

ICCPROP XMM Application Running
Hello World!


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

hippy
04-03-2009, 12:56 AM
My interest in LCC has been re-sparked and I've also been thinking about why I feel less than enthusiastic about C-LMM on the Propeller, so it seemed sensible to put down what my thoughts were for refutation and opposing arguments ... have I got it wrong ? I'm quite happy to be told so ...

Internally LCC holds a tree structure IR of the program and un-rolled that is well suited to execution on some theoretical stack-based machine.

While far from optimised, the bytecode of that IR is quite straight forward and can be easily translated to opcode plus optional operand which suits a bytecode interpreter. For frequently occurring operands it's easy to create additional opcodes with implicit operands as super-operators which, when all put together, can produce minimal footprint code.

Non-bytecode output from LCC is less efficient than the bytecode in so far that much involves register movement requiring opcode plus two operands.

While that opcode plus two operands could be compacted, fixed native instruction sets work against that unless converted to kernel calls. Where register fields are large, and registers used are limited in number, a lot of that instruction width is wasted.

For the Propeller, that is even more true as instructions are 32-bit wide; 9-bit register fields plus 4-bit conditionals and 3-bit write-modifiers which are largely unused. With a 4-bit register field needed for C execution say, that amounts to 17 to 21 redundant bits, somewhere between 50% and 75% of each instruction becomes unnecessary overhead.

That's equally true where any constant over 9-bit has to be loaded or used, which includes destination addresses for branches and calls, each of which take up two instruction slots. For 64K instruction code space, between 75% and 85% of those instruction is waste.

It therefore seems to me that (1) LCC, probably any C compiler, output is far more suited to a stack-based processor than a register-based one, (2) better suited to variable length byte oriented instruction sets than larger fiexed-width instructions, and (3) that makes it a very poor match for Propeller 32-bit PASM/LMM.

To get execution speed up, 32-bit LMM is the best choice, and this dictates a 32-bit wide data stack as well ( which in itself can be equally wasteful when dealing with less than 32-bit data ).

Propeller C-LMM is therefore only really suitable for execution with large memory. With limited memory the only options are to use C-LMM where code and/or data structures are small or to execute from external memory. The later having potential performance and increased financial costs.

The only other potential for C on the Propeller we currently have is bytecode interpretation to keep the footprint minimal, but that comes at a performance cost which may not be acceptable. It is also true to say that without optimising the LCC bytecode as generated that too is far from being the most efficient, space and speed wise, though considerably better space wise than C-LMM.

Now that conclusion is no different to what I've previously believed and stated though it's the first time I've put a detailed argument and rationale behind my thinking.

I have also thought that those saying "Propeller must have C" were largely doing so because they simply don't ( through indoctrination, peer pressure, limited vision or refusal to accept other possibilities ) consider anything without C as credible - came, looked, commented and derided lack of C, but never had any real interest in using the Propeller anyway. But could it be that take-up of C is always going to be hindered by the inherent nature of the Propeller ? It needs large resources to have speed and lacks the speed with minimal resources, all-in making it a poorer choice than other processor alternatives despite what the Propeller hardware does offer ?

How do other 32-bit instruction set processors fare with respect to programming in C ? Is it just that they do have larger memory, or that the instruction set is somehow better suited to using C ? Is it simply, that as there's little alternative to C for such processors, that's how it is, no one thinks to ask if it's well suited or not ? Am I being overly critical of C on the Propeller when it's really no worse than on any other 32-bit processor ? Is their saving grace higher clock speeds mitigating inefficiencies elsewhere ?

The final thing is; if one wants to make the Propeller attractive to C programmers, if for no other reason that to sell into a market where C is deemed necessary for use, what needs to be done to the Propeller to improve it ?

My feeling is that adding instructions to allow efficient bytecode / 16-bit LMM implementations to run much faster would be highly advantageous. Not just for stack-machine emulation, but also for compacting what is currently 32-bit PASM/LMM to 16-bit Thumb-style PASM/LMM for precisely the cases such as this where the alternative is 50% waste of instruction space. Of course, higher clock speeds and single cycle instruction execution will help as well.

What I'm not particularly convinced about is requiring people to have to integrate external memory just to run C which runs 'as is' on other processors. However I do accept that if the other advantages of using a Propeller justifies it, that is a viable alternative.

If anyone has any thoughts I'd be pleased to hear them.

Bill Henning
04-03-2009, 01:17 AM
Excellent analysis, which largely parallels my thinking.

I still think that ImageCraft C and Catalina will help get acceptance for the propeller, and it will allow those used to C to start using the Propeller without having to dive into Spin.

We should also remember that while code size is limited, LMM does allow C code to execute considerably faster than Spin, thus providing a nice middle ground - and on the PropII with its larger memory LMM will shine (and be MUCH faster due to autoincrementing hub pointers, 160Mips cogs, and 20M hub cycles per second - I'd guess a minimum of 5x-8x increase in speed for LMM code)

I also think that a byte code C compiler - weather targeting the Spin byte code or a custom crafted one - would be a very welcome tool. Richard seems to be interested in targeting the Spin byte codes... which by the way will also get a minimum 5x faster with PropII.

If my LMM assembler/linker is debugged in time, I may come to the unofficial expo to show it off and meet everyone.


hippy said...
My interest in LCC has been re-sparked and I've also been thinking about why I feel less than enthusiastic about C-LMM on the Propeller, so it seemed sensible to put down what my thoughts were for refutation and opposing arguments ... have I got it wrong ? I'm quite happy to be told so ...

Internally LCC holds a tree structure IR of the program and un-rolled that is well suited to execution on some theoretical stack-based machine.

While far from optimised, the bytecode of that IR is quite straight forward and can be easily translated to opcode plus optional operand which suits a bytecode interpreter. For frequently occurring operands it's easy to create additional opcodes with implicit operands as super-operators which, when all put together, can produce minimal footprint code.

Non-bytecode output from LCC is less efficient than the bytecode in so far that much involves register movement requiring opcode plus two operands.

While that opcode plus two operands could be compacted, fixed native instruction sets work against that unless converted to kernel calls. Where register fields are large, and registers used are limited in number, a lot of that instruction width is wasted.

For the Propeller, that is even more true as instructions are 32-bit wide; 9-bit register fields plus 4-bit conditionals and 3-bit write-modifiers which are largely unused. With a 4-bit register field needed for C execution say, that amounts to 17 to 21 redundant bits, somewhere between 50% and 75% of each instruction becomes unnecessary overhead.

That's equally true where any constant over 9-bit has to be loaded or used, which includes destination addresses for branches and calls, each of which take up two instruction slots. For 64K instruction code space, between 75% and 85% of those instruction is waste.

It therefore seems to me that (1) LCC, probably any C compiler, output is far more suited to a stack-based processor than a register-based one, (2) better suited to variable length byte oriented instruction sets than larger fiexed-width instructions, and (3) that makes it a very poor match for Propeller 32-bit PASM/LMM.

To get execution speed up, 32-bit LMM is the best choice, and this dictates a 32-bit wide data stack as well ( which in itself can be equally wasteful when dealing with less than 32-bit data ).

Propeller C-LMM is therefore only really suitable for execution with large memory. With limited memory the only options are to use C-LMM where code and/or data structures are small or to execute from external memory. The later having potential performance and increased financial costs.

The only other potential for C on the Propeller we currently have is bytecode interpretation to keep the footprint minimal, but that comes at a performance cost which may not be acceptable. It is also true to say that without optimising the LCC bytecode as generated that too is far from being the most efficient, space and speed wise, though considerably better space wise than C-LMM.

Now that conclusion is no different to what I've previously believed and stated though it's the first time I've put a detailed argument and rationale behind my thinking.

I have also thought that those saying "Propeller must have C" were largely doing so because they simply don't ( through indoctrination, peer pressure, limited vision or refusal to accept other possibilities ) consider anything without C as credible - came, looked, commented and derided lack of C, but never had any real interest in using the Propeller anyway. But could it be that take-up of C is always going to be hindered by the inherent nature of the Propeller ? It needs large resources to have speed and lacks the speed with minimal resources, all-in making it a poorer choice than other processor alternatives despite what the Propeller hardware does offer ?

How do other 32-bit instruction set processors fare with respect to programming in C ? Is it just that they do have larger memory, or that the instruction set is somehow better suited to using C ? Is it simply, that as there's little alternative to C for such processors, that's how it is, no one thinks to ask if it's well suited or not ? Am I being overly critical of C on the Propeller when it's really no worse than on any other 32-bit processor ? Is their saving grace higher clock speeds mitigating inefficiencies elsewhere ?

The final thing is; if one wants to make the Propeller attractive to C programmers, if for no other reason that to sell into a market where C is deemed necessary for use, what needs to be done to the Propeller to improve it ?

My feeling is that adding instructions to allow efficient bytecode / 16-bit LMM implementations to run much faster would be highly advantageous. Not just for stack-machine emulation, but also for compacting what is currently 32-bit PASM/LMM to 16-bit Thumb-style PASM/LMM for precisely the cases such as this where the alternative is 50% waste of instruction space. Of course, higher clock speeds and single cycle instruction execution will help as well.

What I'm not particularly convinced about is requiring people to have to integrate external memory just to run C which runs 'as is' on other processors. However I do accept that if the other advantages of using a Propeller justifies it, that is a viable alternative.

If anyone has any thoughts I'd be pleased to hear them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

Mike Green
04-03-2009, 01:30 AM
hippy,
You've articulated the issues that have been present all through the history of computing from the time of the first Fortran compiler to the present. You are absolutely correct that the Propeller instruction set is poorly suited to simple code generation from a high level language. It's quite good for raw efficiency of hardware, of hand code generation and optimization. A good example of a microcontroller design for compiler use would be the Motorola 6800 and 68000 processors. They have a largish set of registers and the instructions are mostly symmetric. Similar instructions work similarly. Most importantly, they have stacks and index registers. The Propeller does have a largish set of registers and many of the instructions are mostly symmetric. There's no stack and there's no indexing of any sort. The conditional execution, which is so useful for close control of timing and the determinism, is of very little use for most code generation. There's a little peephole optimization that could be done to use it, but it's really a waste of bits from a code generator's standpoint.

I really believe that Chip has come up with a nearly ideal programming toolset for the Propeller. The individual cogs are just about the right size for hand produced code and the instruction set is manageable that way. On top of that, he's produced a very efficient interpreter, both in space and execution time, with a large instruction set. The only piece that's missing is an efficient way to embed native code within the interpretive code. I think that if there had been a mechanism for loading short segments of native code into a buffer in a cog and executing them, we would not have many of the problems we're having. This would include loading these short segments from ROM and some of the infrequently used Spin operations (like xxxxMOVE, xxxxFILL, and STRxxx) might be done this way to make room for the buffer. Chip had his reasons for not considering this, but it has had a large impact. The effort to produce alternative Spin interpreters and different LMM interpreters is helpful to show us what is possible and to provide real tools for optimal Prop use.

I would like to see a Spin-like C implementation for the Propeller that allows mixing of assembly and compact interpretive code. For that matter, given a new Spin interpreter, the same could be done with a 3rd party Spin compiler. There's no reason why either a C compiler or a Spin compiler couldn't produce native Propeller code for a subroutine or part of a subroutine. ImageCraft does have the tools and expertise to do this. They just don't have a large enough customer base to pay for the work involved.

Leon
04-03-2009, 03:12 AM
Hippy:

Other 32-bit processors I've used like the ARM, PIC32, and XMOS have architectures and instruction sets that are optimised for the efficient execution of C and similar languages.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

ImageCraft
04-03-2009, 03:53 AM
Hi Hippy, nice analysis. However, there is one point that is "incorrect" - LCC intermediate code does not favor stack based output. Absolutely no limitation in terms of generating code for a general purpose register machines. Believe me, I have seen a lot of compiler IR http://forums.parallax.com/images/smilies/smile.gif What you have seen, I believe, is a conversion to a stack bytecode from the IR. All this means that the LCC IR can be transformed into stack bytecode easily but it has no other impact for generating other output.

re: Mike "They just don't have a large enough customer base to pay for the work involved..."
You hit the nail quite correctly. It's absolutely possible to have a version of ICC to generate bytecode. In the ideal case, generating a mix of bytecode, LMM and native FCACHE code would be possible. We have some momentum with Propeller C going right now, so I think it may be time to start thinking about how best to do this.....

hippy
04-03-2009, 04:34 AM
Thanks for the feedback and particularly Richard - You are right, I probably have misunderstood the internals of LCC, my only experience has been with Pascal P4 and its ilk and I've always used 'stack code' in my own efforts, and what came out looked remarkably similar. Doesn't mean that the IR is though.

One question ImageCraft may be able to answer, but it is understandable if not ( and I don't expect figures ) .... is the main problem a lack of interest in ICC-Prop, few even looking at the demo, or is it more demo downloads not translating to sales ?

Mike, I also agree with your analysis; the Prop is an ideally fit with PASM and Spin, and both are quite easy to use, Spin particularly so. I think the real market and potential for C is for those who don't have the prejudices I mentioned earlier but are familiar with C, wish to use it and want to also use the Propeller.

While I'm not overly fond of C, use it only as a high-level assembler, I have nothing against its use per se. What I don't like about C is a matter for 'programming language war' threads on other forums, and totally separate to the issue of implementing C http://forums.parallax.com/images/smilies/smile.gif

ImageCraft
04-03-2009, 04:51 AM
Hippy: I wish I know the answers to your question http://forums.parallax.com/images/smilies/smile.gif

My gut instinct is that our biggest competitor is Spin. May be I should go up to Rocklin to rough Jeff up http://forums.parallax.com/images/smilies/smile.gif. However, as Propeller is being picked up by more traditional uC users, there will be more interests in Propeller C.

I can say that with the Parallax promotion of getting people to write C objects and our joint promotion of giving the Prop Demo board with purchase of a compiler definitely have a positive impact. With the C objects, I see one of the final barriers to fall.

RossH
04-03-2009, 05:51 AM
Hi hippy,

I agree with most of your analysis. While LCC may not be especially targeted at stack-based architectures, the C language itself definitely is, and it is commonly accepted that LCC therefore maps "well" to some architectures, and not so well to others. I'm working on a better mapping to the Propeller, but it's not easy. I think LMM C will really only be a winner on the Prop II.

There are certainly some things in the Propeller that could be changed to help support for stack-oriented languages (this is the subject of a whole 'nother thread - but I suspect it's too late for any significant changes to be incorporated in the Prop II) but at least for the current Propeller (i.e. the Prop I) perhaps a byte-coded C implementation is really a good alternative to an LMM implementation. I can't see Catalina heading that way in the short term, but I believe ImageCraft C may be experimenting in that direction.

No matter what happens, the Propeller is guaranteed to be the winner. We might will end up with one solution that suits all needs, or we might end up with several alternative solutions that allow users to pick the one that best suits their needs.

As to the "must we have C at all" question - I don't want to start a language war, but I believe that's just a fact of life. SPIN/PASM definitely has a large role to play, but there's just too much investment in C (and too much existing C code) for it to be an alternative language for many commercial embedded applications. Case in point - the company I work for uses "another brand" of microcontroller. I could probably convince them to change hardware, but we also have 30-50 man years worth of software development in our products - and 99% of it is in C. This represents an investment that completely and utterly dwarfs any investment we may make in any particular brand of hardware.

Ross.

hippy
04-03-2009, 06:00 AM
I can appreciate the problem of C lock-in. Luckily I've had the luxury of never having been in that position for micro development, but do suffer from desktop application / OS lock-in.

jazzed
04-03-2009, 07:48 AM
Make a bed; sleep in it. Change sheets every now and then. Buy a new mattress when you can't stand the old one anymore. Better yet find many beds to sleep in :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
04-03-2009, 07:59 AM
I'm sure there's a line about bedbugs that would be really appropriate here. If only I wasn't too tired from lack of sleep to think of it.

Ross.

Cluso99
04-03-2009, 12:08 PM
I am in total agreement to the statements above. The big explosion has just begun, but sadly most seems to be driven by hobbyists. Not that that's a bad thing, it just means it's slower because lack of financial input not occuring by commercial enterprises. And any commercial enterprises using the prop are probably keeping that to themselves anyway.

C is here to stay. I will avoid it, but that's my choice. I see it as an absolute necessity for the commercial benefit to the prop. ICC provides a commercial product and Ross's will provide an entry for the hobbyists, who may advance to the hobbyist version of ICC. I can only see positive outcomes for Imagecraft, Ross, Parallax, and ultimately all of us.

Keepup the good work all.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

heater
04-03-2009, 04:21 PM
I am very surprised to hear so many negative comments regarding C on micro-controllers here. Especially terms like "lock in".

It is in the nature of the technology that embedded hardware has been changing at a rapid pace for decades now. New processors, architectures, bigger faster etc. The huge expansion in memory space, the addition of networking and so on.

Whilst a competent hardware engineer can produce a new platform with all the latest CPUs, memories and peripherals in a matter of weeks or months and do that every three or four years, to keep abreast of technology or just to be able to build anything because the old chips have gone obsolete, it can be a major project to get the application software up and running on it.

In all of this turmoil C has not been the "lock-in" but the "oil" that allows apps to move relatively painlessly from platform to platform, generation to generation.

I'd be very interested to hear from you all what other languages you have been using that also made this possible. For myself I have been involved in many "dead-ends" like PL/M on Intel, Coral 66, and even Ada which was supposed to be the last word in all this.

A case in point: 10 years ago myself and another software engineer spent nearly two years recreating an embedded control application in C that was originally written in 8086 assembler a decade before that. The motivation for this being to make use of a new platform that was Motorola 68000 based. This turned out to be a good investment because since then the app has moved from 68000 and PSOS operating system to PowerPC and VxWorks to PowerPC and Linux to ARM and Linux. All the while being able to run the same code wrapped up in hardware simulations on Windows and Linux on the desktop.

Again I ask, how else could we have done all that?

Now I'm not particularly stuck on C, I'll use what ever gets the job done. It does seem that C is just not a good fit for the Propeller. For generating COG code it is basically useless due to the tiny space and need for self modifying code. Generating LMM is nice but ends up wasting a lot of space. LMM using external RAM (XMM) would fix the space problem but at a huge speed hit as we won't be having 32 bit wide data paths.

So a C generating byte codes would seem to be the thing.

If you want to program your Prop in C with compact and speedy byte code in HUB or external RAM you can do it now. Just use BDSC on the Z80 emulator for the Prop (Just joking, had to get my ZiCog plug in again).

I look forward to having the time to try out Catalina.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

ImageCraft
04-03-2009, 04:50 PM
You know, while we may do an ImageCraft C that generates bytecode, there is currently NO one pushing the limit of the LMM C yet, with the exception of Steve's graphic stuff where he needs the RAM for the display. So the negative aspect of LMM C is currently only a potential problem. It may not be true in a month or two where people start to push ImageCraft C, but lets not be so hasty in judging LMM C to be "too big" yet http://forums.parallax.com/images/smilies/smile.gif

heater
04-03-2009, 05:19 PM
OK, I'll just have to give it a serious try. C in on the Prop II will be an excellent proposition.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Brian Fairchild
04-03-2009, 05:29 PM
ImageCraft said...

...there is currently NO one pushing the limit of the LMM C yet...


Except that a nagging doubt is stopping me moving a commercial project completely over to the Prop.

I have about 1k active lines of C source which currently compiles to around 6k instructions on an ATmega644P. A quick and dirty port to the prop shows a similar size, once you've allowed for data, which is 75% of the available hub space. As part of the reason to move is to make use of the VGA capability of the prop to add a display to the project I'm very worried that if I move then I'll not have enough space to add the new features. Even if I didn't need space for VGA screen memory I'd be very worried about lack of expansion space.

So at the moment the new CPU board has a prop alongside an ATmega and development will be ICCPROP alongside ICCAVR.

I *could* rewrite all my code in SPIN, tests show I'd get a threefold saving on code space, however SPIN just isn't fast enough to do what I need. Plus, as other bits of the system will stay with other processors coded in C I don't really care for the idea of using two languages alongside each other. I find SPIN quite usable as a language to hack together objects for the prop but the switch back and forth is just too painful for day to day use.

Like heater, I've been brought up with a number of dead-end languages (although I still have a soft spot for PL/M) and have seen how some language just don't fit some CPU architectures. A case in point is PL/M. Running on something as lowly as an 8085 it actually made quite a decent system, especially when the hardware used some of the more esoteric features of the peripheral chips. The code generated was clean and efficient. However, the product that was PL/M-51 was awful. The architecture of the 8051 just didn't fit with a compiled language. A lack of any real indexed instructions and only one crippled 16-bit data pointer made the compiler really work hard and the bloated code it generated was just painful to look at. We regularly used to prototype in PL/M and then rewrite from the ground up in assembly. Code size gains, and with them similar speed gains, of a factor of 10 were not unusual.

RossH
04-05-2009, 08:36 PM
All,

Just a quick update. I'm putting the final touches on the next Catalina beta. I haven't yet had time (as I had hoped) to experiment on using external RAM, so I've decided instead that the next beta will incorporate two different kernels:

- the 'full' kernel, with integrated floating point support in a single cog. This will always be the standard kernel.

- an 'alternate' kernel which can be used for programs without a need for fast floating point (but which will support floating point at the cost of an additonal cog). This kernel will have about 120 free longs to encourage experimentation. I'm hoping someone might use this free space to implement a kernel that reads from external RAM.

Selecting the altrnate kernel will be done at link time by specifying a different target.

The main improvements in the next beta are to do with code generation. I've reduced overall code size by about 25%, and also fixed a few miscellaneous bugs. The next release will also contain improved cog-support functions (I must have been asleep when I wrote the last set - there's a couple of really silly errors in them).

Depending on work committments, the next beta should be ready in a day or so.

Ross.

Cluso99
04-05-2009, 09:16 PM
Time permitting, I'll have a bash at adding the external ram driver to the pasm code and try it, prividing you can give me some test c code to try it with.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Ron Sutcliffe
04-05-2009, 10:10 PM
What a great Project.

After 3 months in Rural France with only poor access to the Internet. It’s great to drop in on the Prop community and first up come across this thread and read some of the very thoughtful contributions. I hope that you get the support that this project deserves.∑I have been using ICCP since its release. I have downloaded the Catalina binaries today and it looks like a nice fit with SourceEdit by Praxis. Worked ok under∑XP with a small testfile.c.∑Compact code size even at the expense of a reduction in execution speed will win the day for me.



Ron

hippy
04-08-2009, 04:42 AM
I hope Ross doesn't mind because this is a bit off-topic for C-LMM but as Catalina is the best C framework outside of ImageCraft we have for the Propeller, this seemed the best place to post ...

A little something which can be added to Catalina ( or any LCC 4.2 ); a better bytecode generator than the one which comes provided. Drop it in .\catalina\source\lcc\src ( alongside bytecode.c etc ), add the following to bind.c ...

xx(bytecode/propeller, bytecodePropellerIR) \

Add propbcod to the makefile or MAKE.BAT, compile the sources, then run the compiler with -target=bytecode/propeller.

The bytecode is ( despite its different look ) pretty much the same as -target=bytecode generates but opcodes are renamed to 'xxx.tt' where 'tt' is the type which fits better with a Propeller view of the world; UP unsigned pointer, SF signed float, UW unsigned word etc, should be largely self explanatory. Fixed the problem of data left on stack for a function call with no assignment, and also simpliefied block moves by adding an extra opcode. The 'Cxx.tt' opcodes convert type 'xx' to type 'tt'.

Compile your source with -target=bytecode/propeller -noopcode -notypedef if you want original LCC bytecodes.

It also generates linking and other information which is a PITA for the subsequent toolchain when missing. In particular you can use either 'tree' or 'code' entries to generate the actual executable bytecode image. The 'tree' entries will be handy if optimising. Use -nocode or -notree to hide that output.

All the hacking is in the propbcod.c so feel free to modify. I don't plan on doing anything further with this source except fix bugs if any are found. I'm not a C programmer so no apologies for inconsistent coding style, horrible looking or bodged code. The goal was to get a backend which prduces something external utilities can use better than what was output.

A final note - This is not intended to detract from C-LMM ( nor any developments with ImageCraft bytecode generation ) but rather complement it. Seeing the 'tree' structures might even help people get a feel for what Catalina is holding internally. It is also possible to take the bytecode and generate C-LMM from it or even PASM for small programs. If it's any use to Richard / ImageCraft /anyone else it's there for the taking.

hippy
04-08-2009, 05:20 AM
I've also added a page for Catalina on the Propeller Wiki which everyone is free to add to as they wish. I recall you don't need to register to edit pages, just dive-in, start typing -

propeller.wikispaces.com/Programming+in+C+-+Catalina (http://propeller.wikispaces.com/Programming+in+C+-+Catalina)

RossH
04-08-2009, 09:48 AM
Hi hippy,

Thanks for this. I'm constantly have to use the existing LCC bytecode generator to check what my backend produces (no funny comments here please!) compared to what other backends produce, so any help in that area is welcome. I may add your alternate bytecode generator into the next release to assist other brave venturers into the arcane world of compiler code generation - or at the very least include a note about it.

I'm getting closer to releasing another beta. I'm currently working on a C conformance test suite for Catalina, so that I can do more automated regression testing. The trouble is that all the test suites I can find (e.g. the gcc torture test, or even the one included in LCC itself) assume that (a) the compiler you're testing pretty much works already, and (b) that you have unlimited RAM available. Breaking these suites up into Propeller sized chunks that I can actually use to tell me what's wrong is going a bit slower than I expected.

Ross.

agodwin
04-08-2009, 10:19 PM
ImageCraft said...
. It may not be true in a month or two where people start to push ImageCraft C, but lets not be so hasty in judging LMM C to be "too big" yet http://forums.parallax.com/images/smilies/smile.gif


I tend to agree with Brian and heater.

I have a commercial product that I started in Spin about 9 months ago. I used Spin because it was all a bit experimental - I hadn't any experience of the Prop, and ICC was very new. I didn't want the additional uncertainty of a new compiler, even though I'd much rather work in C.

Now, the project has matured a bit. I've used part of the codebase for another project and a lot of features have been added. I've several times run out of space and had to cut features out to keep going. Admittedly I was learning Spin as I went and probably haven't written as efficiently as I might (and I've used some library objects that I could usefully replace with assembler) . With a rewrite I might be able to save a fair bit of space.

I'd rather like to change to C because it seems to have better features for maintenance - the preprocessor in particular. I'm already using one of the 3rd-party Spin compilers in order to be able to build with 'make' under linux, and I take advantage of its constant folding.

But while I'm comfortable enough now with the Prop that I would consider buying ICC, and could appreciate a speed-up, the potential increase in code size makes it not worthwhile - I think I'd blow the limits immediately. I'd also have to go back to Windows, or some sort of emulation, which I'd see as a retrograde step.

hippy
04-09-2009, 12:07 AM
Q: What's the audience's take on C extensions to support coding for the Propeller ?

As a primarily non-C programmer knowing just the basics, if I were to use C I'd like to be able to use it like I do spin - pre-defined byte, word, long data types, byte[ ], word[ ] and long[ ] pseudo-array access to hub memory, $, % and %% for numeric constants and the ability to put underscores in numbers.

Some of that's fairly easy ( numerics done ), the rest harder, but how would one turn extensions on or off, and which is it by default ? I guess it depends on which encampment you're coming from.

One thing someone could help with by putting some effort in which isn't the mainline code generation stuff Ross is working on, is making 'LCC' ( 'Catalina' in this case ) not tied down to hard-wired paths or reliant on environment variables, eg determining where it is when executed and calling CPP and RCC relative from itself. I'm surprised no one's ever done that. I don't have the knowledge on what needs to be done there and I tend to run CPP and RCC separately rather than use the LCC/Catalina wrapper.

jazzed
04-09-2009, 01:41 AM
C users often have a hard time with types. I like spin's three primitive type notation mainly because there is no differentiation between signed and unsigned. For byte, word, and long you can have a Propeller specific typedef header except that you have to decide whether word means short or unsigned short which are treated differently in C. Pseudo-array access if I get your meaning is really just pointer dereferencing ... no?

The % in C is the mod operator ... one would be hard pressed to redefine that. It is also a format specifier and could cause great confusion. The $ is free to change except that some source control packages look for $ in comments ... though that shouldn't matter.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Jo„o Geada
04-09-2009, 01:50 AM
hippy,

I personally would be very much against adding such syntactic extensions to C. No problem with adding routines/macros
that have the same effect but don't touch C syntax.
C is a very popular and very widely used systems programming language for many reasons and has been around successfully
for a long time. I'd not monkey with its basic essential formulation without some *VERY* good reasons.
I'd highly encourage all Parallaxians that don't yet know C to learn it and get familiar with it. Lots of resources on the Web
and lots of algorithms, libraries etc out there coded in C and an effort to learn C will not be wasted.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo„o

hippy
04-09-2009, 03:01 AM
Thanks. I was TBH expecting a 'leave C alone, it is what it is, not something else' from those more experienced C programmers, so maybe an 'off' by default and those who choose to use can enable them and take the consequences of that.

I suppose I was looking at how to make C more Spin like, coming at it from the other direction of making Spin more C like ( I forget who suggested that ). The merits are debatable ( for and against ) and it's true that any change could break the standard C definition.

Re-purposing % isn't really a problem, no more so than already using & for three different things in C, the only code I can think of which would break is 'a=b%c' where 'c' is 0 or 1, though that should generate an invalid expression error rather than silently compile and behave differently to expected.

I've expressed my view before that I believe many procedural languages are simply transformations of another so there's no reason a single compiler couldn't support C, Pascal, VB-style or even Spin all in the same source. Maybe LCC/Catalina is the framework to build on for that but it's getting off-topic and I don't have anything planned in that respect.

Brian Fairchild
04-09-2009, 03:26 AM
hippy said...

...I've expressed my view before that I believe many procedural languages are simply transformations of another...


Same here. I've often said that the trick is getting the code structure, any algorithms and the data flow right. Once you've done that, the 'programming' into your chosen language is almost a mechanical task.

technoweasel
04-09-2009, 05:54 AM
Thanks Ross. I actually don't have my propeller yet (I ordered a protoboard about a week ago), but once it arrives I will definitely check out your compiler. Spin looks pretty cool, but the prop definitely needs a free c compiler. C seems to be the standard for all programming, and I am pretty sure nearly all of us here can write a little C. I really didn't want to learn a whole new language just for micro programming. I guess that is why parallax decided to make the C compiler cost over $100! Anyway, thanks. By the way, are there any other free c compilers for the prop? I searched a bit but could only find your Catalina and the expensive imageCraft version.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world, those who understand binary and those who don't.∑∑ -a poster I saw

RossH
04-09-2009, 08:01 AM
All,

I have to agree with those who don't want to mess with the C language. If you need C, you need it as unadorned and as standard as you can possibly get it. Anyone who has had to port C code from one compiler to another in the days before ANSI or ISO C would tear their hair out at the thought of yet another set of nonstandard language extensions (this is the reason I have no hair left!)

However, having said that, the reason I started writing Catalina in the first place is that it is a first step towards experimenting with a parallel language for small embedded processors. I love Ada, but it has never achieved any penetration here - even though that was one of its original aims. The multitasking model built into the Ada language (a thing of beauty) requires far too much low level support. But the Propeller comes with much of the required support "built in"! There is a huge amount of potential in this area, and I'm keen to explore. SPIN is a good language for many things - but not for this. It would be like trying to write an accounting program in LISP or an AI-program in COBOL - yes you could do it (at least according to Alan Turing) but what kind of demented masochist would want to? I don't mean to be critical of SPIN - the reason it has these limitations is because the entire SPIN interpreter has to be squeezed into a single cog. It's just the wrong tool for the job.

So while Catalina will always support "Plain Old C", I expect it will also eventually support other "Propeller-specific" languages - in much the same way that the gcc compiler supports C, C++, Objective-C, Fortran, Ada etc etc - all with the same compiler, and without compromising the integrity of each language.

Ross.

Bill Henning
04-09-2009, 10:06 AM
Hi Hippy.

Just add this in your main code:

long *LONG=0;
int *WORD=0;
char *BYTE=0;

(above assumes C compiler has 32 bit longs, 16 bit ints, and 8 bit chars, and treats the hum memory is the "real" memory instead of trying to get pointers to cog ram)

Then in your code you can use them pretty much the same as in Spin, but only with one subscript.


hippy said...
Thanks. I was TBH expecting a 'leave C alone, it is what it is, not something else' from those more experienced C programmers, so maybe an 'off' by default and those who choose to use can enable them and take the consequences of that.

I suppose I was looking at how to make C more Spin like, coming at it from the other direction of making Spin more C like ( I forget who suggested that ). The merits are debatable ( for and against ) and it's true that any change could break the standard C definition.

Re-purposing % isn't really a problem, no more so than already using & for three different things in C, the only code I can think of which would break is 'a=b%c' where 'c' is 0 or 1, though that should generate an invalid expression error rather than silently compile and behave differently to expected.

I've expressed my view before that I believe many procedural languages are simply transformations of another so there's no reason a single compiler couldn't support C, Pascal, VB-style or even Spin all in the same source. Maybe LCC/Catalina is the framework to build on for that but it's getting off-topic and I don't have anything planned in that respect.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

OwenS
04-13-2009, 12:57 AM
Bill - your forgetting the fact that the subscript operator in C calculates addresses as:

addr = baseAddress + subscript * sizeof(T).
(Incidentally, this is why so many processors have complex instructions like LEAL 4(%ebx, %ecx, 16), %eax - which is doing %eax = %ebx + %ecx * 16 + 4)

meanwhile in Spin you pass a pointer to the variable to be accessed. I have a feeling that doing that with any variable declared as a pointer in C would (reasonably) generate a compiler error.

The closest emulation I can think of in C is

#define LONG(_x) (*((long*)(_x)))

Obviously it must be noted the vast differences between C and Spin pointer arithmetic and dereferencing. I think a far better solution than mutilating the C language with such additions is a "C for Spin programmers" document - bear in mind how annoying compiling half the files with such features on and half off would be.

Cluso99
04-13-2009, 08:33 AM
could Catalina compile itself (the spin/pasm compiler) to produce an executable Catalina running on the prop? That is, to poduce a spin/pasm C compiler that runs natively on the prop?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Mike Green
04-13-2009, 09:02 AM
No way. The issue is primarily memory. If Catalina were to compile code for external SRAM and there was a couple of megabytes, maybe it could work. There have been C compilers for CP/M and DOS that worked with multiple phases on a 64K byte machine, but those were usually hand coded in assembly and used a more space efficient instruction set than the LMM one of the Propeller. I suspect that it will be fairly easy to produce a native C compiler for the Prop II with its 256K of memory. It will probably be written either in Spin or a Spin-like interpretive code (for space reasons) and will have several phases. It should also be possible to produce an LMM-based C compiler that produces LMM code, but it wouldn't be like Catalina. It would also be multiple phases and tightly written.

Cluso99
04-13-2009, 09:21 AM
CPM2.2 is already running and we will be running CPM 3 in days (with banked memory - maximum 1MB, but we are going for a mix of memory and ram disk) and we will have all those resources including Borland Pascal and C. But this is CPM hosted, so why cannot the Propeller work - IT IS POSSIBLE on the Prop 1. We have heaters ZiCog emulation running at about a 3.7MHz Z80 speed and there maybe room for tweeking (maybe something for later).

I guess it's all this negativity that bothers me. :-(

I can and will write a pasm compiler if required, but have so little experience with C it's not possible for me.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Mike Green
04-13-2009, 09:48 AM
Cluso99,
I don't mean to sound negative. The question was whether Catalina could compile itself for use natively on the Prop I. Catalina is a compiler design that's not meant for small machines with limited memory. I've written a lot of compilers over the years including a Z80 Pascal compiler that ran in about 48K under a fancier operating system than CP/M. You can get a lot more instructions in 48K using the Z80 (or 8080) instruction set than you can with Prop LMM and, although you get 32 bit arithmetic on the Prop, most of what you need to do in a compiler involves bytes and words. I think it's possible to produce a C or Spin compiler in Spin for the Prop I with maybe 4-6 phases using some kind of mass storage, probably an SD card. At the very least, you need a lexical scanner, a parser, maybe a separate storage allocator (particularly for C), and several code generation phases. The same sort of design would also work if it were done in Z80 or 8080 instructions under CP/M. I started a PBasic-like compiler in Spin for the Propeller just to see what would be involved and, of course, it ran out of room, but it could process declarations and some simple expressions and statements and generate LMM code that looked like it might work.

Cluso99
04-13-2009, 12:30 PM
Mike,
As you know, I have 1MB of memory (external Ram) and 2GB of SD card memory (microSD) available.

My interest is in getting this hardware to compile native code for the prop on the prop. I want to get the first stage running which is obviously just a PropTool compatible spin/pasm compiler executing on the prop to produce a compatible PropTool binary. Subsequently, some other bytecode or LMM is entirely feasible using Spin, C, Pascal, Basic or whatever.

Currently we can assemble/compile using the ZiCog Z80 emulator, 8080/Z80 opcodes and CPM. We can use Pascal, assembler Basic, etc, but all 8080/Z80 based, and running on the prop under emulation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

hippy
04-13-2009, 08:40 PM
Cluso99 said...
could Catalina compile itself (the spin/pasm compiler) to produce an executable Catalina running on the prop? That is, to poduce a spin/pasm C compiler that runs natively on the prop?


Accepting all Mike says; it is possible ( I said this elsewhere ), and is how some compilers are ported to other architectures.

Assuming there is nothing in the compiler source that Catalina cannot understand and generate correct code for and all the necessary libraries work as expected on a Propeller -

1) Compile Catalina on Windows/Linux/Mac to get an executable Catalina which runs on that OS ( eg, catalina.exe ), or take the provided binary executables.

2) Compile the Catalina source using catalina.exe, link, assemble and you should ultimately end up with a Catalina.Spin/.Eeprom.

3) Catalina.Spin/.Eeprom is a C compiler which runs on the Propeller.

The problems are -

1) There may be something which stops Catalina compiling its own or library source code.

2) The low-level libraries may not provide support for the interaction needed with the Propeller and its hardware when it runs ( eg, where does getch() read from, how ? )

3) The created .Spin/.Eeprom file may be far bigger than what is allowed so some mechanism to work round that is needed.

You can try much of this with what is provided.

The main work is in providing a run-time environment which executes what Catalina produces and low-level libraries which allow user programs ( in this case the compiler itself ) access into and through that environment.

Obviously, the Propeller hardware needs to be able to provide enough memory for Catalina to run but that's down to the Catalina Kernel. It may be in a Cog which never accesses Hub Memory, using only XMM or SD Card with scant regard as to how quickly that were to be worn out.

As to how fast it would be or its inherent efficiency ... that's a issue of practicality of final implementation, not an issue of ability to do it. It doesn't matter if Version Alpha One takes an hour to compile an empty 'main', just that it works. Everything after that is optimisation and improvement.

Maybe it never would or could be as good as a compiler created some other way, but that's a different issue to the question asked. Whether it's worth trying this route is a personal decision to make.

Brian Fairchild
04-13-2009, 09:52 PM
Depending on what 'flavour' of C you wanted it should certainly be possible to port Small C to the Prop.

I've ported it to 2 or 3 different CPUs over the years. First port was from Z80 CP/M 2 to 8086 and CP/M 86. Then to MSDOS and then, IIRC, to 8051. As written it's a four pass compiler and could be coaxed to run on 48k CP/M systems. It's certainly close enough to ANSI C to make an interesting learning platform.

hippy
04-14-2009, 01:32 AM
Some good news -

LCC can compile itself so no reason catalina cannot. A couple of overflow warnings for 0x7fffffffffffL in dag.c and string.c which I presume is max int at 64-bit ( long long ).

I counted around 600KB of C-LMM produced, 300KB of bytecode, when stripped to a single back-end code generator. That's unoptimised bytecode so seems to fit with the 3:1 size ratio which has come up before.

RossH
04-14-2009, 08:05 AM
All,

Gosh - and I thought I was being ambitious! There is nothing inherent in Catalina itself that would stop it being "self compiling" - as hippy points out, LCC certainly is.

However, the first problem would be that the resulting PASM files would be far too big for the existing PASM assemblers. There is a limitation on the current Parallax Propeller Tool of 1024 DAT symbols - I don't think Parallax ever intended their tool it to cope with LMM programs, just cog programs (since these are limited to 512 instructions, it is unlikely they would ever need even that many symbols).

I have already hit this limit several times - LCC generates lots of symbols for language constructs like 'case' statements - but so far only on code that is too large to fit on the Prop in any case. I have therefore deferred implementing a workaround until I get the generated code sizes down a bit. Brad's SPIN Tool may not have this limitation, but I cannot check without constructing a specific test case since the current version quits assembling as soon as the result would exceed the 32K Prop limit. I have not tried HomeSpun with Catalina yet.

Ross.

BradC
04-14-2009, 02:02 PM
RossH said...
All,

Brad's SPIN Tool may not have this limitation, but I cannot check without constructing a specific test case since the current version quits assembling as soon as the result would exceed the 32K Prop limit.


There are no limits to the number of symbols you can use with bst, however as you noted it will choke on anything that produces a binary greater than 32K. I could not see a point exceeding that as I have no extensions in there to enable paging or LMM style code. I believe Bill Henning is writing an LMM assembler though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

RossH
04-14-2009, 09:52 PM
Hi Brad,

Glad to hear bst does not have the limitations of the Parallax Propeller tool - bst is definitely my preferred option for compiling PASM. For one thing it produces great listings that make debugging LMM code much easier! But there is one nice feature in the Parallax Propeller tool when compiling LMM code - when it tries to compile a file larger than 32k it tells you exactly how many longs over the limit the resulting object would be - very handy when you are trying to squeeze a 32.1k C program into 32k!

I'll be interested in seeing Bill Henning's PASM assembler, but I'm not what he intends to add that would make me switch away from bst - are you suggesting he's intending to add some kind of overlay or external memory support? I have tried to keep my LMM code compatible with all the existing PASM compilers (apart from funny limits like the ones already discovered), but for features like those I'd be prepared to switch!

Ross.

Cluso99
04-14-2009, 10:34 PM
RossH and others:

Currently∑what I am looking for is to be able to compile C and/or Spin and/or Pasm prop programs∑on the Prop. It doesn't have to be able to compile programs that will not run on a standard prop, but I do need a standard prop binary output file up to 32KB. The compiler will have access to 1MB of external ram and 2GB of SD memory. I can write the necessary drivers for this section.

I have already done pretty much that in pasm now for ZiCog/CPM for ram access including a ram disk and have extended the Femto SD routines. ZiCog and CPM2.2 now boots from PropDos on an SD card as a prop binary on the TriBladeProp board. MBasic, etc all run.

Heater and I∑expect to boot CPM3 with 256KB Ram using bank switching later this week. CPM2.2 has been running for a while now.

It is just a shame we have to run a Z80 emulation to get access to all this stuff. Oh, and the emuation is running at the speed of a∑3.7MHz Z80 (4MHz on a real chip).


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

hippy
04-15-2009, 01:51 AM
Perhaps your next step Cluso99 is to write a CP/M program which will launch the Catalina Kernel in a Cog and have it execute a small Catalina produced .Eeprom file which has been stored on SD Card.

Once you have that it's just a scaling-up to be able to run the Catalina compiler itself on the Prop ... once someone works out how to link a bigger than 32KB .Eeprom file and get it on SD.

Bill Henning
04-15-2009, 02:57 AM
That's correct.

I have it limping along, not release quality, and I intend to demonstrate it at the Propeller Expo - along with some other LMM goodies that I will not announce until they are done - I hate unexpected things delaying me and don't want it to happen again http://forums.parallax.com/images/smilies/smile.gif

(I started LAS it right after I came up with LMM a couple of years ago, however I had too much consulting work to finish it before now)


BradC said...

RossH said...
All,

Brad's SPIN Tool may not have this limitation, but I cannot check without constructing a specific test case since the current version quits assembling as soon as the result would exceed the 32K Prop limit.


There are no limits to the number of symbols you can use with bst, however as you noted it will choke on anything that produces a binary greater than 32K. I could not see a point exceeding that as I have no extensions in there to enable paging or LMM style code. I believe Bill Henning is writing an LMM assembler though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

Cluso99
04-15-2009, 07:10 AM
Thanks all. I will keep the CPM updates coming via the ZiCog and TriBladeProp threads.
Anyone who wants to seriously get Catalina running on the TriBladeProp PM me. The same goes for the pasm compilers.

I am about to announce another preassembled solution for the masses. http://forums.parallax.com/images/smilies/cool.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

RossH
04-15-2009, 08:46 AM
Hi Cluso,

I'm impressed with your TriBlade Prop, and would love to have a go at getting Catalina up and running on it. But it will have to be after the next Catalina beta release - that should be out later this week.

The next version of Catalina rewrites the code generator quite substantially. It fixes a few bugs in the existing code generator and has major optimizations to reduce the final code size. I will also release what I hope will be the 'final' Catalina LMM Kernel, plus a new 'alternate' kernel, which has free space intended for user customizations (e.g. kernel support for the TriBlade Prop!)

Some other goodies are also coming in the next release - such as a debugger with built-in support for Catalina LMM PASM - it can disassemble LMM, set LMM breakpoints, single step through LMM and switch between cog debug mode and LMM debug mode.

Ross.

BradC
04-15-2009, 10:48 PM
RossH said...
Hi Brad,

Glad to hear bst does not have the limitations of the Parallax Propeller tool - bst is definitely my preferred option for compiling PASM. For one thing it produces great listings that make debugging LMM code much easier! But there is one nice feature in the Parallax Propeller tool when compiling LMM code - when it tries to compile a file larger than 32k it tells you exactly how many longs over the limit the resulting object would be - very handy when you are trying to squeeze a 32.1k C program into 32k!


Most peculiar. Which version are you running?

For quite a while now it's produced this :



Untitled - Binary too large for RAM by 6777 Longs.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

RossH
04-16-2009, 09:36 AM
Hi Brad,

I'm not at home at the moment so I can't check the exact version of bst I use, but it is fairly recent. I don't see the message you describe when I call bst from within lcc, but this may be due to the way I am invoking it. Some of the bst output seems to get obliterated by mutiple messages about the memory limits being exceeded (I can't recall the exact wording off the top of my head - I'll PM you an example when I get home). I'll try invoking bst manually and see if I get the message you describe.

Ross.

BradC
04-16-2009, 08:30 PM
RossH said...
Hi Brad,

I'm not at home at the moment so I can't check the exact version of bst I use, but it is fairly recent. I don't see the message you describe when I call bst from within lcc, but this may be due to the way I am invoking it. Some of the bst output seems to get obliterated by mutiple messages about the memory limits being exceeded (I can't recall the exact wording off the top of my head - I'll PM you an example when I get home). I'll try invoking bst manually and see if I get the message you describe.

Ross.


I'll bet the problem is related to single object files. In the "link" phase I check for oversize and report an error, but if a single object file exceeds 32k I probably just blow up. Let me look at it a bit closer and see if I can make the error message a little more informative. It's somewhat academic anyway as it'll produce an error in any case.

As much as I love my compiler, I've never written one before and the error handling is a little agricultural (at best). This is evidenced by the not-infrequent null pointer dereferences people see when they bend it in ways it's not designed to be bent.

If I ever get the time to re-architect it, I'd hope it was a bit better. mpark put me onto Jack Crenshaw's "Lets build a compiler", but unfortunately I'd already finished mine before I even read his papers (and we both wrote ours in the same language). Mine is uglier. I wager Michaels blows up less.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

RossH
04-20-2009, 06:25 PM
All,

The second beta release of Catalina is finally ready. See the first post in this thread for updated documentation, and the second and third posts for new linux and win32 source code and binaries.

Here's a summary of what's new in beta 2:

Many code generation fixes – Catalina now successfully passes all the C tests included with the lcc compiler itself (note that some of the test programs need to be split into parts small enough to run on the Propeller);

Register passing and trivial peephole optimization has been added - typical code sizes have been reduced by ~20% (up to 50% in some cases);

A new alternate kernel is provided which has 100 longs free space (to encourage experimentation);

New targets have been added that that use the debug kernel and the alternative kernel;

The HMI plugin now implements tabs (tabs fixed at size 8);

The HMI plugin now interprets Ctrl-D entered on the keyboard. Ctrl-D now returns EOF (-1);

Case sensitivity for C identifiers – since this has complicated the internal names used for identifiers, the Catalina binder now prints both the mangled and unmangled names of all identifiers;

The Catalina binder now differentiates between undefined symbols and redefined symbols. Redefined symbols can occur (for example) if a library is specified more than once in the lcc command – previously this would cause the binder to report that all the symbols in the library were undefined (when in fact they were multiply defined);

New HMI utility function t_printf – an alternative to the C89 printf for printing strings, integers, unsigned, float or characters using printf-style formatting, but which requires significantly less code space than printf;

Support for Catalina LMM PASM programs (disassembly of LMM code in hub RAM, set breakpoints, single step etc) has been added to POD.



Ross.

heater
04-21-2009, 03:56 AM
Well someone has to comment on this before the day is out.

I just downloaded the Linux version and gave it a try, no idea if the generated code works yet as my home made demo board is a bit sick again, but it builds a hello world which I can load into bst and inspect/compile just fine.

Only have to figure out how to fire up the ZiCog Z80 emulator PASM from C now. Can I really replace all the surrounding Spin with C?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH
04-21-2009, 06:12 AM
Hi heater,

I'm not sure I'd bother replacing Spin with C just to get ZiCog running - in any case you wouldn't be eliminating the need for Spin since Catalina uses it itself during startup. It's handy to bootstrap from Spin since it gives you an opportunity to use existing Spin objects in conjunction with C programs (Catalina allows this as long as the Spin objects don't use VAR space at runtime).

But if you do get your Demo board working again, I'd appreciate it if you could let me know of the "demo" Catalina target works ok - I only have a Hydra, and have never been able to test it.

Ross.

RossH
04-22-2009, 10:06 PM
Apologies all - I have had to re-release beta 2 as I found a couple of bugs - C programs with identifiers longer than about 24 characters would fail to assemble, and programs using floating point may crash. Both problems have now been fixed and new source and binary files have now been uploaded.

Ross.

heater
04-22-2009, 11:34 PM
A little problem: When logged in as non root on linux I can't compile.

ddt:~$ lcc hello.c -Wl-tdemo_tv
Brads Spin Tool Compiler v0.14 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 22:54:26 on 2009/02/23
Found a USB Serial Device
Loading Object lmm_demo_tv
Loading Object Catalina
Loading Object Catalina_LMM
Loading Object Catalina_HMI_Plugin_Tv_d
Loading Object Catalina_comboKeyboard
Loading Object Catalina_mouse
Loading Object Catalina_TV_Text
Loading Object tv
An unhandled exception occurred at $08050F85 :
EInOutError : Access denied
$08050F85
$0804F49F
$0804D9F2
$080481E2

This is odd because I am in the correct group to access my USB serial adapter, BST has worked just fine. Also if I change ownership and or permissions of my /dev/ttyUSB0 so that anyone can read/write it still fails.

Why is BSTC wanting to access this just to compile anyway ?

Edit: Hmm.. looks like it's not the USB device that is the prob. If I log in as root and remove read/write access to my /dev/ttyUSB0 entirely I can still compile as root but not as user.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 4/22/2009 4:40:11 PM GMT

RossH
04-23-2009, 07:16 AM
Hi heater,

I'll try and reproduce this when I get home. Looks like bstc is having permision problem writing its output file. I'm afraid I tend to test while logged in as root (my bad!) so I have not noticed it. I assume that the user you are logged in as has write permission on the directory you are working in?

You could try running bstc independently of lcc to get some more clues. Try something like the following:

lcc hello.c -Wl-a -o error.spin
bstc error.spin -b

The "Wl-a" option tells lcc to compile and bind but not assemble (i.e. don't run bstc from within lcc). After running bstc manually you should get a file called "error.binary". Note this binary cannot be executed - it does not include Catalina Kernel - but at least it would tell us whether it is a bstc or an lcc problem. If it is bstc I may have to rely on BradC for help.

Ross.

heater
04-23-2009, 01:14 PM
Of course, having run this as root there is an a.out.binary in the user directory that is owned by root. Changing ownership of that or deleting it gets us going again.

So busy thinking about what goes on in /usr/local/lib/catalina I didn't think to look at home.

Still curious as to why bstc is worrying about /dev/tty....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH
04-23-2009, 02:59 PM
Hi heater,

Glad you figured it out.

Apparently bstc can also be used to load the resulting image to the Propeller - a feature I've never used, but that's probably why it's looking for a serial port. Use bstc -h to see all the options.

Ross.

heater
04-23-2009, 05:49 PM
Well there is one reason I may want to use C in conjunction with the ZiCog emulator. That is to be able to use a FAT32 file system on SD cards for storing the CP/M disk images.

Just for fun I compiled this FAT32 implementation elm-chan.org/fsw/ff/00index_e.html (http://elm-chan.org/fsw/ff/00index_e.html) with Catalina. Just the FS layer no SD driver or application.

The resulting binary for the demo board target is 1650 longs to big to fit.

Compiling with -S results in a an assembler output of 8424 lines. So give or take the labels in there about 33.5K bytes of instructions.

So this is not really feasible. Putting the PASM into XMM would do it I guess but at a cost in speed and size of RAM disk we have in mind for CP/M.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH
04-24-2009, 06:50 AM
hi heater,

I don't really think this would get the size down anywhere near far enough, but you could try customizing your target and removing the HMI drivers (e.g. mouse) which you probably don't need. Alternatively, compile your program using the "no_hmi" target.

Ross.

BradC
04-28-2009, 10:16 PM
RossH said...
Hi heater,

Glad you figured it out.

Apparently bstc can also be used to load the resulting image to the Propeller - a feature I've never used, but that's probably why it's looking for a serial port. Use bstc -h to see all the options.

Ross.


Absolutely right. bstc scans the serial ports on startup whether you requested a propeller load or not. I should change that I guess....

I kinda wrote bstc to be sort of propellent compatible. So it had to be able to auto-locate a propeller, plus compile for it on all supported OS's including those many bodgy hacks from Redmond... (Win95->) I might not have thought things through completely before I wrote them however as it's been years since I had to deal with those train wrecks..

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

RossH
05-18-2009, 11:57 AM
All,

The third beta release of Catalina is finally ready. This release adds XMM support, so C programs can now be larger than 32K.

The only XMM platform currently supported is the Hydra Xtreme 512K SRAM card, but I expect Cluso99 to provide me with a TriBladeProp sometime soon.

Many thanks to Michael Park for his Homespun compiler, which can now compile PASM programs larger than 32K.

See the top of this thread for details and for new documentation, demos, sources and binaries. Only the Windows binaries are there at the moment - I'll add the linux binaries later today.

Ross.

jazzed
05-18-2009, 12:52 PM
Hi Ross,

Thought I would take this for a spin. Ran build_demos.bat ...
things seem ok except for "too many arguments to _dira" and looking for bstc.

C:\Catalina\catalina_demos>lcc test_leds.c -lc -o test_leds -Wl-tno_hmi
test_leds.c:8: too many arguments to `_dira'
test_leds.c:9: too many arguments to `_outa'
test_leds.c:13: too many arguments to `_outa'

Trying out build_test_suite_xmm.bat gives:
C:\Catalina\catalina_demos>lcc test_suite.c -lc -Wl-x2 -o test_suite_xmm -Wl-w-e
unrecognized switch: -x2

Same for Startrek and Othello.

My platform is Windows XP SP3 with .net 3.0.

This is my first attempt at using Catalina. Do I need bstc ?

Reading your docs, you mention using HAM for XMM stuff.
Are you able to generate an intel-hex file?
I have a hex loader I was using with ICC for doing serial XMM downloads.
Maybe you can use that ... beats the heck out of programming eeproms.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
05-18-2009, 01:00 PM
Hi Jazzed,

It seems you have a mix of old and versions of Catalina. Using an older version the catalina.exe program would explain the 'unrecognized switch' problem - the '-x' swich is new to this version. And using an old version of the library explains the 'too many arguments' problem - I added a new argument to these functions in this release.

It all works for me here. I may have stuffed up my zipping - I'll check and report back. In the meantime, if you had an older version of Catalina installed, please delete it and install the new one from scratch.

jazzed
05-18-2009, 01:20 PM
You're right. I did have an old version. No idea why the old one was being run ... didn't see anything in the environment. Shrug shoulders. I had put the new copy in C:\Catalina. I'm set now. I'm still scratching my head over using HAM though ... enough for today. Bed time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
05-18-2009, 01:21 PM
Hi Jazzed,

I though maybe I had forgotten to update one of the zip files, but I just deleted my Catalina directory, downloaded the win32 binaries and demos from the links at the top of this thread, installed them and then compiled the demos again. All works fine for me. Perhaps when you grabbed the binary zip file you were still getting a cached copy of the last release.

You could try flushing your browser cache, reloading the page from source (hold down the CTRL key while pressing the REFRESH button - but this doesn't work on all browsers) and download and install again.

If you still have problems after that then let me know.

Ross.

Post Edited (RossH) : 5/18/2009 7:37:15 AM GMT

RossH
05-18-2009, 01:39 PM
Hi Jazzed,

Glad you got it sorted.

You don't really need HAM (for those who don't know what HAM is - it's the Hydra Asset Manager, designed to allow the use of the eeprom space on the Hydra platform above the normal 32K that gets loaded into the Propeller on boot).

Perhaps I should make that clearer in the documentation that any program that can put the program images produced by Catalina into an eeprom would do. And if you want to modify the Catalina XMM Loader, you could have the images stored anywhere. Cluso99 pointed out that I could easily replace the Basic I2C driver with an SPI driver, and thereby have SDRAM support as well - I'll investigate this for the next release.

But at the moment the only XMM platform I have for testing any of this stuff is my Hydra/Xtreme combo, so for me HAM is the obvious solution.

I'm finding I'm spending way too much time on the non-core parts of Catalina (for example, I just spent 2 days trying to get Mike's Basic I2C driver working - still not exactly sure why it wouldn't work - so instead I ended up rewriting it as a PASM driver).

Ross.

RossH
05-18-2009, 08:30 PM
All,

I have updated the linux source and binaries with the latest release.

NOTE: I have included homespun.exe in the linux binary distrubutions, as homespun is supposed to run on Linux under the 'wine' Windows emulator - but I have been unable to get it to run myself. I will update the release (if necessary) when I solve this problem, but I am releasing the distributions anyway since bstc can also be used as the PASM compiler. To use bstc, download it, install it, and then put a link to it called 'bstc' in the main Catalina directory. Then compile programs with the -Wl-b option to LCC. This is more fully explained in the documentation. Note that XMM support is not available when using bstc.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

BradC
05-18-2009, 09:11 PM
RossH said...
All,

I have updated the linux source and binaries with the latest release.

NOTE: I have included homespun.exe in the linux binary distrubutions, as homespun is supposed to run on Linux under the 'wine' Windows emulator


No it won't. Wine is for running Win32 binaries. homespun is a .Net application and you need to run it with Mono (and the resulting 100MB download).




brad@bklaptop2:~$ mono homespun024.exe Fruit_Machine_TV_001
Homespun Spin Compiler 0.24
parsing Fruit_Machine_TV_001.spin
compiling Fruit_Machine_TV_001.spin
writing Fruit_Machine_TV_001.eeprom


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

mpark
05-18-2009, 11:00 PM
"Fruit Machine"?? Just what are you working on, Brad?

RossH
05-19-2009, 05:24 AM
BradC said...
No it won't. Wine is for running Win32 binaries. homespun is a .Net application and you need to run it with Mono (and the resulting 100MB download).



Ah!. Thanks Brad - I was trying to install .Net under wine, which wasn't working.

I'll test it again tonight and update the documentation.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

BradC
05-19-2009, 05:36 AM
mpark said...
"Fruit Machine"?? Just what are you working on, Brad?


I wanted to learn how to blit so I wrote a slot machine simulator. It loads 8 bitmaps off SD card, then creates 3 virtual rolls from these 8 images in random positions. Then it scrolls them round the screen just like a slot machine would, coming to rest completely randomly in left to right order. It was also my introduction to writing TV drivers and using multiple cogs to render to the same driver :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

RossH
05-19-2009, 06:31 PM
All,

I've uploaded new sources and binaries for the Linux release of beta 3.

No functional changes, but Homespun is now invoked correctly under the "mono" open source dotnet runtime. A new "README.Linux" file has been added describing the mono packages that need to be installed - they take about 10Mb disk space in total (BradC's "100MB" is true only if you download all the mono development libraries).

None of these changes affect the Windows release. There were a couple of linux script changes, and a few problems caused by Linux being case sensitive in places where Windows is not. I also added some scripts for building the demos under linux - please download the catalina_demos.zip file again to get these.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

grahamreitz
05-21-2009, 05:40 AM
How does the Catalina compiler compare to ImageCraft's C compiler (not necessarily the IDE) in terms of performance and features? (versus being free and running on Mac/Linux, which is awesome!)

Is it the 'same' thing since they are both based on LCC?

Kindly,
graham

RossH
05-21-2009, 07:25 AM
Hi Graham,

To be honest, I'm not really sure. I've been far too busy to find out :) But here goes with what I do know ...

Both Catalina and ImageCraft are based on LCC, so they will be very similar in the 'dialect' of C they support - unless ImageCraft has added their own extensions to the language. Catalina has no extensions - it is just plain old ANSI C.

However - and I'm simplifying outrageously here! - all LCC really gives you is the ability to parse A C program into a syntax tree. The code generation of the two compilers is completely different, as are things like the stack model, the parameter passing mechanism, memory management, cog management etc etc.

Our LMM Kernels take completely different approaches, since I concentrated on building in things like floating point support from day one, whereas this was absent in the early versions of the Imagecraft compiler and added later (I don't know if is in part of the ImageCraft Kernel or not). Catalina provides the ability to choose between zero, one or two cogs dedicated to floating point. On the other hand, I believe Imagecraft concentrated on improving execution speed generally by sticking closely to Bill Henning's (and others) original LMM proposals, including the ability to cache small amounts of hub ram in the kernel cog to speed up execution of small loops. However, to compensate I suspect Catalina offers better support for register variables (including floating point register variables). So I would expect Catalina to be faster in some areas such as floating point, but slower in other areas. I have not run any comparisons, but if you (or anyone) cares to, I'd be happy for you to post the results here.

Our approach to integrating with PASM and SPIN is probably different. Catalina uses SPIN during initialization, which makes it fairly easy to include existing drivers (with some restricitons and modifications) and it can also include other PASM programs by defining 'plugins' accessible from C (a 'plugin' is basically a program running in another cog). I have no idea what Imagecraft does in this area.

Catalina offers a rich variety of Human Machine Interface (HMI) options - various combinations of Hires and Lores TV, Hires and Lores VGA, Mouse and Keyboard support for any platform with the appropriate hardware. Catalina provides a platform-independent execution environment for the C program by defining 'targets' that encapsulate all the platform dependent HMI issues. The HMI gets completely loaded and initialized before the C program starts up. This gives the C program a standard interface to the HMI no matter what the platform. The early versions of ImageCraft offered fairly basic support for the HMI, but they may have added more drivers in their recent releases.

Our approach to linking is significantly different. I think ImageCraft uses a traditional compile-assemble-link paradigm. When I started Catalina there seemed to be no language independent linker available for the Propeller (I subsequently found out about OwenS's work, but have still not had time to investigate this thoroughly). Since I did not want to spend time writing my own asembler and linker - a major job in itself - I used a compile-bind-assemble paradigm. Much simpler, and perfectly suited to an embedded enviroment where every program has to end up as a stand-alone binary image. This means that things like the Catalina C libraries exist in source form (PASM, not C) and not object form. The Catalina Binder does source level manipulation to combine the various components into a final source file - and then uses existing Propeller tools (such as the Parallax Propeller Tool, bstc, or Homespun) to turn the resulting program into binary form. For most purposes, users will never see any difference - but this probably makes Catalina slower to compile. However, it means Catalina can rely on the good work of others to do much of the hard stuff :)

Our libraries themselves are different. Catalina uses a public domain C89 libarary, whereas I believe ImageCraft uses a C99 library - but in an embedded environment that would probably make very little difference to most people.

Again, I have not run any tests, but I think that Imagecraft would produce more compact code than Catalina. However, Catalina offers an XMM option to allow programs larger than 32K to execute from external RAM, so this is not such an issue. I am unaware of ImageCraft offering XMM support, but I believe they have been working on it, so if they don't offer one already I'm sure they soon will. The Propeller's 32K onboard RAM is enough for an interpeted language like SPIN, but is simply not enough for largish C programs. However, when the Prop II arrives .... !

I would encourage ImageCraft (or anyone who uses ImageCraft) to respond to your question here as well. Since Catalina is completely open source, everyone has an opportunity to examine the guts of Catalina in all it's gory details - so I'm sure ImageCraft and others will know more about the differences than I do.

Since others will no doubt bring it up again, I should mention the licensing. Parts of Catalina (including the Kernel and the Binder) are currently issued under the GNU Public Licence (GPL). This doesn't mean you can't use them in commercial products and charge money for products that use them, but it does mean that if you use them you must (a) acknowledge their origin and (b) make your source code available. I have already said that when I'm ready to take Catalina out of beta status I may revisit this (at least for the Kernel, so you don't have to release your products source code), but that is how things stand at present. Partly, this is my choice to avoid undercutting the good work that ImageCraft have done.

Finally, ImageCraft is a finished product, whereas Catalina is an ongoing work still very much in beta release. However, since my acquisition of a new TriBladeProp has been delayed (which means I can't do much more on XMM support at present) I may take this opportunity to go back, finish things like the implementation of the C89 library, polish things up generally and issue a first 'official' release.

In summary, if you want a C compiler for commercical use, then at the moment you should probably buy ImageCraft's compiler. If you are still experimenting or are a hobbyist, you may find Catalina suits you better. And it's free!

Hope this helps,

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

jazzed
05-21-2009, 08:37 AM
Ross,

As an ICC user, and one who has looked through your implementation, I think you have summed up the differences pretty well. I still don't get how to put together an XMM image after reading your doc otherwise, I would be doing that for the 2 boards I have. If you summaried your XMM build process, that would help. For example, is it possible to use it without first writing EEPROM ? I would much rather download a binary.

Richard has added XMM extensions to a private build of ICC ... and that's what I've been using. The ball is in his court for productizing XMM-ICCPROP.

ICC does offer some extentions to C89 such as one line comments and enhanced printf (no dynamic arrays or inline functions).
GNU C is the Linux variety. Linux relies heavily on inline functions. I've never seen a dynamic array in Linux but that doesn't rule them out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
05-21-2009, 09:21 AM
Hi Steve,

At the moment, I use HAM (http://forums.parallax.com/showthread.php?p=628778). Although HAM stands for Hydra Asset Manager, I don't think it is Hydra-specific, I believe it should work on any Propeller Platform with an external EEPROM larger than 32K - which you have to have to run the resulting XMM program anyway.

I'll go through the steps I use to compile/load the startrek demo (this is from memory - check my docs and HAM itself for details):

1. Compile your Catalina program as an XMM ('-x2') file, and generate an eeprom image ('-e') of the result:


lcc startrek.c -o startrex_xmm -Wl-x2 -Wl-e


This should give you a 64K eeprom file called startrek_xmm.eeprom. This is a pure PASM program, and needs to be combined with an XMM target.

2. Choose your target - For startrek you need to use the hires TV XMM target. You will find an eeprom file in the Catalina 'target' subdirectory called xmm_hires.eeprom. All the XMM targets are 32K eeprom files. If you need to modify them, just compile them with any SPIN compiler and overwrite the existing eeprom files.

3. Start HAM. It is a drag-and-drop application that shows you the layout of an imaginary eeprom up to 128K. You drag and drop the file xmm_hires.eeprom and set its start address to $0000. Then drag and drop the file startrek_xmm.eeprom and set its start address to $8000. You can do this by just dragging and dropping both files in the correct order and then pressing the 'Compress Assets' button. This gives you (in the PC memory) an image of what you need to program into the Propeller's eeprom. Unfortunately, you can't simply save the result to file on the PC at this point - you have to actually upload it.

4. To upload the image into the Propeller's eeprom, you first upload the HAM driver to the Propeller. That takes about 15 seconds. Then you upload the actual eeprom image to the Propeller. This takes about 1 minute.

That's it - reset the Propeller, and enjoy 'Super Star Trek' in all its original monochrome character-based glory!

If you want to save a copy of the eeprom locally for future use, you need to use HAM again - you again upload the HAM driver to the Propeller, but this time you download the entire Propeller eeprom to a local PC file. Unfortunately, I think HAM always saves it in .eeprom format, not .binary format.

It should be easy to write a program that does essentially the same job without requiring either HAM or a Propeller - i.e. just input two .eeprom files and output a combined .eeprom file. If I get time, I'll add this to the next release of the Catalina Binder to make the whole thing a one step process.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

ImageCraft
05-21-2009, 09:33 AM
re: ImageCraft C

Sorry, been busy for a few days. One thing I want to make clear is that we spend A LOT OF effort in optimizing the code from the LCC. Remember our bread and butter are things like compiler for the 8 bits AVR where code size is paramount. So for example, we have automatic register allocation and can pack multiple variables into the same registers if their uses do not overlap etc. We also have capability to do dataflow and peephole, far more extensive than plain LCC facility.

These features will be worked on and enabled on the Propeller C as demand warrants.

// richard

grahamreitz
05-21-2009, 10:21 AM
Thanks Ross!

That's an outstanding answer and I really appreciate the effort you took to write it up.

I recently purchased the non-commercial version of the ICC compiler and planned to upgrade to the commercial version as soon as I had more time to evaluate it. So far I really like it. It's much better than the PIC C compilers that I have worked with in terms of features and documentation. The only major limitation is that it only works on windows. An ICC Linux/OSX version, even if it was only a command line version, would be a huge improvement. A Code::Blocks + ICC would be a sweet combo.

Although, I am intensely interested in Catalina, esp. if it supports Linux/OSX. I personally prefer OSX.

As an aside, the propeller HW design is absolutely fascinating, especially in its simplicity. I was really getting tired of all dizzying architectures of the PICs. It was hard to keep track of the various caveats and etc.

Kind regards,
graham

RossH
05-21-2009, 12:34 PM
Graham,

No worries - enjoy your Propeller programming whichever compiler you choose to use. It's a great piece of engineering.

And if you get a chance to do any direct comparisons, by all means post the results. If ImageCraft wins they'll sell more compilers - but that doesn't cost me anything. And if Catalina wins then richard will have to actually implement some of those code optimizations, which will make his users happy, and will probably end up with him selling more compilers in the long run anyway.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

ImageCraft
05-21-2009, 01:06 PM
More "drive by answers," sorry, it will be a crazy weekend for me...

re: Jazzed and XMM
I'd like ICC-XMM to work on a couple reference platforms such as your board and Clous99's board before release. There never seems to be enough time to do everything I want or need though, so things move in spurts.

re: Linux / OSX
As I have communicated with Graham, our next-gen IDE will likely be based on code::Blocks, and all the compiler tools will be ported to Linux/OS X. Release time TBD. See first bullet.

Thanks and regard,

RossH
05-21-2009, 01:40 PM
@all

IDE? Why would you need an IDE when you have commands as simple and self-explanatory as:



lcc -Wl-w-e -Wl-thires -Wl-x2 startrek.c -Wl-v -Wl-M65536 -o startrek_xmm -Wl-d -lc -lma


Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

BradC
05-21-2009, 03:07 PM
RossH said...



lcc -Wl-w-e -Wl-thires -Wl-x2 startrek.c -Wl-v -Wl-M65536 -o startrek_xmm -Wl-d -lc -lma




That makes perl look readable!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

Leon
05-21-2009, 03:08 PM
Makefiles deal with that problem!

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

RossH
05-21-2009, 03:54 PM
Makefiles? Makefiles are for wimps!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

stevenmess2004
05-23-2009, 03:04 PM
I don't want it but purely to satisfy my curiosity. Will you be able to use Catalina to compile and run linux (or some other os) now that you have the XMM mode? With 512kB it must be getting close...

RossH
05-23-2009, 03:47 PM
Steve,

There are linux systems that run in less space, so it should be possible once I put the data segments into XMM as well as the code segments. But linux really also needs virtual memory and disk storage. I don't know of anyone that has a disk drive connected to a Prop yet - but I suppose it's only a matter of time :)

Virtual memory is fairly trivial to implement in software, but on the Prop doing it this way would probably be too slow to be much real use even using fast XMM. VM should really be done in hardware. Of course, first we had LMM, then XMM, so the next logical step is VMM :)

More likely is that someone will port one of the non-virtual RTOS's specifically designed for embedded applications.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

BradC
05-23-2009, 05:20 PM
RossH said...
Steve,

There are linux systems that run in less space, so it should be possible once I put the data segments into XMM as well as the code segments. But linux really also needs virtual memory and disk storage.


Linux also relies on a number of extensions to GCC and has historically been quite awkward to port to other compilers. There is a non-mmu variant floating around that runs on a 640k 8086/8 processor, but with no mmu you lose fork and porting traditional tools becomes somewhat harder. Busybox will run on a non-mmu system though.

My mips router here has 4MB of Flash and 16MB of ram and runs linux quite comfortably, but you either need more non-compressed storage and hacks for XIP (eXecute In Place) or lots more RAM than you are planning on for XMM stuff. You'd also need to develop a new architecture for linux, and while it's not very difficult to port, without GCC and a stable architecture already in place you are starting from a lot further down stream.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

heater
05-23-2009, 06:16 PM
Linux is probably too much but what about Contiki and its IP stack
www.sics.se/contiki (http://www.sics.se/contiki)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater
05-23-2009, 06:22 PM
RossH: "I don't know of anyone that has a disk drive connected to a Prop"

Yes you do, what about all the projects here using SD cards? How do you think CP/M gets along.

Anyway Linux will run quite happily without swap space on a disk drive. For sure implementing virtual memory in PASM will result in the slowest ever Linux machine:)

There is always Minix.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH
05-23-2009, 06:31 PM
heater,

You're right - trouble is that on the Hydra I can't have both the XMM and SD expansion cards plugged in at the same time. Which means my "swapfile" speed is limited to how fast I can insert and remove the cards. My arms are getting tired :)

Maybe when I get that TriBladeProp that Cluso keeps promising ...

Ross.

P.S. Contiki looks like it could be a goer. Unfortunately, some of us still have to work for a living!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

heater
05-23-2009, 07:02 PM
RossH: "Unfortunately, some of us still have to work for a living!"

But fortunately often people want to pay us to do what we like best, hack on software and hardware and play with gadgets. Which just by happy coincidence is actually of use to someone somewhere.

For example: Having been "resting" for some time and hence having the free time to mess with the Propeller and other goodies I find that in my new position there may well be a space for the Prop in the big picture. A previous "resting" period had me working night and day building up my own embedded system with this new off the wall Linux OS. I've been paid to work on Linux full time ever since. Amazing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH
05-23-2009, 07:11 PM
heater,

Good fortune to you.

If I spend too much more of my time on the Prop, I may be in for a period of "resting" myself :)

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Infinity
06-02-2009, 12:28 AM
Hello RossH

I am here because I want to ask you if there are any plans to Port this Compiler to Mac OSX, like Brads Spin IDE which is available for 3 Platforms Win32,Linux and OSX

Best regards,
Infinity

RossH
06-02-2009, 04:04 AM
Hi Infinity,

The only reason I do not offer Mac support is that I have no access to a Mac.

Since the Catalina sources are available, it should simply be a matter of compiling them. All you need to get started is have access to an existing C compiler on the Mac (such as gcc, which is available). Once you can compile lcc on the Mac, from then on lcc (and hence Catalina) can compile itself. As you say, both bstc and Homespun can run on a Mac, so there is really nothing preventing Mac support.

I'd be happy for someone to take this on, and let me know of any changes required. I don't think there should be any (except maybe to build scripts), but if there are I'll incorporate them into the common Catalina source.

Ross.

P.S. An alternative approach is to use a Windows emulation layer on the Mac - but I know how most Mac addicts would react to that suggestion!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

hinv
06-02-2009, 04:38 AM
How about compiling Catalina with Catalina so we would then have a propeller version of Catalina?

RossH
06-02-2009, 06:39 AM
@hinv,

I'm working on it. The problem is that I don't currently have a platform that provides anywhere near enough RAM or file storage space - at least not at the same time.

I only have a Hydra to work with, so I can currently have EITHER access to XMM RAM OR access to an SD Card for storage. I can't have both at the same time. I have a full implementation of the C file and stream processing library functions that can access files on the SD Card, but I can't test it because when I run it from XMM I can't see the SD Card - and I just can't get the #@$#@# to fit into 32K so that I don't need to use XMM!

Until I can get around this, Catalina will not be able to compile Catalina. To be more precise - since Catalina is a cross-compiler - it is actually lcc that can compile Catalina. So we actually need to use Catalina to compile lcc for the Prop, then run lcc on the Prop to compile Catalina on the Prop - but there is no point in even trying this yet since to run lcc on the Prop it needs access to a file system - hence the work on the file system.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Infinity
06-02-2009, 09:50 PM
Compiling it under OSX brings 2 warnings...


catalina.c: In function ‘main’:
catalina.c:1269: warning: incompatible implicit declaration of built-in function ‘exit’
catalina.c:1323: warning: incompatible implicit declaration of built-in function ‘exit’

i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I have only one question for what is the ICC in the source tree and how could I build catalina with all libs or is catalina.c just everything?

Is catalina only a front of the ICC?

Oh and after trying to build lcc:

cc -g -o /usr/local/lib/catalina/source/lcc/build/ops /usr/local/lib/catalina/source/lcc/build/ops.o
cp /usr/local/lib/catalina/source/lcc/build/rcc.exe /usr/local/lib/catalina
cp: /usr/local/lib/catalina/source/lcc/build/rcc.exe: No such file or directory


rcc.exe??? Linux? build_lcc.linux...

Is there a description how to build everything and also use it?

Oh and I still haven't got a propeller but look forward to get one so I can't test the compiled code...

best regards,
Infinity

Post Edited (Infinity) : 6/2/2009 9:17:23 PM GMT

HollyMinkowski
06-03-2009, 04:55 AM
This is great! http://forums.parallax.com/images/smilies/smile.gif
Soon as I have my propeller hardware I will be trying this C compiler out.
I'm used to the free gcc compiler for the Atmel chips.

Maybe I won't have to bother with spin.
Maybe I can someday help with writing a bit of code for this compiler http://forums.parallax.com/images/smilies/smile.gif

RossH
06-03-2009, 06:47 AM
@Infinity,

You can probably ignore the warnings on compiling catalina.c What compiler are you using?

But the program catalina.c is only the binder (I probably should change the name of this program - it seems to confuse lots of people!). The actual compiler is implemented as a code generator buried way down in the lcc source tree - most of it is in the file 'catalina.md' in the lcc/src directory.

When you build the entire lcc source tree (there is a makefile in there that you may need to modify), you will end up with the three executable files - cpp.exe lcc.exe and rcc.exe (or just plain cpp, lcc and rcc under linux). Here is what all the components do:
lcc.exe is a "wrapper" program that accepts arguments and then invokes the various phases of compilation - i.e. cpp.exe, rcc.exe, catalina.exe. You will probably need to modify this if your environment works differently (different pathnames etc).
cpp.exe is the C preprocessor - a fairly standard part of any C compiler.
rcc.exe is the actual C compiler, which in turn invokes the Catalina code generator.
catalina.exe is the binder - Catalina does not use a linker, but a binder does much the same job - e.g. resolves references to library functions. It then invokes homespun to do the final assembly.

Once lcc is build you then use it to build the library.

I'm sorry it's so complex - I'll try and get around to generating some build documentation for the next release, but in the meantime you should look at the documentation for lcc itself - see www.cs.princeton.edu/software/lcc/ (http://www.cs.princeton.edu/software/lcc/)

Tthe easiest thing maybe to compile it under windows or linux first (if you have access to a suitable machine) so you can see how it all fitst together before attempting to port it.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-03-2009, 06:53 AM
@HollyMinkowski,

I'd suggest at least playing with SPIN - it's a language specifically designed to take advantage of the capabilities of the Propeller. But then by all means use C if you're more familiar with it.

Let me know that Propeller platform you end up buying, and I'll make sure that there are some preconfigured targets for you to use with Catalina (you'll see what I mean when you download the Catalina documenation at the top of this thread).

Ross.

P.S. Your offer of help greatly appreciated. There's always seems to be more to do than I have time available to do it in.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Dale Stewart
06-03-2009, 08:29 AM
Hi Ross (also sent as PM)

Well done on the C compiler. Great for people on low incomes like myself.

For fun I am looking at exploring how to explore and develop a compiler/s and/or interpreter for various targets.

For micros C is my language (ASM if desperate).

I have a general science background (Degree), and an engineering-based Associate Degree in computer systems technology, including x8086; RISC, CISC micros, ;ASM, C++ and C programming and architecture; interfacing, electronics. The associate degree was completed for interest after being medically retired.

Unfortunately due to health issues I have not been able to follow through in my university studies started last year in computer engineering and computer science. I no longer work due to these health issues.

Obviously a lifetime of experience that you have would also be helpful.

Have many books on architecture, micros, computer science/engineering - need more specific stuff relating to development of compilers for target platforms.

Any books and other resources ( e.g. websites of university courses) that you can please steer me toward?

Anything is appreciated.

Cheers

Dale

RossH
06-03-2009, 10:07 AM
Dale,

Gosh you've got me there - before I started on Catalina it was so long since I did any compiler work that I can't even remember what books I used to have on my bookshelf. I remember a book called "Compiler Construction" but can't remember anything else about it. But while looking it up I came across this web site en.wikibooks.org/wiki/Compiler_Construction (http://en.wikibooks.org/wiki/Compiler_Construction) which looks quite useful.

The main thing I remember is that you can read all about language grammars, and it is all very interesting (ll0, ll1, lr0 etc etc - for examples of each see smlweb.cpsc.ucalgary.ca/example-grammars/ (http://smlweb.cpsc.ucalgary.ca/example-grammars/)) - but you probably won't really LEARN it until you get down to actually building a parser for one, and find out how complex it can be. And of course most "real world" languages don't fit neatly into any of these categories anyway. Language designers just love putting in features that seem designed solely to frustrate the life of compiler builders.

I'd suggest starting with something really simple. Use tools like lex and yacc (or bison - whatever you are familiar with) to build a simple expression parser - it can be surprisingly satisfying to define your own grammer, even if that grammer does nothing more than allow you to evaluate simple expressions such as "(4 * (6 - 3))" and print out the correct answer. But even such a simple grammer can be complex once you add error reporting and recovery - you can often get something working in 10 minutes that can then take you a week to get to the state that it recovers gracefully from the most trivial of typos, and correctly tells the user where and how they went wrong - especially when you have to look ahead several symbols from where the error is to try and guess what it was they may actually have been trying to say.

If you are particularly interested in C, then lcc is obviously a good place to start (see www.cs.princeton.edu/software/lcc/ (http://www.cs.princeton.edu/software/lcc/)). You could perhaps look at the lcc book. I've not read it, but I've just ordered copy - I'll report what I think when it arrives. Since all my work on lcc has been on the back end (i.e. the code generator), I have not actually needed the book, which I'm sure concentrates mostly on the front end (i.e. the language parser) - till now.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

heater
06-03-2009, 11:37 AM
Dale: Not sure what level you are pitching your question at but as a compiler ignoramus myself I was totally enchanted with this famous series of articles: compilers.iecc.com/crenshaw/ (http://compilers.iecc.com/crenshaw/)

Over the years I've tried to read various tomes on compiler construction and parsers etc. I always find them totally impenetrable. For example the famous "Dragon" books: "Compilers: Principles, Techniques, and Tools" by Aho and co.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Infinity
06-03-2009, 02:25 PM
Hi Ross,

The Problem is I build it for LINUX and it trys to move a rcc.EXE why I run the build_lcc.linux and why does it try to move a rcc.exe because there is none....
Hope you understand my Problem because I have no Idea...


Best regards,
Infinity

RossH
06-03-2009, 02:44 PM
@Infinity,

On linux the executable files don't have the .exe extension - i.e. they are not called 'rcc.exe', 'lcc.exe' etc, they are just called 'rcc' and 'lcc'

If the make file is trying to move rcc.exe then it is possible the makefile has a problem. I did have this issue once before but thought I had fixed it. If you look in the custom.mk file in the source\lcc subdirectory you should see something like:




install:
cp $Brcc$E /usr/local/lib/catalina
cp $Blcc$E /usr/local/lib/catalina
cp $Bcpp$E /usr/local/lib/catalina




If instead you see something like:




install:
cp $Brcc.exe /usr/local/lib/catalina
cp $Blcc.exe /usr/local/lib/catalina
cp $Bcpp.exe /usr/local/lib/catalina




then that's the problem - fix this file and try again. If you still have problems then PM me and I'll send you my email address to send me a listing of the actual build ouptut.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Infinity
06-03-2009, 03:34 PM
Thanks now there is no extension and the lcc is compiled on Mac OSX, but there are problems with the lib so you get a PM.

,Infinity

grahamreitz
06-03-2009, 07:10 PM
@HollyMinkowski

I've been using the Imagecraft ICC C compiler for a little over a month or and it works quite nicely.

The upside is that ICC uses the LMM model (no extra hardware, memory, necessary) and it's quite mature relative to Catalina. Rich at ImageCraft has been ultra helpful. I had one minor issue, which was remedied almost immediately. Had this been most other compiler companies it could have been weeks or months before I had a fix.

The downside it that it's not free, $99 for the non-commercial version. It's slightly pricey, in my opinion, but not outrageous either by any means. I bet $50-75 for the NC version and $150-$175 for the commercial version would be the sweet spot.

I would like to give the Catalina C compiler a try, but I lack a board with the extra hardware, and Ross has not indicated whether or not he will provide it under a license that doesn't require releasing your product's source code. I suspect the reason is that the stdlibs are compiled and statically linked. Compiling code itself with GPL compilers like GCC doesn't require you to release your source.

Good luck and enjoy the Propeller it is a real treat to work with!

graham

RossH
06-03-2009, 08:26 PM
@greitz

I'm not sure what you're talking about. Perhaps you should re-read the Catalina documentation.

Catalina doesn't need any extra hardware to run C programs - it also uses an LMM memory model. Catalina will run "as is" on a Hydra, or on a Demo board. It will also run on an ABC board or an XYZ board. You just need to set a few constant values (i.e. the clock frequency and I/O pin numbers) - the same way you do with any other Propeller program. No doubt the same way you do with ImageCraft.

On other hand, Catalina can use external RAM if you happen to have a Hydra Xtreme board.

As for the licensing, it has nothing to do with the libraries, which are freely distributable and modifiable in both source and binary form. It is currently my choice to offer Catalina under the GPL. I have previously indicated that when it is ready for a non-beta release, I will release the Kernel under the "lesser" or "modified" GPL so that you don't have to release your own source code just to use it. I will probably not do that with either the Code Generator or the Binder, so that you cannot release your own compiler based on Catalina without also releasing the source code.

Ross.

P.S. It is quite true to describe Catalina as immature compared to ImageCraft. I have said this myself.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

grahamreitz
06-03-2009, 11:01 PM
@RossH,


RossH said...
Catalina doesn't need any extra hardware to run C programs - it also uses an LMM memory model. Catalina will run "as is" on a Hydra, or on a Demo board. It will also run on an ABC board or an XYZ board. You just need to set a few constant values (i.e. the clock frequency and I/O pin numbers) - the same way you do with any other Propeller program. No doubt the same way you do with ImageCraft.


Sorry about that, I was completely mistaken or misinformed. I am certain I gathered a little ignorance due to reading many Catalina/Hydra posts, and inferred a dependency.


RossH said...
Since others will no doubt bring it up again, I should mention the licensing. Parts of Catalina (including the Kernel and the Binder) are currently issued under the GNU Public Licence (GPL). This doesn't mean you can't use them in commercial products and charge money for products that use them, but it does mean that if you use them you must (a) acknowledge their origin and (b) make your source code available. I have already said that when I'm ready to take Catalina out of beta status I may revisit this (at least for the Kernel, so you don't have to release your products source code), but that is how things stand at present. Partly, this is my choice to avoid undercutting the good work that ImageCraft have done.


This was not a definitive answer. It sounded like you were thinking about it and had not decided. There might be a newer post (after 5/20/09) that I missed where you clarified your intentions, thanks for making that clear now.

Kindly,
graham

RossH
06-07-2009, 11:09 AM
@All,

The fourth beta release of Catalina is now available. See the first few entries in this thread for sources and binaries.

With this release, Catalina is now substantially complete http://forums.parallax.com/images/smilies/hop.gif

This is therefore expected to be the final 'beta' release. Unless a major problem emerges with this release, the next one will be the first 'offical' release. Between now and then I will be concentrating on adding support for various different hardware configurations - including various platforms with XMM hardware and SD Card slots.

New features in beta 4 include: A tutorial document has been added which describes in detail how to use most of the major features of Catalina.

The ANSI C library is now complete (and can now be built under Win32). Newly implemented C library functions include:

- Functions related to non-local goto - setjmp and longjmp.
- Functions related to signals - signal, raise, abort etc.
- Functions related to time - clock, time, asctime, mktime etc.

A new Real-Time Clock (RTC) plugin has been added. This is used to support the ANSI-compliant time functions. Some additonal non-ANSI functions are also provided - e.g. to allow the time to be set programatically.

A new EMM program mode has been added to support Propellers with 64k (or larger) external EEPROMS. This mode allows larger LMM C programs to be created, since EMM programs can use the entire 32k of Hub RAM for application C code. Previously, this space had to be shared between the C code and the the target/plugin code.

Configuration for different Propeller platforms has been made much simpler. All platform-dependent options (e.g. clock frequency, I/O PIN definitions etc) are now combined in a single SPIN file.

The Hydra Asset Manager (HAM) is no longer required to build XMM programs. Now the Catalina Binder combines the XMM target file with the program file to produce a single "ready to execute" output file.

Catalina now supports many new output formats in addition to the standard eeprom and binary files - e.g. Motorola S-records or Intel Hex records.

A new version of Homespun (0.26) is included, which fixes a problem generating large binary files, and also allows the listing output file to be renamed with the '-o' option (many thanks as usual to Michael Park!).

Some bugs have been fixed:

- A bug converting constant numbers to addresses has been fixed.
- A bug defining static symbols with file scope has been fixed.
- A bug in line termination handling has been fixed.
- A bug in ungetc not being called correctly has been fixed.
- A bug resolving symbols in functions with file scope has been fixed.

For more details, see the Catalina documents.


To clear up any confusion, this beta release is still licensed under the Gnu General Public License (GPL). However, in the forthcoming 'offical' releases, the Catalnia Kernel will be released under the GNU Lesser General Public License (LGPL) so that programs compiled with Catalina can be used in commercial products without requiring the release of program source code.

Again, to clear up some apparent confusion, Catalina now supports three different compilation modes: LMM mode, which can generate C programs that are completely self-contained within 32k. The space available for C application code is the normal Propeller 32k RAM minus any space required for the target initialization code and the various plugins - but the program should be able to execute on any Propeller platform without any additional external hardware.

EMM mode, which can support larger C programs than is possible with just LMM. The space available for C application code can be the entire Propeller 32k RAM since the C program does not need to share this space with the target initialization or plugin code. However, this mode requires a Propeller with an external EEPROM of 64k (or larger).

XMM mode, which can be used to build C programs of arbitrary size (depending primarily on the capabilities of the XMM hardware). However, this mode requires additional compatible XMM hardware. In this release, the only XMM hardware supported is the Hydra Xtreme - this allows C application code to be up to 512K, but (due to the limitations of the Xtreme) programs larger than 64K may be substantially slower to execute than programs of 64K or less.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Post Edited (RossH) : 6/7/2009 7:09:04 AM GMT

Bill Henning
06-07-2009, 11:35 AM
Excellent work Ross...

After UPEW I'll see about getting it running... my assembler is written in C, and with XMM, I think it will be able to run natively under Largos under an XLMM kernel if compiled with Catalina.

Do you have any idea how large the Catalina executable would be as XLMM code? I need to know how much ram I'll have to attach to my propellers http://forums.parallax.com/images/smilies/smile.gif http://forums.parallax.com/images/smilies/smile.gif http://forums.parallax.com/images/smilies/smile.gif

Best Regards,

Bill

p.s.

I benchmarked the Largos prototype messaging system... almost 2300 empty messages served per second by a prototype Spin kernel and messaging object!

I expect a roughly 50x speed increase once the pasm LMM messaging and kernel are in.


RossH said...
@All,

The fourth beta release of Catalina is now available. See the first few entries in this thread for sources and binaries.

With this release, Catalina is now substantially complete http://forums.parallax.com/images/smilies/hop.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Largos (http://mikronauts.com/products/largos/) - a feature full nano operating system for the Propeller
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

RossH
06-07-2009, 11:56 AM
Hi Bill,

No - no idea yet. I have been so constrained by the limitations of the Hydra Xtreme as an XMM solution that (after my initial burst of enthusiasm) I have had to put aside any further XMM-related work over the past few weeks. I also decided that I should spend a bit more time on tidying up the Catalina 'basics' - so that others could use it more easily. After all, most people will never have any XMM hardware attached to their Prop at all!

However, now that that's done, I hope to get back to it. Today I'm going to see if I can finally get my CPLD programming cable assembled (I've had the parts for nearly a week now, but while I can write software in the odd few moments of free time I get here and there, I get completely flummoxed tryng to do the same thing with hardware!).

Ross.

P.S. Good work on Largos - I'll have to give it a try.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

jazzed
06-07-2009, 12:13 PM
Congrats Ross. Maybe you'll get a chance for some rest now. It's nice to see you implement the EMM feature. We discussed a similar feature at length in another thread for Spin/PASM. I read your docs, and it is very difficult to tell conceptually how the cog memory usage is implemented. Guess I'll have to read your code. The simplest way to use COG space from eeprom is for drivers like fullduplex serial, float math, etc..., and there was a lengthy discussion of this before. Another way is store pasm library code in COG space and use it on demand, but that would not likely be efficient. Yet another way would be to use COG space as just storage for LMM code. Too late for me to dig this mystery :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Post Edited (jazzed) : 6/7/2009 5:38:32 AM GMT

RossH
06-07-2009, 01:15 PM
Hi Jazzed,

It's not very sophisticated - the cogs are primarily used for device drivers, but are also used to implement library functions. The new RTC plugin is a fairly simple example of a device driver that interacts with the built-in Propeller 'clock' hardware - but the various Floating Point plugins are a good example of using one or more cogs as a library extensions.

The basic HMI drivers (screen, keyboard, mouse etc) are just the normal Parallax drivers and typically take a cog each - but the HMI 'plugin' also takes a cog - and it is more like an extension of the stdio library specifically devoted to stdin/stdout/stderr - it not only manages interaction with the basic drivers, it also adds functionality of its own, such as interpreting control characters and performing screen scrolling etc.

I've also 'reserved' for future use a plugin type that I intend to use to provide an alternative means of implementing low level 'block' oriented functions (like block moves and string comparisons) that are much quicker to do in PASM than in C. At the moment these are all done (in C) in library functions - this makes the resulting C programs much bigger and slower than they really need to be.

Eventually, you will have a choice of how many cogs you want to devote to 'library' plugins, in the same way you can currently choose how many cogs you devote to floating point. If you don't need the cogs for anything else, you can elect to put the library functions in them and get smaller programs and faster execution. If you need the cogs for other purposes, you emulate the same functions in C and live with slower execution and bigger programs.

I don't use any cogs for simple storage. Generally I think cogs are too valuable for that - and I never seem to have enough! But I may end up using one cog as an LMM 'instruction cache' for some types of XMM hardware.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

jazzed
06-07-2009, 01:46 PM
I suppose there is a way to omit hmi drivers? Some platforms won't use hmi "device" drivers at all on the execution cog since almost all pins are used for memory interface. In that case, one could use multiple cogs to speed up memory access among other things.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
06-07-2009, 02:03 PM
Hi Jazzed,

Yes, there's an example 'no_hmi' target provided that doesn't load any HMI drivers (or the HMI plugin). I use it for the 'test_LEDs' demo program:



lcc test_leds.c -lc -o test_leds -Wl-tno_hmi


The whole point about the various targets is that you can customize them to load only the plugins you want to use. The rest of the cogs are then yours to use for whatever you want.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-07-2009, 02:38 PM
@all,

Almost forgot - Infinity reported that he has successfully compiled Catalina using gcc under OSX on a Mac. A few minor problems he found with the Makefiles on that platform have been incorporated into this release. If you have a Mac, you should start with the linux sources and follow the linux instructions.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-08-2009, 09:46 AM
@all,

Further to my response above (to jazzed), I have just added a 'cog usage' addendum to the first post in this thread. As you will see from that document, Catalina can use anywhere from 1 to 7 cogs, depending to the target you choose.

The 8th cog is not quite so easy to use because it is required to execute the SPIN code that performs the target initialization - but like any other cog not allocated to a specific use by the target, this cog is available for general use once the kernel begins executing - these cogs can be started either in PASM (using the COGINIT instruction) or in C (using the _coginit() function).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-08-2009, 09:20 PM
@All,

Sorry - just found a few typos in the new tutorial document - some of the commands near the end of the doc were incorrect (e.g. the ones to compile hello_World.c as an EMM or XMM program).

I've updated the file catalina_documents.zip file. Please download that file again.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-11-2009, 07:11 AM
@all,

Just a progress update. I have successfully used epmoyer's modified formware for the HX512 to give Catalina access to the full 512K RAM on that card. For details of this firmware see this thread (http://forums.parallax.com/showthread.php?p=656146). The only modifications to Catalina are a couple of lines of Kernel code - and the resulting kernel is still backward compatible with the original HX512.

However, unless anyone has an urgent need for it, I will not bother to release a new version of Catalina at this point. The new capability doesn't really mean much on the Hydra because Catalina can currently only load programs from EEPROM anyway (with the Hydra the HX512 and the SD Card slot cannot be used at the same time). This effectively means programs are still limited to 96K code space, so the only benefit for Hydra users this point would be to go from 64K code sizes to 96K. And most people can't use the new capability in any case because it requires the use of a special programming cable to reprogram the HX512 - which hardly seems worth bothering with for a measly 32K!.

However, I'm expecting a Hybrid board to show up shortly (thanks Coley!) and on that board it will make a significant difference - with that board Catalina can use the HX512 at the same time as the SD Card, and will be able to load programs that will make use of the full 512K.

I'm also expecting a TriBladeProp (thanks Cluso99!) and various other cards, so I plan to support them all at the same time in the next release.

Ross.

P.S. If anyone does want to try out the experimental kernel with a modified HX512, send me a PM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-14-2009, 07:50 AM
@All,

There is now a new section in the first post of this thread called "Problems Discovered Post Release". I will keep that up to date with any minor issues discovered by me or reported by others. Of course if any "showstopper" issues are found I'll issue a new release ASAP.

Most recently, I had a report about Catalina not running correctly under 64 bit windows becasue of pathname differences - the best solution to this at present is to modify the hardcoded paths in both source\lcc\etc\catalina_win32.c and source\catalina\Catalina.c and recompile both LCC and the Catalina Binder (note that you need to use the short filename equivalent of wherever you installed Catalina). Next release I'll try and make Catalina correctly use an environment variable (Windows ... sigh!).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-14-2009, 09:25 PM
@All,

I have added a new document describing the Catalina LMM and XMM Kernels to the top of this thread, in the file catalina_kernel_doc.zip. This document will be combined with the other documentation in the next release.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Bill Henning
06-15-2009, 05:14 AM
Ross,

Sorry, I did release Las - but I took the time to finish practically all of the special LMM support first http://forums.parallax.com/images/smilies/smile.gif

Enjoy!

Bill


RossH said...
@All,

I have added a new document describing the Catalina LMM and XMM Kernels to the top of this thread, in the file catalina_kernel_doc.zip. This document will be combined with the other documentation in the next release.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las (http://mikronauts.com/products/las-largos-lmm-assembler/) - Large model assembler for the Propeller (alpha version released)
Largos (http://mikronauts.com/products/largos/) - a feature full nano operating system for the Propeller
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

jazzed
06-15-2009, 07:23 AM
Hi Ross.
I've looked at adding support for my SRAM module to Catalina today. It appears that xmm_progend.s is the "kernel" module that contains source for Hydra512K access. I'm thinking that creating a temporary copy of the file is fine for testing my hardware, but will require a "release" strategy that you can support. Have you given thought to infrastructure supporting third-party modules?
Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
06-15-2009, 08:11 AM
Hi jazzed,

Yes, that is the code that gets loaded by the XMM Loader. This was a bit of a quick and dirty hack, I'm afraid - to support multiple XMMs it makes more sense to have each XMM target contain the necessary XMM kernel.

For the moment, just modify that file to suit your board. In the next release, you will use the same kernel code but wrap it in a spin object and include it in a particular target. All I really need to do is use a different method to calculate the eeprom address where the XMM loader expects to find the kernel. In hindsight, I should have done it this way in the first place.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

jazzed
06-15-2009, 11:25 AM
Hi Ross.

Please check me on the steps below. Just for now, I'm trying to test what should work using othello xmm.
Here's what I think I need to do to run othello XMM (I've already verified that I can run othello LMM).

1: Change Catalina_Common.spin for platform
2: build_othello_xmm
3: run Catalina_XMM_Eeprom_Loader xmm_lores.spin (or hires)

Anything else ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Post Edited (jazzed) : 6/15/2009 5:03:17 AM GMT

RossH
06-15-2009, 12:24 PM
hi jazzed,

I assume from your previous post that you have now modified the xmm_progend.s file to include your XMM access routines. Here is what you should do next:

1. Yes, you should modify the Catalina_Common.spin file. You should then run the 'build_targets' batch file (or script) in the target subdirectory.

2. There is no longer a build_othello_xmm batch file (or script) in the current release, but if you still have this from a previous release it should still work. I presume if you are building it this way then you are trying to build just the C program image "standalone" - i.e. without any target code included. Is this correct? If so, what you end up with after this step is a binary intended to be loaded into EEPROM at address $8000. If instead you just want to build the whole thing in one executable (which you can just load into EEPROM starting at address $0000) use the following command instead:

lcc othello.c -lc -Wl-x2 -o othello_xmm -Wl-w-e


3. Assuming you do intend to build the compiled C program and the target separately, the next step is to run the target (not the loader - you don't normally run the loader directly, since at the conclusion of loading it automatically starts the kernel - and before you do that you also need to have set up the registry and various plugins). In the case of othello, you'll need at least a screen and a keyboard plugin, so the default xmm target (xmm_default.spin) is an appropriate one. Examine this file to see what it does - it is only a few lines of actual code, which does the following:
- initializes the registry
- starts the HMI plugin, which loads screen, mouse and keyboard (you can disable the mouse if you don't need it)
- starts the Float_A plugin, since the XMM kernel has no floating point built in (but I don't think you need it for othello).
- starts the XMM EEPROM Loader (this will start the kernel automatically)
- stops its own cog


Ross.

P.S. I just noticed that one of the windows binary files at the top of this thread is incorrect - I seem to have accidentally included the linux_binary_2 file instead of the windows_binary_2 file - this is not really essential - it would just stop srecord from working. I'll fix it when I get home.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-15-2009, 12:29 PM
@jazzed,

I noticed you edited your previous message while I was typing my reply - if you still have xmm_lores and xmm_hires you still seem to be using the previous release. I renamed the xmm targets in the current release to be xmm_tv and xmm_default (to be more consistent with the LMM target names). I think the rest of my comments still apply though.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

jazzed
06-15-2009, 12:37 PM
It's late. I'm tired. Perhaps you can make a list of steps for me to follow for the new release. I'm pretty sure i downloaded the new release but just copied over the old files. It is important to me to make this work since Catalina is one route to executing XMM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
06-15-2009, 12:46 PM
hi jazzed,

I know how you feel http://forums.parallax.com/images/smilies/smile.gif

Can you do me a favor and execute the command

catalina -v

This returns the number of the release (e.g. 1.3 is beta 3 and 1.4 is beta 4). Then I can figure out the appropriate commands for you to use.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

dMajo
06-15-2009, 03:17 PM
@RossH,

In your second post of this thread you have included second part of linux binary instead of windows one

RossH
06-15-2009, 03:30 PM
@dMajo,

Thanks - now fixed. The catalina_win32_binary_2.zip file contains only the various 'srecord' utility executables, which are not necessary unless you want to produce output formats other than the normal binary or eeprom formats (e.g. motorola s-records).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-15-2009, 04:04 PM
@jazzed,

Further to my last post (I'm at home now and can actually try it, rather than just working from memory) ...

The commands used to build xmm programs are the same under both beta 3 and beta 4 - but the results differ. E.g. the command to build othello as an xmm program is:

lcc othello.c -lc -Wl-x2 -o othello_xmm -Wl-w-e

This command was in 'build_othello_xmm' in beta 3, and is now in 'build_demos' in beta 4

Under beta 3, this would build a 64kb eeprom file containing only the C program code - i.e. it would not include the target code. You had to combine this 64kb image manually with a 32kb target image (such as xmm_hires.eeprom) using HAM.

Under beta 4, the same command now does this for you, and builds a 96kb file which contains both the C program and the target code (in this case since we did not specify any particular target it will use the 'xmm_default' target).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-15-2009, 07:13 PM
@all,

Daivd (Praxis) has created an installer program for the Catalina beta 4 binaries. This is simpler than downloading the multiple binary files at the top of this thread (but you may still need to download the source and demos).

The installer is too large to post directly in these forums but David is currently hosting it here (http://219.95.182.114/Catalina_distrib.zip).

Thanks, David.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

jazzed
06-15-2009, 10:17 PM
So the loader is 64K? Is that necessary? That + 32K minimum app code puts most hardware out of business.
Good thing I have an eeprom DIP socket on one of my boards.

What I want to see eventually is a loader or O/S that can launch an xmm binary from uSD card.

An intermediate step is to have a loader that can download/start a hex image from serial or uSD.
This intermediate step is useful so that *any* Propeller regardless of eeprom size with XMM hardware can be used.

Is there any way to make the loader fit in Propeller hub ram or 32K eeprom?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
06-16-2009, 04:44 AM
jazzed said...
Is there any way to make the loader fit in Propeller hub ram or 32K eeprom?


Yes - just use LMM mode. To summarize:

- If you need your program AND your target (i.e. your plugins and drivers) to fit completely within 32k you compile it as an LMM program (the default).

- If your program needs have the whole 32k to itself (and you have a 64k+ EEPROM) then you compile it as an EMM program.

- If your program needs more than 32k then you compile it as an XMM program.

LMM programs are simple - everything is compiled together into 32k just like any other Propeller program.

For EMM and XMM the loader+target is (max) 32k. These are compiled into a 32k image even if they only take 1k. The application program is then compiled into a separate image. For EMM this is always 32k. For XMM this defaults to 64k but can be smaller or larger. Then the two images are simply concatenated.

The reason for this is that the EMM and XMM loaders need to know where to find the application program (i.e. at $8000) in the EEPROM. If you limited yourself to smaller loaders (you may theoretically need up to 2k*8 = 16k of PASM + some SPIN "glue" - say 24k max) - you could start the application code at $6000 and fit another 8k of program code in the EEPROM. This didn't seem worthwhile to me when I already had XMM - it would just complicate thinge further (!). But it is a trivial mod to make if you want to do it.

I also would like to be able to load from SD card. Previously I didn't have suitable hardware. I do now, so that's on my list - along with file system support from C.

I agree loading over serial would be a nice intermediate step - it would be fairly easy to do - but I couldn't see any practical application for it.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Post Edited (RossH) : 6/15/2009 11:49:45 PM GMT

jazzed
06-16-2009, 07:21 AM
We all see things differently I guess.

A "loader" loads another program to run. In this case, an XMM program (the "loadee"?) is the thing to be loaded by the "loader" and could be of any reasonable size. The "loader" should be under 32K. What and where is the "loader" source? What's the best way to build just a "loader" and what size would it be?

Why do I not get to see the sources being used on an emm/xmm build like in an lmm build?
I'm not used to an opaque build process.




C:\Program Files\Catalina\demos>lcc hello_world.c -lc -o hello_world_xmm -Wl-x2 -Wl-w-e
Homespun Spin Compiler 0.26
parsing C:\progra~1\catalina\target\catalina.spin
compiling catalina.spin
writing hello_world_xmm_tmp.eeprom
combining target and program to hello_world_xmm.eeprom

C:\Program Files\Catalina\demos>lcc hello_world.c -lc -o hello_world_emm -Wl-x1 -Wl-w-e
Homespun Spin Compiler 0.26
parsing C:\progra~1\catalina\target\catalina.spin
compiling catalina.spin
writing hello_world_emm_tmp.eeprom
combining target and program to hello_world_emm.eeprom

C:\Program Files\Catalina\demos>lcc hello_world.c -lc -o hello_world
Homespun Spin Compiler 0.26
parsing C:\progra~1\catalina\target\lmm_default.spin
parsing C:\progra~1\catalina\target\Catalina.spin
parsing C:\progra~1\catalina\target\Catalina_Common.spin
parsing C:\progra~1\catalina\target\Catalina_LMM.spin
parsing C:\progra~1\catalina\target\Catalina_HMI_Plugin_Hi Res_Vga.spin
parsing C:\progra~1\catalina\target\Catalina_comboKeyboard .spin
parsing C:\progra~1\catalina\target\Catalina_mouse_iso_010 .spin
parsing C:\progra~1\catalina\target\Catalina_VGA_HiRes_Tex t.spin
compiling lmm_default.spin
compiling Catalina.spin
compiling Catalina_LMM.spin
compiling Catalina_HMI_Plugin_HiRes_Vga.spin
compiling Catalina_Common.spin
compiling Catalina_comboKeyboard.spin
compiling Catalina_mouse_iso_010.spin
compiling Catalina_VGA_HiRes_Text.spin
writing hello_world.binary

C:\Program Files\Catalina\demos>




Here is the version info.



C:\Program Files\Catalina\demos>catalina -v
verbose mode
catalina: Catalina Binder (version 1.4)


A practical application of serial load is mainly ease of use. Not all my eeproms are big enough for your images which should be vividly pretty obvious by now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Post Edited (jazzed) : 6/16/2009 12:28:26 AM GMT

RossH
06-16-2009, 09:03 AM
Hi jazzed,

Yes, we don't appear to be communicating very well, do we http://forums.parallax.com/images/smilies/confused.gif I agree that it seems to be a terminology problem. Let me start again ...

The loader you seem to be looking for is a general purpose utility that can load a compiled Catalina program from somewhere off-chip (e.g. from a serial port, an SD card or an EEPROM) into a location from which it can be executed (either HUB RAM or XMM RAM) - and then set it executing. Is that correct? If so, I'm afraid there is simply no such beast - at least not yet.

As I mentioned in an earlier post, I hope to have an SD Card loader soon. That will probably be a little more like what you want. However, if you want to develop a serial loader in the meantime, you can just take one of the existing loaders (start with the XMM EEPROM loader) and modify it for your own use. If you like, I'd be more than happy to include the result in the Catalina source tree.

By the way, the Hydra Asset Manager has a loader that does something along the lines of what you want - i.e. you first load the loader (using another loader http://forums.parallax.com/images/smilies/smile.gif of course) and it then accepts a program sent serially. It then programs the Hydra EEPROMs with the result, whereas you presumably want to load XMM with the result - but that's the trouble with such loaders: i.e. you typically need a different one for each platform you want to load to.

I don't presently need such a general purpose loader. Instead, I have a separate target for each possible platform (to take into account the device and pin differences) and also a separate 'low level' loader - and there will be one of those for each possible combination of source (i.e. EEPROM, SD Card, Serial) and destination (i.e. HUB RAM or XMM RAM).

Using Catalina terminology, there are three main components required to get a program executing: The 'target' - this sets up all the device drivers and other plugins (e.g. real-time clock, floating point co-processor) that comprise the environment that the application code needs to execute.
The 'loader' - this loads the application code into the correct place (or places) for execution - and then loads and starts the kernel.
The 'program' or 'application code' - this is the compiled version of your C program.So the type of loader I am talking about is probably a much lower level beast than the type of loader you are looking for.

Typically, for LMM programs the target, loader and program are all compiled into one executable file. In practice, LMM programs don't need much a loader, since they are executed 'in place' in hub RAM - so the only job of the loader is to load and start the kernel.

But for EMM and XMM the target and loader are compiled together into one file (which is saved as a 32kb EERPROM image) which then sits around in the target directory until you have some application code that needs to use it - which is compiled into another file. This is why the EMM and XMM compile process appears to be 'opaque' - it isn't, but it may seem to be because it only compiles the C application code each time, whereas the LMM compile process compiles everything each time. If you want to see the rest of the EMM and XMM compile process, go to the target directory and enter 'build_targets' - but you don't usually need to do this unless you specifically want to change something in a target or in the Catalina_Common.spin file.

So ... getting back to the loader(s) ... at least in the Catalina meaning of the term ...

The EMM Loader is in the target directory. It is called Catalina_EMM_EEPROM_Loader.spin. As the name implies, it can only load from EEPROM, and it always loads into hub RAM. It always loads from address $8000 in the EEPROM.

The XMM Loader is also in the target directory. It is called Catalina_XMM_EEPROM_Loader.spin. Again, it can only load from EEPROM (and again, from address $8000) - but it loads into XMM RAM - and it currently only supports the Hydra Xtreme.

Hope this helps,

Ross.

EDIT: forgot to say - you should discard all the files from previous releases - e.g. the previous 'xmm_hires.spin' doesn't use the new 'Catalina_Common.spin' file.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Post Edited (RossH) : 6/16/2009 2:08:47 AM GMT

jazzed
06-16-2009, 09:45 AM
It is clear there is no "loader" beast. I fully expect to write code I need. If I knew the parts available, I could put it together myself. I've seen Catalina_XMM_EEPROM_Loader.spin and tried to use it ... for some reason it stays stuck reading from eeprom and it's not obvious why that happens.

Is the loader that you have really 32KB or is that just a 0 padded eeprom file?
Your intel-hex files contain many unnecessary 0 data lines ... how can they be removed?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

RossH
06-16-2009, 10:46 AM
Hi jazzed,


jazzed said...
I've seen Catalina_XMM_EEPROM_Loader.spin and tried to use it ... for some reason it stays stuck reading from eeprom and it's not obvious why that happens.


It sounds like you're using all the right parts. This could be a problem with my I2C implementation. There was no PASM driver for I2C when I started so I wrote my own - but of course it's only been tested on the Hydra. However, I think I saw somewhere that there is now a pure PASM I2C driver, so you could try that.


jazzed said...
Is the loader that you have really 32KB or is that just a 0 padded eeprom file?


Yes, it's zero padded, and that 32k also includes all the drivers and plugins. The actual loader is pure PASM, so it is less than 2k.


jazzed said...
Your intel-hex files contain many unnecessary 0 data lines ... how can they be removed?


Generate a binary ouptut instead of an eeprom - even if you subsequently generate intel-hex format, this causes the zero records to be left off the end. But there will still be some zero records in the middle - to eliminate those you would have to use the appropriate srecord options.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Cluso99
06-16-2009, 11:03 AM
PropDos can load a standard binary from SD. So all we need for now is that binary to be a "loader" to load a Catalina binary.

I will be writing minimal code to boot a binary from SD. I need to fit this "boot code" into a MC9S08 which will boot the RamBlade when no secondary prop terminal is available. I am hoping that I may be able to fit it into under 4KB.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427))
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

RossH
06-16-2009, 11:26 AM
@Cluso,

Yes, I'm working on a loader that can load from a given file on SD.

Never enough time!

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-20-2009, 01:51 PM
@all,

Ive finally managed to resolve an annoying problem with the Catalina code generator ... it is mentioned in the beta 4 release notes as follows:


Catalina.pdf said...
Complex expressions involving functions that return structures can cause the Catalina Code generator to fail (in such cases lcc will return an assertion failure). This is quite rare, and the workaround is to locate and simplify the offending expression - i.e. evaluate the expression in several steps instead of as one large expression

Turns out to be a simple fix, but finding it has caused me to lose a lot of time on XMM support, so I don't plan to issue a new release just yet. However, if you want to recompile Catalina from source, the fix is a one line change to the function "clobber" (in source/lcc/src/catalina.md):




static void clobber(Node p) {
assert(p);
switch (p->op) {
case CALL+F:
spill(INTTMP | INTRET, IREG, p);
spill(FLTTMP, FREG, p);
break;
case CALL+I: case CALL+P: case CALL+U:
spill(INTTMP, IREG, p);
spill(FLTTMP | FLTRET, FREG, p);
break;
case CALL+V:
spill(INTTMP, IREG, p); // don't clobber our own target <=== THIS LINE CHANGED
spill(FLTTMP | FLTRET, FREG, p);
break;
}
}




@Dale Stewart,

I promised (earlier in this thread) to report when my copy of the lcc book "A retargetable C compiler: Design and Implementation" arrived. Well it finally did - and while it did help me track down the abovementioned bug, I couldn't otherwise recommend it. It's almost unreadable. The big giveaway is on page 11 - despite the title, the authors acknowledge that there was no actual design phase for lcc. The book certainly shows evidence of this lack - it doesn't seem to follow any natural or logical order, or have any overall structure that I can discern. For example, by page 6 we're discussing abstract syntax notation trees, but basic language parsing is not covered in the main body of the book till page 100. Language declarations are not covered until page 250. The subject of the very first chapter (apart from the introduction) is ... wait for it ...memory allocation! The book is dated 1995, but it obviously has its roots deep in the 1970's when such things were "hot" research topics. While the content is undoubtedly still perfectly valid, starting the book this way just makes it seem very dated. And after starting out so badly, it fails to really improve much - it is very definitely a "bottom up" description of lcc. Perhaps the whole book is really intended to be read backwards.



Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

heater
06-20-2009, 02:04 PM
RossH: "Perhaps the whole book is really intended to be read backwards."

What, you mean this book is really about Forth?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro
06-20-2009, 04:24 PM
Hi RossH,

I have probably a little strange question: How many assmbler instructions of the propellers instruction set does your compiler use? Does it need all? Would it be possible to reduce the instruction set to use a processor with the most important 16 instructions of the propeller?

Thanks,
chris

Sapieha
06-20-2009, 04:32 PM
Hi Chris Micro.

In my opinion it is very bad idea.
For me it is same to buy " RoysRoys " and reconstruct is to " Fiat " for at I will have " Fiat "

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it∑as simple as∑possible yet as versatile as posible.


Sapieha

heater
06-20-2009, 06:29 PM
Chris Micro: I see where you are going with this.

First thing to do is to download Catalina and have a look in the lmm kernel module. All the instructions in there have to be working before any compiled C code will run.

Then perhaps Ross will tell you how many different PASM instructions can be generated by the compiler. Or again you can check the compilers code generator and count them yourself.

Anyway what you want seems unlikely to me.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH
06-20-2009, 08:04 PM
Hi Chris,

The code generator only currently generates about 30 different instructions - have a look in the file "source/lcc/src/catalina.md". But as heater says, the kernel will use a bunch more - have a look in the file "target/Catalina_LMM.spin"

However, I wouldn't guarantee that it will stay that way - I intend to go back and do more optimization over time, of both the Kernel and the Code Generator - so the instructions required may change.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Chris Micro
06-20-2009, 08:07 PM
>Chris Micro: I see where you are going with this.

Hey, you are one step ahead of Sapieha. http://forums.parallax.com/images/smilies/smilewinkgrin.gif
I was thinking of simply making statistics of the code. But I thought it's easier to ask the expert directly. I simply want to spare work by not have to implement all instructions. http://forums.parallax.com/images/smilies/tongue.gif

Chris Micro
06-20-2009, 08:11 PM
>The code generator only currently generates about 30 different instructions - have a look in the file "source/lcc/src/catalina.md". But >as heater says, the kernel will use a bunch more - have a look in the file "target/Catalina_LMM.spin"

Hi RossH,

Thank you for the answer. I will take a look at the *.md files.

chris

Sapieha
06-20-2009, 08:59 PM
Hi Chris Micro.

You said " I was thinking of simply making statistics of the code ".
That statisticas of code used by C and ASM on Intel's 8080-8085 CPU give os bad posiblites in Intel 8088-8086 code.
Them optimized out instructions from 8080 ASM set that have ben used not frequently.
And it result in optimising out all CALL on flags instructions !!

Regards
Christoffer

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it∑as simple as∑possible yet as versatile as posible.


Sapieha

heater
06-20-2009, 09:12 PM
Sapieha: That's interesting. I seem to remember reading many years ago, when the 6809 was new, that Motorola had done a lot of statistical analysis of existing code in order to decide what instructions the new chip should have.

Result, the 6809 ended up with no conditional CALLS as well !!

I always wondered if they just grabbed a load of listings and counted the occurrence of each instruction or if they actually ran the code to see what really got used most.

Makes one appreciate the Propeller way of handling conditional execution.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater
06-20-2009, 09:38 PM
Chris Micro: As far as I understand you have created an emulation of some of the Prop instructions in C that runs on an AVR.

I must strongly encourage you to continue and expand your effort to emulation of all the instructions. After all there is only 64 opcodes, I'm busy working through 256+ for the 6809 emulator.

Be sure to take care of instruction timing and self-modifying code.

The result could be a nice fast Cog emulator that could be run on Windows or Linux or where ever and the Propeller community would love you forever.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro
06-21-2009, 12:27 AM
>I must strongly encourage you to continue and expand your effort to emulation of all the instructions
Thank you for that. I'm not sure yet, because for me it was only a try how difficult it would be to write an emulator.
With the structure of the existing code I have now it is easy to extend it. But it seems a lot of work ... Hmm, probably I will do it ...

> The result could be a nice fast Cog emulator that could be run on Windows or Linux or where ever and the Propeller community >would love you forever

Yes, you got the bigger goal. It would be very easy to transform the code to any platform ...

teraquendya
06-28-2009, 03:45 AM
Hey, great job on the compiler.

I was just having some questions about the different cogs. do i run _coginit(par, addr, cog) with par as the function name? and addr just as a random empty int?

RossH
06-28-2009, 05:21 AM
Hi teraquendya,

No, the _coginit is a low level function to start a PASM program - it doesn't work like the SPIN function (which can start another SPIN function in a new cog).

Have a look at pages 284/285 of the Propeller manual (version 1.1) - the parameters to the coginit C function (i.e. par, addr, cogid) map to the destination register of the coginit assembly language instruction in a fairly straightforward manner, as follows:

par = bits 31:18 (i.e. the parameter to pass to the cog after startup)
addr = bits 4:17 (i.e. the long address of the code to load into the cog)
cogid = bits 3:0 new flag + cogid (i.e. the id of the cog to start, plus the new flag)

The C function does the shifting and combining required to put these parameters in the right places, but you must supply addr as a LONG address (dividing the actual address by 4). It points to 512 longs that represent the code. The par parameter can be any value (up to 14 bits) but is most often the address of a data block that contains configuration data for the cog - in which case it must also be divided by 4 (the reason I don't do the division by 4 automatically is that the par parameter may just be a value, not an address)

The fact that the cogid parameter also incorporates the new flag means a cogid of 8 will result in any free cog being used.

Here is a (non-working!) example of how I expected it would be used ...




#include <catalina_cog.h>

#define COG 7

void main() {

long code[512] = {0x12345678, 0x12345678, 0};
long data[32] = {1, 2, 3, 4};

int result;

result = _coginit ((int)data>>2, (int)code>>2, COG);
}



However, while writing this post I just reviewed the code to check on the parameter mapping and noticed that the par parameter is not being passed correctly. I will issue a fix and generate a working example of how to use it later today.

Ross.

Edit: minor correction to code

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Post Edited (RossH) : 6/27/2009 11:42:11 PM GMT

matb
06-28-2009, 07:37 AM
The RTC is pretty heavyweight to use a dedicated COG. Could you integrate the approach I posted in this thread (http://forums.parallax.com/showthread.php?p=819130)?

Post Edited (matb) : 6/28/2009 12:48:31 AM GMT

RossH
06-28-2009, 08:08 AM
Hi matb,

Yes, I agree my RTC implementation is pretty much a waste of a cog - I'll have a look at your code and see if I can find a way to use it instead.

I didn't worry too much about it because the Prop crystal is not really accurate enough to be an RTC anyway - my plugin is mainly intended as an example.

If you need accurate time, you would be better off adding an external RTC chip. There are several RTC chips with I2C interfaces that are very simple to integrate with - what I really should do for the next release of Catalina is include a general purpose I2C plugin that is accessible from C.


Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
06-28-2009, 09:15 AM
@all,

I've included a fixed 'coginit' function, and a demo program showing how to use it, in the file 'catalina_coginit_fix.zip' attached to the first post in this thread.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Mike Green
06-28-2009, 10:54 AM
Anyone have any luck in compiling Catalina's LCC for the MacOS?

RossH
06-28-2009, 11:06 AM
Hi Mike,

Infinity successfully compiled beta 3 under OSX using gcc. I incorporated a couple of minor changes into the beta 4 makefiles as a result of his experience, so I believe it should now compile "out of the box" - but I don't have a Mac so I can't guarantee this.

You will also need to install mono in order to run homespun (same as for Linux).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

teraquendya
06-28-2009, 11:56 AM
Thanks a lot for the fast answer

So do i see it right that i need to convert the code to hex first before it can be run on a new cog?

and is data going to be globally accessible for other cogs to communicate with one another?

matb
06-28-2009, 12:08 PM
Is there a way of passing (command line) #defines values to Homespun? Or putting in a list of paths to search with -T?

I am not a fan of editing Catalina_Common.spin for different boards to define the pinouts. I figure a #define in any spin plug-ins would be really useful mechanism that would solve it.

An alternative would be to pick up Catalina_Common.spin (or similar) in a local directory, instead of from the common library directory, using a include path type mechanism. I quickly tried that, but I suspect the -T Catalina argument does not support it.

The spin mechanism of 'importing' constants is pretty frustrating. One of the reasons for me to try C instead.

m@

RossH
06-28-2009, 12:54 PM
@teraquendya,

I'm thinking of implementing an 'asm' function, but it's not part of the ANSI standard. So yes, you have to currently specify PASM instructions in hex. The easiest way at the moment to get the required hex is to use Homespun to compile the PASM, and use the Homespun -d option to produce a list file - then cut and paste the bytes from that file. Be careful about byte ordering - homespun prints each long as 4 bytes, so it may be easier to represent the data in Catalina as an array of bytes - or if you want to represent it as longs you need to reverse the order of the bytes in each long.

But there is another, even easier way - each target has a file called something like 'catalina_target.s' where you can simply insert PASM instructions or data. For example, the default target has one called ' catalina_default.s' - add your PASM program to this, making sure your main symbol is prefixed by "C_" and is all lower case and has no other underscores - e.g. "C_mycode". Then you can refer in your C program to the symbol as simply "mycode". The binder will initially complain that this symbol is undefined, so you need to use the '-f' option to the binder (or the '-Wl-f' option to lcc) to force the binder to continue even if it has undefined symbols (it finds it later in the binding process).

Making data globally accessible between cogs is up to you - if all your coginit functions use a common data pointer (i.e. one declared as a static in C), then yes - all cogs will see the same data. I use this trick a lot - ff you also need to pass individual data to each cog as well as shared data, then have each cog retrieve its own id and use this as an index into an array of cog-specific data.

@matb,

I don't think homespun accepts #defines on the command line. But using the -T switch to the binder (or -Wl-T to lcc) to specify an alternate target directory works for me.

For example, I'm currently working on a set of targets for the Hybrid. So I created a copy of the target directory, called it 'hybrid', and I now compile for the Hybrid by saying something like:


lcc hello_world.c -Wl-TC:\Progra~1\Catalina\hybrid


Of course it's easier if you use a batch file or a makefile. Note the need for using the short version for all path and file names.

Ross.

Edit: PASM for the default target should be included in the file called "catalina_default.s", not "lmm_default.s"

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Post Edited (RossH) : 6/28/2009 6:37:27 AM GMT

RossH
07-05-2009, 02:48 PM
@All,

Beta 5 of Catalina is available.

See the first post in this thread for a list of updates. The major ones are the addition of a new support package for the Hybrid board, and the additon of an SD card-based file system - this requires a Propeller board that has XMM and can access the SD card at the same time (which is possible on the Hybrid, but not - alas - on the Hydra!).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

teraquendya
07-05-2009, 03:32 PM
Alright,

so are you going to be implementing an easier way to use multiple cogs anytime soon, or should i look at the code and play with it myself?

RossH
07-05-2009, 04:11 PM
@teraquendya,

I have a small backlog of things to complete first (mostly related to supporting other XMM platforms), but top of my list after that is to extend Catalina to support multiprocessing. That's the main reason I wrote it in the first place.

But if you want to add your own extensions in the meantime, feel free - I don't claim any great expertise in this area - just an abiding interest.

And I'd really like others to contribute to Catalina.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
07-06-2009, 11:39 AM
@all,

Apologies - there is a typo in one of the Hybrid target files.

I have posted the required fix in the first post of this thread.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
07-08-2009, 10:51 AM
@All,

I've temporarily removed the Catalina source code and binaries because I've discovered a significant problem in the XMM Kernel.

I'm testing a fix now, and expect to have a new version up later today.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
07-08-2009, 07:13 PM
@All,

A new version of beta 5 has now been uploaded. The problem I found only affected some programs compiled to run from XMM RAM and the fix turned out to be fairly minor, so I'm not creating a whole new release.

The compiler, binder and libraries are unaffected, so if you have already downloaded the previous beta 5 release you don't need to download either the documentation or source distributions again - just get the binary distributions.

I also noticed that the information in the demo README files was out of date, so you should also download the demo programs again.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
07-17-2009, 12:12 PM
@all,

Someone just pointed out to me that it is not sufficient to simply download the 'source' distributions to use Catalina. The source distributions contains only the source code to the compiler, libraries and utilities - they do not contain the various target packages that you will need to actually run the compiler. Those are only contained in the 'binary' distributions.

So even if you intend to build the compiler from scratch, you should still download both the binary and the source distributions.

I have added a note to the posts containing the various distribution files. Apologies for any confusion.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Painless
07-25-2009, 09:42 AM
Hi Ross,

Just wanted to let you know that I finally had a chance to check out your C compiler under Linux and I have to say I'm impressed! If this is a beta release, I can't wait to see what the future holds.

I did find the target system a bit of a stumbling block at first, but after a little reading of your reference manual I was able to figure out how to get the pin assignments where I need for the correct target. I've soldered up my PropRPM with demoboard pin standards and wanted to use TV output, I ended up modifying the hydra targets clock, tv and pin assignments to get things how I wanted.

I spend a lot of my propeller time where I only have a serial terminal for HMI purposes and would like to see a target designed to accommodate such, perhaps when I dig deeper I'll figure out a way of achieving this.

Congratulations and thanks for a great FREE product!

Russ.

RossH
07-25-2009, 02:27 PM
Hi Painless,

Glad you got it working, and thanks!

You may be interested in the set of targets I'm now preparing for Cluso99's TriBladeProp - it will include a couple of new HMI plugins that allow the use of the PC as the Catalina HMI - with all the usual mouse, keyboard and screen support functions (mouse support is only available if you use PropTerminal, but if you don't the mouse then any terminal emulator will do).

This should be available in a day or two (fingers crossed that I get enough time!).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Cluso99
07-25-2009, 03:51 PM
Great news Ross http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),∑SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

RossH
07-29-2009, 10:21 PM
@All,

Just a quick post to alert all TriBladeProp users that the Catalina Target Package for the TriBladeProp is now available.

The package is avilable in the first post in this thread. The Catalina_tribladeprop.zip file contains the new sources and binaries for both Linux and Windows. It includes a new version of the Catalina Binder program (sources and binaries).

Note that the target package is not a full release - it must be installed over the top of an existing Catalina beta 5 source/binary installation. If you don't have a TriBladeProp, it is probably not worth downloading this package just for the new Binder - I will include that in a general release soon.

Here's a very quick summary of the TriBladeProp support: All three blades can be used to run Catalina C programs. Targets are provided for all three blades: Blade #1 has all the normal HMI targets are available for using the screen, keyboard and mouse. Also, this blade has an optional 512Kb of XMM RAM available.
Blade #2 has an SD Card and an optional 1Mb of XMM RAM available. This blade can be used to load programs from the SD Card and either execute them on this blade (using a PC terminal emulator as the HMI) or download them for execution to another blade.
Blade #3 can be used to execute I/O control programs. It also can use a PC terminal emulator as the HMI. A new plugin to support using the PC as the HMI via a serial port is provided.
A new plugin to support serial communications between Propellers is provided.
For complete informatiom, see the README.TriBladeProp - I have enclosed a copy with this post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Post Edited (RossH) : 7/29/2009 10:51:18 PM GMT

Cluso99
07-29-2009, 10:31 PM
Fantastic news Ross http://forums.parallax.com/images/smilies/smile.gif I am finally headed for Gosford on the weekend and hopefully a few days to build another TriBlade and finish the other 2 designs too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),∑SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

RossH
07-30-2009, 06:34 AM
@Painless (and others)

The new TriBladeProp Target Package contains a plugin that is applicable to other platforms as well. The file Catalina_HMI_Plugin_PC.spin in the target_tribladeprop directory (you also need Catalina_PC_Keyboard.spin and Catalina_PC_Text.spin) use pins P30 and P31 of the Prop for serial comms, and maps them to the standard C stdin and stdout streams. This allows the use of a terminal emulator on the PC as the screen and keyboard from within Catalina C programs.

You will have to create your own targets that use this HMI plugin - for an example, see lmm_pc.spin

This plugin is based on drivers provided by Andy Schenk of Insonix (the creator of PropTerminal) - but will work just as well with any terminal emulator. A PropTerminal specific version (Catalina_HMI_Plugin_PropTerminal.spin) which will also support using the PC mouse is still under development, but is not working yet (I hadn't actually intended to include it in this release - please ignore it!).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
07-30-2009, 06:41 AM
@Cluso,

That's good news - hope we get the chance to catch up. What a shame that the current shortage of DIP40 Propeller chips is likely to curtail the sales of the TriBladeProp for a while - it really is a great board (although my wife doesn't think so since it has taken up so much of my spare time for the last couple of weeks - if you develop any more boards I'll have to get you to send them to me in a plain brown wrapper so she won't get suspicious!)

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Cluso99
07-30-2009, 07:33 AM
Ross http://forums.parallax.com/images/smilies/tongue.gif

Definately will have to∑catch up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),∑SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

teraquendya
07-31-2009, 06:20 AM
Hey,
loving it so far.

Right now i was wondering if it would be possible to interface C code compiled with Catalina and SPIN code? I assume it would be possible to compile to assembly and copy it over, but would this cause issues with the kernel?

RossH
07-31-2009, 07:19 AM
Hi teraquendya,

Thanks. I also would like to have SPIN programs coexist with Catalina. I have given it a little bit of thought, and I believe the simplest way is to allow the Hub RAM to be 'partitioned' between SPIN and Catalina.

Instead of Catalina assuming it can use all 32Mb of Hub RAM, once it starts it would have to know to only use Hub RAM from some partition boundary up to $7FFF for Catalina programs - but it would also know how to load and execute SPIN programs in the area from Hub RAM address $0000 up to the partition boundary. Catalina would then start one cog specifically as a SPIN interpreter (maybe even using Cluso's 'improved' SPIN interpreter) as well as one cog to execute the Catalina kernel. After that, both SPIN and Catalina would compete for the remaining cogs.

As long as both the Catalina programs and the SPIN programs behaved themselves and didn't cross the partition boundary, they should be able to coexist. To allow commmunication between SPIN and C, I would provide a 'shared memory' buffer (and provide both C and SPIN routines to access this buffer) - probably using the Propeller's 'lock' mechanism to ensure the buffer's integrity.

The complicated part is all the changes this would require to the Catalina startup process. The process for loading Catalina programs to XMM from EEPROM, SD Card, or via serial I/O from another Prop (this last one is new for the TriBladeProp!) is already very complex - and now all the various loaders would also have to know how to load and execute SPIN programs.

As usual, the main problem is time. At the moment I only get to work on Catalina in odd hours (unfortunately I still have to work for a living!) and there are also lots of other things I need to do first.

For example, I need to finish Catalina's XMM support. After working on Cluso's TriBladeProp (which has two different XMM implementations on the one board) I have put a bit of effort into developing a 'standard' Catalina API for accessing XMM, and I need to get this rolled out to the other Catalina platforms (Hydra, Hybrid etc). I've also promised Bill Hennning to put Catalina on his new Morpheus platform - although after the TriBladeProp I expect this to be relatively straightforward.

I am also working on finalizing the Kernel design I will need for what I expect to be Catalina's final XMM memory model - which I expect to support 16Mb of shared code/data/heap space (in XMM RAM) and up to 32Kb of stack space (in Hub RAM). It makes sense that while I am doing this I should implement the 'partition' concept to simplify future SPIN/Catalina coexistence.

It's hard to put a timeframe on all this, but I'd say it will be months rather than weeks - the more complex Catalina gets (and the more platforms I support) the longer it takes me to do any significant development work.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Post Edited (RossH) : 7/31/2009 12:37:19 AM GMT

RossH
07-31-2009, 09:20 AM
@teraquendya,

No sooner do I write the above than I find this (http://forums.parallax.com/showthread.php?p=738145) mentioned in another ongoing thread (credit: BradC). It seems SPIN is relocatable, so it may be a lot simpler than I thought just to execute a simple small SPIN program from C - just reserve a suitably sized block of Hub RAM space (use a static global array of longs in C unless you will also shut the SPIN program down again), load the spin program into it, then execute the appropriate coginint function.

Anyone want to try this?

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Painless
08-01-2009, 01:59 AM
RossH said...
@Painless (and others)

The new TriBladeProp Target Package contains a plugin that is applicable to other platforms as well. The file Catalina_HMI_Plugin_PC.spin in the target_tribladeprop directory (you also need Catalina_PC_Keyboard.spin and Catalina_PC_Text.spin) use pins P30 and P31 of the Prop for serial comms, and maps them to the standard C stdin and stdout streams. This allows the use of a terminal emulator on the PC as the screen and keyboard from within Catalina C programs.

You will have to create your own targets that use this HMI plugin - for an example, see lmm_pc.spin

This plugin is based on drivers provided by Andy Schenk of Insonix (the creator of PropTerminal) - but will work just as well with any terminal emulator. A PropTerminal specific version (Catalina_HMI_Plugin_PropTerminal.spin) which will also support using the PC mouse is still under development, but is not working yet (I hadn't actually intended to include it in this release - please ignore it!).

Ross.


Awesome, Ross! I'll give that a try!

Russ.

RossH
08-15-2009, 06:19 PM
@all

I have updated the TriBladeProp support package (available in the first post in this thread) to include a new PropTerminal compatible HMI plugin (and also a new target and a demo program that uses it). This plugin allows the use of the PC's screen, keyboard and mouse as the Catalina HMI. The new plugin is not TriBladeProp specific, and could also be used on other platforms, such as the Hydra or Hybrid.

The TriBladeProp update also fixes a problem with the EMM targets, and a problem that may have prevented a blade from rebooting properly after a program was loaded using the generic program loader.

The new demo program is called test_propterm.c. To compile this program to use the new PropTerminal target, use a command such as:

lcc test_propterm.c -lc -Wl-tpropterminal -o test_propterm

This will produce a binary called test_propterm.binary. The easiest way to load this binary into the TriBladeProp (it can run on any blade) is by using PropTerminal itself - i.e. start PropTerminal and then use the 'File->Upload File' menu option. Note that the PropTerminal window should be set to 40 chars by 13 lines - the propterminal plugin assumes this size for compatibility reasons (but this can be modified if required).

The demo program displays some startup information, then allows you to either type text or press a mouse button - text typed appears at the current cursor position. The cursor position is also displayed at the bottom of the screen whenever a character is typed. Mouse button 0 sets the cursor position to be the position pointed to by the mouse, and also displays the results of the m_bound functions at the bottom of the screen. Mouse button 1 does not change the cursor position, but displays the results of the m_abs functions (representing the absolute position of the ouse) at the bottom of the screen.

The following notes apply to the new PropTerminal plugin:

1. You must clear the keyboard - i.e. call k_clear() - at the start of your program to avoid getting a spurious first character.

2. There appears to be something slightly amiss with the way PropTerminal scales the mouse (at least on my machine - YMMV). I have to set the mouse scaling as xscale=8, yscale=17 for my mouse to work correctly - i.e. I call m_bound_scales(8, 17, 0). The symptoms of incorrect scaling are apparent when using the demo program - press and release the left mouse button to set the cursor position and then type a character. The character should appear where the mouse is pointing - if the character appears elsewhere the scaling is probably not set correctly.

3. PropTerminal does not implement button 2 (the middle button or scroll wheel) - only buttons 0 and 1 will work correctly.

4. When using the mouse, you are limited to screen sizes no larger than 64 cols by 32 rows - this limitation is due to the way PropTerminal sends mouse events. If you don't need a mouse, you can use larger screen sizes. To set a new screen size, you must modify the file Catalina_PC_Text.spin, and also edit the file propterm.ini (and load the updated ini file into PropTerminal).

5. PropTerminal only supports one cursor position. You should use either cursor 0 or cursor 1 - but not both. If you want to write to the screen at a different cursor position, save the cursor position first, set the new cursor position, write to the screen, then restore the original cursor position - the demo program illustrates how to do this.


Ross.

P.S. Sorry this new plugin has taken so long - I haven't had much time to work on Catalina recently. I'm still working on the next major release which will include the new XMM model - but I can't currently estimate when this release will be available.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Cluso99
08-15-2009, 06:30 PM
Nice work Ross http://forums.parallax.com/images/smilies/smile.gif
P.S. I am back on the coast but I don't know for how long.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

∑ Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),∑SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
∑ Single Board Computer:∑3 Propeller ICs∑and a∑TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
∑ Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
∑ Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
∑ Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ∑www.bluemagic.biz (http://www.bluemagic.biz)∑∑ MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

RossH
08-15-2009, 07:32 PM
Hi Cluso,

This weekend and next are both pretty much a writeoff for me - SWMBO has declared this weekend to be a 'gardening' weekend because of the weather (oh, my aching back!) and next weekend we have a couple of family events we have to go to.

Our catch up may have to wait till your next trip down this way.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
08-16-2009, 07:17 AM
@all,

One of the files in the catalina_trlblade.zip file necessary for PropTerminal mouse support was an old (broken) version. I have uploaded a new version of the package (available in the first post in this thread).

Please download the package again - sorry.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

RossH
09-29-2009, 04:53 PM
@All,

Catalina 2.0 (the first non-beta version) has now been released. I have started a new thread for the new series of releases here (http://forums.parallax.com/showthread.php?p=844004).


Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=844004)

Post Edited (RossH) : 9/29/2009 10:42:37 AM GMT