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
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.
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 ....
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.
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.
@ 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.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
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.
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.
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.
@ 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"
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.
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 - a new blog about microcontrollers
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.
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
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 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.....
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
My gut instinct is that our biggest competitor is Spin. May be I should go up to Rocklin to rough Jeff up . 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.
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.
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.
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 [noparse]:)[/noparse]
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:
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.
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
...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.
Comments
--(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
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
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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.
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://forums.parallax.com/showthread.php?p=788230
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.
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.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 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.
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://forums.parallax.com/showthread.php?p=788230
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.
For Win98SE/XP rather than XP only, replace "DEL /Q %BUILD%\*" with "FOR %%F IN (%BUILD%\*.*) DO DEL %%F"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
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.
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
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.....
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
My gut instinct is that our biggest competitor is Spin. May be I should go up to Rocklin to rough Jeff up
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Ross.
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, 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
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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.