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.
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:
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.
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.
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 -
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.
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
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.
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[noparse][[/noparse] ], word[noparse][[/noparse] ] and long[noparse][[/noparse] ] 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.
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.
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.
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.
...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.
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
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.
(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 - a new blog about microcontrollers
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.
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:
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.
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:
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.
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:
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.
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.
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.
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.
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!
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!
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:
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.
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
(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 - a new blog about microcontrollers
Comments
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
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
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.
propeller.wikispaces.com/Programming+in+C+-+Catalina
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.
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.
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[noparse][[/noparse] ], word[noparse][[/noparse] ] and long[noparse][[/noparse] ] 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.
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://forums.parallax.com/showthread.php?p=788230
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
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world, those who understand binary and those who don't.·· -a poster I saw
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
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, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
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.
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, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
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.
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.
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.
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.
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!
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.
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, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
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.
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
(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)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers