If code portability and manufacturer independence is your primary goal, you don't want the Propeller, period. Nobody else has anything remotely like it, and I really don't see that changing. If you write Propeller C code with portability in mind, you will end up ignoring most of the features that make the propeller unique and worthwhile.
I'm not saying the compiler won't be useful, just not for that reason.
Yeah, that makes a lot of sense, (unique architecture) = (unique language to leverage it)
Ok now i question, if not for portability (thanks bergamot) and not for speed (thanks Mike Green), and I know from years of experience, NOT FOR EASE OF USE (I love using C, but it is definitely not an easy lanuage).
The C compiler is a wedge designed to open doors for the Propeller that might otherwise remain shut by pointy-haired bosses who don't understand microcontrollers. Once the Propeller has achieved ingress to the walnut-paneled management suite, the compiler will have done its job and can slip quietly into the shadows, freeing the engineering staff to use Spin and Assembler.
This is a tongue-in-cheek portrayal, of course, and is not meant to disparage ImageCraft or Parallax's support of their efforts. I'm sure the resulting compiler will be of the utmost high quality, as befits ImageCraft's well-earned reputation. And let's face it: it may be a necessary tool for the Propeller's acceptance in the corporate world — even if the language itself is a poor match to the Propeller's architecture.
Disclaimer: Okay, I really am biased. I've never written a program in C, and I hope I never have to!
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 6/24/2007 5:42:12 AM GMT
A C compiler is quite useful. For example, ImageCraft targets its compiler for various microcontrollers. It will be a good fit for the "Large Memory Model" for the Propeller. If you haven't looked at the forum threads discussing this, it's a sort of threaded interpreter that copies native instructions from main memory into a loop in a cog, then executes them in-line using local (cog) memory for data. It uses subroutine calls to simulate jump type instructions since hub addresses are needed and these are at least 15 bits. Since these are simulated, a stack machine can be simulated which makes compilation much easier. There is relatively low overhead, typically with hub instructions executing every 4 native cog instructions. That's still 5MIPS and there are provisions for caching small native routines which execute at the full 20MIPS.
You're still limited to 8K long words of instructions and data which does limit the complexity of compiled programs.
Just for context ... I've written some large Spin and Prop assembly language programs, a lot of C and Pascal programs (including a Pascal compiler and OS) and used a number of programming languages "of historical interest only" today. I've also written assembly language programs for too many different instruction sets to count.
It might be interesting to write a C to Spin compiler. Spin has a functionally similar set of operators and statements. Some of the "extra" operators could be added either as extensions or as built-in functions. A lot of the standard library routines could be implemented, but not be a useful fit to the architecture.
Post Edited (Mike Green) : 6/24/2007 5:35:57 AM GMT
C has always seemed to me a convenient dodge for those who don't want to immerse themselves in the archtecture of whatever they're trying to program. It's rather like Esperanto in that regard: a vain attempt at universal communication without considering the culture of those you're trying to communicate with. But, as with culture in natural languages, architecture in computer languages has a way of rewarding the astute and tripping the unwary, so it needs to be taken into consideration. In my mind, the best way to do this is to learn the "local" languages — in this case Spin (as a glue language) and Assembler (for performance).
I'm familiar with the Large Model and the promises it brings to the table. And I'm wlling to wait and see how it plays out vis-a-vis the C compiler. But my personal preference would still be to write programs for the Large Model in Assembler, because then I'd know I'm squeezing the most performance from it.
When I was in school, I was exposed to a language called PL360. It was a high-level assembler for the IBM 360. Now, "high-level assembler" sounds like an oxymoron, but it really was a nice attempt to make assembly language more readable. Like C, it had high-level control structures, but in all other regards it was close to the metal, and you knew you were programming an IBM 360 and not a CDC 6500, say. I'd be much more inclined to use something like that, designed specifically for the Propeller, than a so-called universal language like C that needs to be shoe-horned to fit.
All this opining, of course, is specific to the microcontroller world, since resources there are so limited. I'm quite content to use interpreted scripting languages like Perl on my PC and don't care a whit what's happening there under the covers. But a PC's resources are so vast, compared to the things it's usually tasked with, that one really doesn't have to care.
Phil,
I'm very familiar with PL360. It's one of the "historical" programming languages I've used extensively. You could use something like that for the Propeller instruction set, but there'd be major problems notationally with the result flags and mixed conditions in a sequence of instructions.
All of these languages provide structure and the structure and its rules help avoid and catch bugs. My personal preference is an extended Pascal since it's a strongly typed language. I can't count the number of times that the typing rules kept me from writing something that not only wouldn't work, but would be difficult to find since the error involved pointers and would show up long after the code involved would execute.
C is actually a good low level language for most instruction sets as long as you don't try to implement the full standard. It's a concise notation and you can get the compiler to enforce type checking for you.
I can really see the C compiler as being a highly useful piece of software but I wonder if the fact that the speed is only a bit slower than assembly masks the fact that you may be loosing some of the true power of the propeller including the determinsm (I'm not too sure on that one) and the new multi processor mind set.
I know of at least one person that told me the propeller did not have enough memory for a certain project which might have been true with all the overheads of trying to get a large program to run on a single processor but I have seen much more complex projects than theirs done on the propeller and I know the development would have been far faster especially given the easy intergration of TV/VGA and keyboards/mice for the interface.
Mike Green said...
C is actually a good low level language for most instruction sets as long as you don't try to implement the full standard.
Hi Mike,
Could you give some indication of what parts of the C standard you think shouldn't be implemented and why? Are you referring to the standard library and stuff like file and I/O or the actual language?
Mike Green said...
It's a concise notation and you can get the compiler to enforce type checking for you.
Spin has a fairly concise notation as well, but as to type checking it's a bit of a disaster. Simple references within a single spin object are fine, but if you need to take an address (or tables of addresses) and share the between multiple objects to try and "glue" an application together, then the risk of memory corruption actually increases quite dramatically. If the variables of sub-objects where able to be directly referenced, then the type checking would be less of an issue.
Compile-time warning would also help with the development of code. For example: · jmp label
is valid, but most of the time I mean to write · jmp #label
It's amazing how long a little bug like that can take to track down.
CardboardGuru,
I'm mostly referring to the standard library which often doesn't apply to the Propeller. Clearly if you implement some kind of mass storage like an SD card or you have a keyboard or display driver, then you ought to provide an interface via the standard library routines. I would be reluctant to implement multidimensional arrays because of the limited memory of the Propeller, not just for the data itself, but the code to access it. I would probably leave out bitfields, mostly because of the cost of access. It's not that you can't do it reasonably, but it looks so simple when you write it in a program, that you lose sight of how much memory each instance takes to implement.
mirror,
I'm a strong proponent of type checking and I do miss the ability to have it in Spin. One of the disadvantages of not building on top of existing compiler construction tools and existing language concepts and design is that you may miss out on some really excellent experience in what has helped (or hindered) programmers and their programs over the 50-60 years that people have been doing this.
I think some of these discussions mix up : use in the "industry" and use in hobby and education.
In "industry" you have to apply more or less complex algorithms - say digital filters, mp3 encoding etc.
These algorithms are generally encapsulated within true C-Programms. You do not want to take the risk to translate them by hand to some new language!
In edudication students expect to be trained along the mainstream - they need to be know about interrupts and cache memory and C
So there is a very tight market niche for the Propeller WITHOUT C!
deSilva,
In "industry", usually the development cost of the software is amortized over many units and performance is a primary goal, whether the issue is speed or memory usage or both. In the education / hobby market, usually the cost of development (of the actual software) is unpaid and performance is often not much of an issue as long as the software works. We're in a period of expansion of hardware capabilities, where the cost of processor power and memory is falling, but will eventually stabilize for a while as it has in the past. Now, you can usually afford the inefficiency of compiled code, but there are always applications that "push the envelope". The risk is in not translating the complex algorithms to a more efficient language, whether that's Spin or assembly, or a special non-standard dialect of C. At the moment, the Propeller is near the "cusp" in terms of on-chip memory. It may be with the Prop 2 that the cost advantages will shift with the added instructions and extra memory. We won't know until the architecture is made public. For the moment, C is not as good a match to the hardware as a combination of Spin and native assembly. Consider the smaller, slower PIC processors. There are any number of compilers available for these, none of them very good in terms of speed or memory usage. That doesn't mean they're not usable. On the contrary. There are some applications that don't need to use the full capability of the chips, most of these in the education area. In the "industry" area, there are many applications where you either have to use assembly language for much of your program or use a larger, faster, more expensive chip for the processor.
CHIPKEN,
You really really do not want to try to implement C++ (or anything like it) on a small processor like the Propeller or most of the PICs or smaller Atmel processors. The overhead in providing the run-time object support is quite substantial, both the amount of code that has to be included and the processing time. There are implementations of standard C that will run on a 16-bit processor with 128K of memory (and some kind of mass storage device). These compilers tend to have multiple overlays, but they do work reasonably well. As long as you don't use floating point or large arrays, and use string manipulation judiciously, they're pretty good. To do C++ reasonably well, you need several MB of memory (realistically a minimum of 16 to 32MB) and a fast 32-bit processor with built-in floating point
The propeller uses UNSPECIFIC SILICON, waiting for the implementation of fancy algorithms by highly inspired programmers.
"Standard" processors use the accumulated knowledge of 50 years of software algorithms to put into some C-program (and be it 256 K bytes long)
Please ponder all the consequences!
A good approach might be to not consider a Propeller as an 8 processor unit, but a as a processor consisting of 8 micro programmable general function units!
A good approach might be to not consider a Propeller as an 8 processor unit, but a as a processor consisting of 8 micro programmable general function units!
This is exactly the reason I got excited about the Propeller. In addition, each of the eight units are dedicated to their task - which makes it possible to guarantee that a single critical unit wont starve for processor time.
If you want an easy 60Mips, a C compiler (GCC), several built in peripherals·and a relatively easy chip to stick on a board, then you could consider using one of the ARM chips. I did, and the code is working fine, but . .·. the Propeller is the first chip that I've gotten really excited about over the last couple of years.
Has anybody thought of doing a forth that uses the spin bytecodes as its own? I'd like to look at it, but am just a bit too busy for the next couple of months.
Mike Green said...
There are implementations of standard C that will run on a 16-bit processor with 128K of memory (and some kind of mass storage device).
Reality check 1: even on CP/M80, we had C compilers. That's 64kB minus operating system on an 8 bit CPU.
Reality check 2: e.g., on an AVR with 4kB Flash, you can do reasonably interesting things in C, using gcc, e.g. ledtoy.sourceforge.net
By the way, there's nothing in C that requires you to have a stack if you don't have recursion. Modern compilers
also do cross-function optimization, sometimes even across compilation units.
I haven't read much about Spin yet, but what I've seen doesn't make it look like a language that's superior to,
say, C. The byte code interpreter may be quite nice, though. There's nothing preventing a C compiler from
using a byte code interpreter as well. It could even switch code generation between byte code, LMM, and cog
code.
Whether this makes sense would have to be determined by comparing code density. Has anyone translated a
program from Spin to assembler or from assembler to Spin (with exactly the same functionality) ? How did the
code size change ?
Parallax will not be producing a C compiler for this Propeller or for the next one nor will they be documenting the Spin interpreter's byte codes. Saying it's nice or important won't make it so. They just don't have the resources for the former or the interest for the latter.
ImageCraft has stepped up to the plate with a commitment for a LMM C compiler which will probably produce some native instructions as well (for the cache setup in the LMM). Whether it will produce native code that's usable like Spin's assembly code is unknown. It certainly won't be able to produce code equivalent to hand optimized assembly with careful timing constraints worked in ... like that for video drivers, high speed serial drivers, etc. One can however, treat those cases like library routines (somewhat as they already are) produced "outside the box" as it were and written in assembly language.
There are currently no active projects that I know of for any other compilers for the Propeller. There is some mostly complete 3rd party documentation on the Spin byte codes, probably enough to get started on a compiler for it. There are a couple of assemblers that are partially complete and everything so far, apart from ImageCraft's effort, is hobby based with very limited resources. I'm not criticizing, just pointing out that there's a very small resource pool to draw on and not much of a market to encourage enterpreneurs. ImageCraft is able to get involved because of an existing, well developed tool chain that can be adapted.
Post Edited (Mike Green) : 6/26/2007 5:03:52 AM GMT
- Look for GEAR here in the forum, it's author has learnt a lot about SPIN byte code the hard way
- I have not yet compared program sizes, but the speed trade-off between Assembler and Spin is somewhat around 80, which - in fact - is intollarable. It improves much when using a lot of multiplications and divisions.
I tried some bytecode interpretation of my own and found that - indeed ! - it takes a lot of instructions whatever approach you use....
You can either say, the propeller is not made for virtual machines.
You can also say, the propeller is highly tuned for other kinds of machine coding
Mike, let's see what the future will bring. I find it quite encouraging already that there are several efforts at providing
some essential tools (two assemblers, two programmers, small cc, GEAR). There also seems to be rather strong interest
for Open Source in this community, along with an understanding of Open Source principles (a lack of which is fairly
common in the hardware industry, and the misunderstandings resulting from this can be rather frustrating), which is also
encouraging.
Since Parallax themselves seem to like that sort of openness, I wouldn't be surprised if they would at least informally
help any project that aims to compile to Spin bytecode. (I haven't looked at the bytecode "reverse documentation"
yet, but I would expect it to be only a partial fit for C. So a C compiler taking that route would probably have to bring
its own bytecode interpreter. Similarly, one can probably make better use of the LMM concept by generating an LMM
interpreter tailored for a specific program or even function, instead of using a one-size-fits-all version.)
Regarding ImageCraft, we'll have to wait and see what they produce. I don't know how suitable the internal structure
of their compiler(s) code base is for the Propeller, nor do I know how much effort they'll be willing to put into making
their Propeller compiler really good.
This is a bit late, but I disagree strongly with the statement:
Mike Green said...
Consider the smaller, slower PIC processors. There are any number of compilers available for these, none of them very good in terms of speed or memory usage. That doesn't mean they're not usable.
Many of the C compilers for the smaller 8 and 16 bit processors are extremely efficient, so much so that in the real world it is possible to get the same job done cheaper and "easier" with a single 16 bit 20MIPS core or even an 8bit 16MIPS
AVR core than the propeller running 8x 32 x 20MIPS cores.
It is the unfortunate position of the propeller that has a state of the art architecture that seems to be extremely hard to use to the full.
If the processor architecture fits C well ,and you know C (as most programmers do) then your code will fit the processor well, and will run efficiently.
The AVR, and PIC18 cores were designed to fit the C language, so most C programmers can write some really amazing code (ie an HTTP web server) on a really low power processor.
The propeller has a unique architecture that Mike and others have pointed out "does not fit C well" but other processors do not share the propeller's inefficiency in processing code translated from C, so much so that most "smaller" micro's can execute code written in c very close to the speed of assembly.
Ok guys this is turning from kicking the tire to kicking a dead horse. The truth is ImageCraft is creating a C compiler for the Propeller, so all of these editorials on benefits or lack thereof of C are moot. So lets just drop the debate and wait for the release of the compiler.
Paul Baker (Parallax) said...
Ok guys this is turning from kicking the tire to kicking a dead horse. The truth is ImageCraft is creating a C compiler for the Propeller, so all of these editorials on benefits or lack thereof of C are moot. So lets just drop the debate and wait for the release of the compiler.
What's so funny? Yea, we are later than we expected and later than we want, but the C compiler is chucking along. We are testing small programs and tuning the LMM and code generation. Status will be reported as warranted.
I for one can hardly wait for the ImageCraft compiler, keep up the great work Richard and rest assured that there are a number of people who will definitely be paying for what I'm sure will be another great tool.
If people are *that* frustrated waiting, perhaps you should try writing your own? I think that you will then perhaps understand what huge undertaking this is and appreciate the investment ImageCraft is making in the propeller architecture.
Simon - all things are relative. I - like many of you - once worked for a small company of true experts. We got assignments from some very important companies which keep lots of own research facilities. We developed in weeks (well, months sometimes ) what they could very well do themselves, though in MUCH more time for MUCH more money only.
Porting a C compiler made for this takes an experienced developer exactly 3 person months:
1 for the code generator
1 for the run time system
1 for testing and integration
When the developer is not so experienced and he or she is not acqainted with details of the compiler kit or of the target architecture this can easily double.
When the person does not do it full time there goes easily a year..
So I think everthing is still in best order..
Um,,... I see the assembler and linker spring from thin air, as for the code to support the low level routines (e.g. mul, div). Forget the downloader too, or any tuning of the IDE and library functions. May be they are all "runtime."
And of course the existing compiler internal architecture would just fit to a T with all the possible devices ...
Comments
I'm not saying the compiler won't be useful, just not for that reason.
Ok now i question, if not for portability (thanks bergamot) and not for speed (thanks Mike Green), and I know from years of experience, NOT FOR EASE OF USE (I love using C, but it is definitely not an easy lanuage).
What is the value of the C compiler????
This is a tongue-in-cheek portrayal, of course, and is not meant to disparage ImageCraft or Parallax's support of their efforts. I'm sure the resulting compiler will be of the utmost high quality, as befits ImageCraft's well-earned reputation. And let's face it: it may be a necessary tool for the Propeller's acceptance in the corporate world — even if the language itself is a poor match to the Propeller's architecture.
Disclaimer: Okay, I really am biased. I've never written a program in C, and I hope I never have to!
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 6/24/2007 5:42:12 AM GMT
You're still limited to 8K long words of instructions and data which does limit the complexity of compiled programs.
Just for context ... I've written some large Spin and Prop assembly language programs, a lot of C and Pascal programs (including a Pascal compiler and OS) and used a number of programming languages "of historical interest only" today. I've also written assembly language programs for too many different instruction sets to count.
It might be interesting to write a C to Spin compiler. Spin has a functionally similar set of operators and statements. Some of the "extra" operators could be added either as extensions or as built-in functions. A lot of the standard library routines could be implemented, but not be a useful fit to the architecture.
Post Edited (Mike Green) : 6/24/2007 5:35:57 AM GMT
C has always seemed to me a convenient dodge for those who don't want to immerse themselves in the archtecture of whatever they're trying to program. It's rather like Esperanto in that regard: a vain attempt at universal communication without considering the culture of those you're trying to communicate with. But, as with culture in natural languages, architecture in computer languages has a way of rewarding the astute and tripping the unwary, so it needs to be taken into consideration. In my mind, the best way to do this is to learn the "local" languages — in this case Spin (as a glue language) and Assembler (for performance).
I'm familiar with the Large Model and the promises it brings to the table. And I'm wlling to wait and see how it plays out vis-a-vis the C compiler. But my personal preference would still be to write programs for the Large Model in Assembler, because then I'd know I'm squeezing the most performance from it.
When I was in school, I was exposed to a language called PL360. It was a high-level assembler for the IBM 360. Now, "high-level assembler" sounds like an oxymoron, but it really was a nice attempt to make assembly language more readable. Like C, it had high-level control structures, but in all other regards it was close to the metal, and you knew you were programming an IBM 360 and not a CDC 6500, say. I'd be much more inclined to use something like that, designed specifically for the Propeller, than a so-called universal language like C that needs to be shoe-horned to fit.
All this opining, of course, is specific to the microcontroller world, since resources there are so limited. I'm quite content to use interpreted scripting languages like Perl on my PC and don't care a whit what's happening there under the covers. But a PC's resources are so vast, compared to the things it's usually tasked with, that one really doesn't have to care.
-Phil
I'm very familiar with PL360. It's one of the "historical" programming languages I've used extensively. You could use something like that for the Propeller instruction set, but there'd be major problems notationally with the result flags and mixed conditions in a sequence of instructions.
All of these languages provide structure and the structure and its rules help avoid and catch bugs. My personal preference is an extended Pascal since it's a strongly typed language. I can't count the number of times that the typing rules kept me from writing something that not only wouldn't work, but would be difficult to find since the error involved pointers and would show up long after the code involved would execute.
C is actually a good low level language for most instruction sets as long as you don't try to implement the full standard. It's a concise notation and you can get the compiler to enforce type checking for you.
I know of at least one person that told me the propeller did not have enough memory for a certain project which might have been true with all the overheads of trying to get a large program to run on a single processor but I have seen much more complex projects than theirs done on the propeller and I know the development would have been far faster especially given the easy intergration of TV/VGA and keyboards/mice for the interface.
Graham
Hi Mike,
Could you give some indication of what parts of the C standard you think shouldn't be implemented and why? Are you referring to the standard library and stuff like file and I/O or the actual language?
Compile-time warning would also help with the development of code. For example:
· jmp label
is valid, but most of the time I mean to write
· jmp #label
It's amazing how long a little bug like that can take to track down.
I'm mostly referring to the standard library which often doesn't apply to the Propeller. Clearly if you implement some kind of mass storage like an SD card or you have a keyboard or display driver, then you ought to provide an interface via the standard library routines. I would be reluctant to implement multidimensional arrays because of the limited memory of the Propeller, not just for the data itself, but the code to access it. I would probably leave out bitfields, mostly because of the cost of access. It's not that you can't do it reasonably, but it looks so simple when you write it in a program, that you lose sight of how much memory each instance takes to implement.
mirror,
I'm a strong proponent of type checking and I do miss the ability to have it in Spin. One of the disadvantages of not building on top of existing compiler construction tools and existing language concepts and design is that you may miss out on some really excellent experience in what has helped (or hindered) programmers and their programs over the 50-60 years that people have been doing this.
In "industry" you have to apply more or less complex algorithms - say digital filters, mp3 encoding etc.
These algorithms are generally encapsulated within true C-Programms. You do not want to take the risk to translate them by hand to some new language!
In edudication students expect to be trained along the mainstream - they need to be know about interrupts and cache memory and C
So there is a very tight market niche for the Propeller WITHOUT C!
Chuck
In "industry", usually the development cost of the software is amortized over many units and performance is a primary goal, whether the issue is speed or memory usage or both. In the education / hobby market, usually the cost of development (of the actual software) is unpaid and performance is often not much of an issue as long as the software works. We're in a period of expansion of hardware capabilities, where the cost of processor power and memory is falling, but will eventually stabilize for a while as it has in the past. Now, you can usually afford the inefficiency of compiled code, but there are always applications that "push the envelope". The risk is in not translating the complex algorithms to a more efficient language, whether that's Spin or assembly, or a special non-standard dialect of C. At the moment, the Propeller is near the "cusp" in terms of on-chip memory. It may be with the Prop 2 that the cost advantages will shift with the added instructions and extra memory. We won't know until the architecture is made public. For the moment, C is not as good a match to the hardware as a combination of Spin and native assembly. Consider the smaller, slower PIC processors. There are any number of compilers available for these, none of them very good in terms of speed or memory usage. That doesn't mean they're not usable. On the contrary. There are some applications that don't need to use the full capability of the chips, most of these in the education area. In the "industry" area, there are many applications where you either have to use assembly language for much of your program or use a larger, faster, more expensive chip for the processor.
CHIPKEN,
You really really do not want to try to implement C++ (or anything like it) on a small processor like the Propeller or most of the PICs or smaller Atmel processors. The overhead in providing the run-time object support is quite substantial, both the amount of code that has to be included and the processing time. There are implementations of standard C that will run on a 16-bit processor with 128K of memory (and some kind of mass storage device). These compilers tend to have multiple overlays, but they do work reasonably well. As long as you don't use floating point or large arrays, and use string manipulation judiciously, they're pretty good. To do C++ reasonably well, you need several MB of memory (realistically a minimum of 16 to 32MB) and a fast 32-bit processor with built-in floating point
The propeller uses UNSPECIFIC SILICON, waiting for the implementation of fancy algorithms by highly inspired programmers.
"Standard" processors use the accumulated knowledge of 50 years of software algorithms to put into some C-program (and be it 256 K bytes long)
Please ponder all the consequences!
A good approach might be to not consider a Propeller as an 8 processor unit, but a as a processor consisting of 8 micro programmable general function units!
If you want an easy 60Mips, a C compiler (GCC), several built in peripherals·and a relatively easy chip to stick on a board, then you could consider using one of the ARM chips. I did, and the code is working fine, but . .·. the Propeller is the first chip that I've gotten really excited about over the last couple of years.
Has anybody thought of doing a forth that uses the spin bytecodes as its own? I'd like to look at it, but am just a bit too busy for the next couple of months.
·
Reality check 1: even on CP/M80, we had C compilers. That's 64kB minus operating system on an 8 bit CPU.
Reality check 2: e.g., on an AVR with 4kB Flash, you can do reasonably interesting things in C, using gcc, e.g.
ledtoy.sourceforge.net
By the way, there's nothing in C that requires you to have a stack if you don't have recursion. Modern compilers
also do cross-function optimization, sometimes even across compilation units.
I haven't read much about Spin yet, but what I've seen doesn't make it look like a language that's superior to,
say, C. The byte code interpreter may be quite nice, though. There's nothing preventing a C compiler from
using a byte code interpreter as well. It could even switch code generation between byte code, LMM, and cog
code.
Whether this makes sense would have to be determined by comparing code density. Has anyone translated a
program from Spin to assembler or from assembler to Spin (with exactly the same functionality) ? How did the
code size change ?
- Werner
Parallax will not be producing a C compiler for this Propeller or for the next one nor will they be documenting the Spin interpreter's byte codes. Saying it's nice or important won't make it so. They just don't have the resources for the former or the interest for the latter.
ImageCraft has stepped up to the plate with a commitment for a LMM C compiler which will probably produce some native instructions as well (for the cache setup in the LMM). Whether it will produce native code that's usable like Spin's assembly code is unknown. It certainly won't be able to produce code equivalent to hand optimized assembly with careful timing constraints worked in ... like that for video drivers, high speed serial drivers, etc. One can however, treat those cases like library routines (somewhat as they already are) produced "outside the box" as it were and written in assembly language.
There are currently no active projects that I know of for any other compilers for the Propeller. There is some mostly complete 3rd party documentation on the Spin byte codes, probably enough to get started on a compiler for it. There are a couple of assemblers that are partially complete and everything so far, apart from ImageCraft's effort, is hobby based with very limited resources. I'm not criticizing, just pointing out that there's a very small resource pool to draw on and not much of a market to encourage enterpreneurs. ImageCraft is able to get involved because of an existing, well developed tool chain that can be adapted.
Post Edited (Mike Green) : 6/26/2007 5:03:52 AM GMT
- www.cliff.biffle.org/software/propeller/forth/index.php But the author seems to have interrrupted the project and there is no source code available
- Look for GEAR here in the forum, it's author has learnt a lot about SPIN byte code the hard way
- I have not yet compared program sizes, but the speed trade-off between Assembler and Spin is somewhat around 80, which - in fact - is intollarable. It improves much when using a lot of multiplications and divisions.
I tried some bytecode interpretation of my own and found that - indeed ! - it takes a lot of instructions whatever approach you use....
You can either say, the propeller is not made for virtual machines.
You can also say, the propeller is highly tuned for other kinds of machine coding
some essential tools (two assemblers, two programmers, small cc, GEAR). There also seems to be rather strong interest
for Open Source in this community, along with an understanding of Open Source principles (a lack of which is fairly
common in the hardware industry, and the misunderstandings resulting from this can be rather frustrating), which is also
encouraging.
Since Parallax themselves seem to like that sort of openness, I wouldn't be surprised if they would at least informally
help any project that aims to compile to Spin bytecode. (I haven't looked at the bytecode "reverse documentation"
yet, but I would expect it to be only a partial fit for C. So a C compiler taking that route would probably have to bring
its own bytecode interpreter. Similarly, one can probably make better use of the LMM concept by generating an LMM
interpreter tailored for a specific program or even function, instead of using a one-size-fits-all version.)
Regarding ImageCraft, we'll have to wait and see what they produce. I don't know how suitable the internal structure
of their compiler(s) code base is for the Propeller, nor do I know how much effort they'll be willing to put into making
their Propeller compiler really good.
- Werner
AVR core than the propeller running 8x 32 x 20MIPS cores.
It is the unfortunate position of the propeller that has a state of the art architecture that seems to be extremely hard to use to the full.
If the processor architecture fits C well ,and you know C (as most programmers do) then your code will fit the processor well, and will run efficiently.
The AVR, and PIC18 cores were designed to fit the C language, so most C programmers can write some really amazing code (ie an HTTP web server) on a really low power processor.
The propeller has a unique architecture that Mike and others have pointed out "does not fit C well" but other processors do not share the propeller's inefficiency in processing code translated from C, so much so that most "smaller" micro's can execute code written in c very close to the speed of assembly.
Thanks,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
// richard
If people are *that* frustrated waiting, perhaps you should try writing your own? I think that you will then perhaps understand what huge undertaking this is and appreciate the investment ImageCraft is making in the propeller architecture.
-Simon.
With a good C compiler, I will probably get back to propeller.
Best regrds
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
I am no compiler expert (far from it, in fact), but I can only imagine that creating a compiler is a HUGE task.
I'll definitely buy a copy when it comes out.
~ Christopher
1 for the code generator
1 for the run time system
1 for testing and integration
When the developer is not so experienced and he or she is not acqainted with details of the compiler kit or of the target architecture this can easily double.
When the person does not do it full time there goes easily a year..
So I think everthing is still in best order..
And of course the existing compiler internal architecture would just fit to a T with all the possible devices ...