I freely admit proper use of FCACHE is not trivial, but neither is writing any good compiler. If writing quality compilers was easy, GCC, LCC, etc would be lost in a sea of competitors.
Part of the reason that existing LMM compilers don't use it effectively is due to a lack of documentation with examples of how to properly use FCACHE. I will be releasing some more documentation on my site, possibly later tonite, that I wrote a couple of years ago for a proposed series of articles for Circuit Cellar. Unfortunately due to urgent consulting contracts, I did not finish the series in time and it never got published. I've been too busy since to try to submit it to another magazine, however as long as the pdf's are only available from my site, I still may be able to do so. As it is, I plan to do a series on LMM2 and submit those.
Why did I not publish them earlier? Since I freely published my LMM, I thought to use it to get more good consulting work by publishing my findings in a popular magazine.
I think that experienced compiler back end writers could do a good job on using FCACHE to optimize code if and only if:
The compiler writers don't try to dictate how the kernel should be written, instead listen to the kernel designer on how FCACHE should be used.
Why?
They simply have not spent more than three years working on it, and on getting to know the propeller inside out, sideways - and very very few will have anywhere near my level of interest in processor architecture.
Given ample time (somewhere between 1-2 years), good compiler writers experienced with multiple architectures (RISC, CISC and VLIW at a minimum) they could duplicate my research and findings (assuming similar CS backgrounds and similar unusual level of interest in past/present/future processor architectures) and then they could write a very good LMM kernel.
Heck, I would not dream of telling back end writers "this is how you must write the code that manipulates the intermediate code to produce the desired result" - I would say "here is the basic kernel, here are some general design principles of how to do FCACHE properly, now study that, and come back to me in a week with your ideas - BUT you are forbidden to take the easy way out and just make a zillion primitives, as that will severely limit your performance". That does NOT mean that they could not get a few helper functions that makes the work easier. It does mean using a large FCACHE properly.
Unless you are designing a new architecture from the ground up, and your compiler writers have worked on processor designs and are well aware of what was done in the past, having them lead the design of the VM - which is basically a hypervisor mode - is a sure road to disaster. I am sorry that I did not have enough time in the Sunday meeting to make this clear off-line.
It would also be a bad idea for me to write the backend - I'd have to spend the years they have invested in learning how to write gcc backends before I could do a good job of that...
I had the definite feeling that Parallax wanted something as soon as possible - probably in 6 months to a year.
If Chip manages to fit in the simple four instruction wide cache (using the existing RDQLONG logic) we will get even better performance, and his improvements to my suggestion will also speed up ZOG, Spin and other VM's.
But even if that does not fit, with proper use of FCACHE, I believe the performance targets can still be met.
The original propeller architecture was a very poor fit for C - LMM made it possible, and Prop2 with the improvements can make C perform quite well - assuming proper use of FCACHE and an extremely detailed low level experience with the Prop.
Do you believe any compiler can implement FCACHE calls easily? I fear the reason an instruction FCACHE has not been used so far is because of the difficulty of getting the compiler to actually emit code that would do the job. ImageCraft implemented a data cache version, but that's different.
I am in the happy position of being able to agree completely with both you and Bill:
Yes, FCACHE could give you substantial performance improvements if you could make effective use it.
Yes, writing a code generator that could make effective use of FCACHE would be extremely difficult - I am tempted to say impossible, but you know where saying things like that that gets you when discussing the Propeller .
3) I am very excited that Propeller 2 is getting close
I do not take your post as an insult, however (please do not take the following as an insult) I am far better qualified to evaluate the possibilities of LMM, and attainable performance levels, due to my CS background, unusual level of interest in processor architecture, and having worked on it since introducing it some years ago.
If you were not totally overboard with this particular "Bill Henning brand" of enthusiasm (not intended as an insult), i would be concerned that you didn't care. I'm glad that you care.
Bill I agree with all your points especially regarding coming up to speed with the Propeller architecture, and that's why the candidate GCC engineers now have copies of your documents as we agreed to on Sunday. They will review the documents and will have questions. They will propose what they are comfortable with I'm sure. Of course a full study, feasibility, and time frames can not be properly considered without instruction set documentation.
The sooner we get a private forum for GCC development which you suggested, the better.
Bill, please be careful to not allow your god-like self-valuation derail the project.
Thanks for that "I'll make a C programmer out of you yet!" -
- But as You maybe already know I'm are Hardware guru AND my Programing are mostly in ASM as it's only language that GIVE me possibility to Control Hardware totally.
A little decorum, please! You are both getting all "het up" for the same reason - because of your enthusiasm for the Propeller!
The fact is you both have a significant part to play.
I myself am a little sad that the GCC effort appears to be being undertaken "in private" - but if we want it to take place in public, we will all need to show a little more respect for each other's capabilities!
Bill, you were not insulted. Your skills were not called into question. I was just making it clear that others may take offense to your ego in hopes that you might tone it down a little. Your humility fuse does seem a little worn out.
... why alternate kernel models are less appropriate, and I think the list I posted of the styles I've tried covers every way C could run on the propeller with any semblance of efficiency.
Let me be a lightning rod here - I make this bold prediction about the Prop II:
The most effecitve technique for implementing a high level language on the Prop II has not even been thought of yet!
And here's a corollary:
If this is true, then when this technique is found, Catalina will be amongst the first compilers to implement it!
In case such a technique exists, I hope you are the one that finds it!
I know how to make a Prop3 VERY efficient at C, but it requires a level of changes to the architecture that is far too late for Prop2, and I did not want to distract Chip with it.
However "Your humility fuse does seem a little worn out." indicates that you still do not understand why the compiler drivers cannot drive the kernel development process, and that they cannot come up with an alternative in any reasonable amount of time.
Wow. Way to belittle anyone who might have thought about contributing.
Bill you mean this? "As part of the specification and feasibility phase ot the project, he will determine whether or not it is suitable for GCC in whole or in part. No doubt he will be interested in your other ideas."
If it is not suitable, for example if he decides that he can not do FCACHE in a reasonable amount of time, I will recommend adopting a platform agnostic version of Catalina which uses professional tools such as makefiles, binary utilities, and libraries, etc... where all code is vetted and reviewed by the community. The other professional partnership alternatives have already been put forward, and will likely be dismissed.
I'm not interested in a 2 man-year back-end port. If a version of Catalina is the way to go then Ross will have full responsibility for the C compiler and VM. Then he can make decisions about what to do there.
As you suggested at the beginning of the meeting, the approach to time is stepwise. This is in line with what Ken and I discussed before. Milestones will be set accordingly. We don't even have an official project start.
Once I actually calmed down, and my wife came home and told me I over-reacted, I decided that wifey (once again, painfully) was right. My wife really appreciated your professional "referee" post. ''Nuff said.
Therefore I went back and cleaned up my posts to remove anything I thought was part of the over-reaction.
A little decorum, please! You are both getting all "het up" for the same reason - because of your enthusiasm for the Propeller!
The fact is you both have a significant part to play.
I myself am a little sad that the GCC effort appears to be being undertaken "in private" - but if we want it to take place in public, we will all need to show a little more respect for each other's capabilities!
Yep, that is what I meant. I interpreted it as "if he does not like the concept of LMM, he will try to find an alternative",
Which is why I posted the alternatives I had worked with, in order to give him more data.
As usual, a misunderstanding. I've cleaned up my posts
Bill you mean this? "As part of the specification and feasibility phase ot the project, he will determine whether or not it is suitable for GCC in whole or in part. No doubt he will be interested in your other ideas."
If it is not suitable, for example if he decides that he can not do FCACHE in a reasonable amount of time, I will recommend adopting a platform agnostic version of Catalina which uses professional tools such as makefiles, binary utilities, and libraries, etc... where all code is vetted and reviewed by the community. The other professional partnership alternatives have already been put forward, and will likely be dismissed.
I'm not interested in a 2 man-year back-end port. If a version of Catalina is the way to go then Ross will have full responsibility for the C compiler and VM. Then he can make decisions about what to do there.
As you suggested at the beginning of the meeting, the approach to time is stepwise. This is in line with what Ken and I discussed before. Milestones will be set accordingly. We don't even have an official project start.
Funny. Yes. You may be asked to give up having to test hundreds of variations though
What I mean is that the compiler and VM would just be one very important part of a larger package. Other parts would be necessary such as a linker, linker scripts, and other common binary utilities. I know your binder does lots of the linker function, but having to constantly add platforms and memory models is a little difficult. GCC has lots of flexibility that presumably many ParallaxSemiconductor target customers have come to expect. IMHO Catalina should also be capable of such things.
Any idea when you will be adding C++ and Objective-C support?
Any idea when you will be adding C++ and Objective-C support?
That's easy - I'll add C++ and Objective-C support as soon as someone comes up with a sensible reason why these languages should ever be considered for a professional embedded microcontroller project.
Would you like Java, Fortran and Ada support as well? Same answer!
No, I did not request compiled Java, Fortran, Ada, or Go for that matter There is a place for C++ (arduwhoknows) and the number of Objective C programs running on iPhones, etc... at any given time probably exceeds the total number of Propellers sold to date.
But that all "begs the question" why would we exclude those languages if they are available essentially for free in the GCC environment.
This is a serious question because as the direction of GCC becomes more clear, we'll have to decide whether or not to support other languages. The default answer is to support whatever GCC supports.
No, I did not request compiled Java, Fortran, Ada, or Go for that matter There is a place for C++ (arduwhoknows) and the number of Objective C programs running on iPhones, etc... at any given time probably exceeds the total number of Propellers sold to date.
Hmmm. The Propeller II (or III for that matter) is unlikely to have enough grunt to sensibly be the processor of choice to run either Objective C or C++ application (except possibly a heavily cripped version like the one used on the ardutellsomeonewhocares).
The processor used on the iPhone (this just from a quick google) is somewhere between 750Mhz and 1Ghz (depending on the model), has a built-in memory management unit, integrated L1 and L2 cache, floating point support and several hundred megabytes of available program space. The Prop II (on the other hand) runs at 160Mhz, has no floating point or memory management, and has only a couple of hundred kilobytes of uncached, unmanaged memory.
Yes, the Propeller has eight cogs - but from a high-level language perspective, each cog is just a 160Mhz processor with round-robin access to a single pool of unmanaged, uncached memory. Even if you had all eight cogs running Objective C, you'd still look sick compared to a single ARM11 or Cortex-A8 processor.
It's fair enough to want to offer all the GCC languages for its marketing appeal, or to try and capture some of the hobbyist market currently claimed by other hobbyist offerings - but let's not fool ourselves into thinking anyone sensible would use the Propeller to run a C++ or Objective-C application when there are other processor can do the job faster - and possibly cheaper (I just checked the prices on DigiKey, and they're frighteningly low even for one-offs!).
Don't get me wrong - I'm sure the Propeller II will find plenty of uses - but not as an iPhone killer. It will find use as an extermely sophisticated embedded micrcontroller, and not as a general purpose microprocessor.
I thought I was a bit tipsy last night, wasn't quite sure I was was reading things correctly. Turns out things were getting a bit heated around here. Looks like everyone is getting over excited by the now rapidly advancing Prop II:)
A few things:
"Arduino" is an Italian word meaning "friend". It is also a common boys name in Italy. If it were my name I might get a bit miffed at how it is abused around here.
Languages on the Prop:
Java - No too slow, to big, needs a memory manager, not real-time enough.
Fortran - Only for the old geeks
Ada - Why not? There is even Ada for little 8 bit AVRs http://sourceforge.net/apps/mediawiki/avr-ada/index.php?title=AVR-Ada
In principle there is no reason code generated from Ada is any bigger or less efficient than that from a C compiler. You may want to switch off all run time checks though.
Go - No idea, probably not.
C++ - Didn't we do this argument on the Zog thread? There is no reason not to use C++ on a small device like the Prop if you can use C. The generated code is the same if you are using C features and the overheads of implementing objects in the style of Spin is none when compared to implementing similar "objectness" in C.
There is nothing crippled about the C++ as used in Arduino. Perhaps the ton of library classes you might expect on your PC is not there. So what? And perhaps new and delete are not a good idea, or big objects on the stack, without a lot of memory and a memory allocator. But that's just the same as avoiding floating point in C if your processor has no FP support.
RossH,
...let's not fool ourselves into thinking anyone sensible would use the Propeller to run a C++ ... application [on the Prop]
Is it not the case that any caching going on in conjunction with LMM is only of any use if the code in the cache is a tight loop? This clearly gives native speed. But for a compiler to make use of this it has to identify such tight loops that might fit in the cache. It then perhaps has to rewrite that loop code, and perhaps code around it, to use in the cache mode.
Now, I'm no compiler writer but it seems to me that:
1) This is asking a lot of the compiler. Probably is not easy to do.
2) In most C code such loops are not so common. things like strcmp come to mind.
My tentative conclusion that a C compiler producing LMM with code caching is unlikely to happen.
Ada - Why not? There is even Ada for little 8 bit AVRs http://sourceforge.net/apps/mediawiki/avr-ada/index.php?title=AVR-Ada
In principle there is no reason code generated from Ada is any bigger or less efficient than that from a C compiler. You may want to switch off all run time checks though.
Actually, you are perfectly correct. Ada makes much more sense than C++ for a small embedded system - especially Spark Ada (the verifiable subset of Ada intended for safety critical applications).
But my argument is not from a technical perspective - it is from a commercial perspective. If someone seriously tried to tell Parallax that they had to have GCC because they needed Ada, and that they would buy a million Propellers if they offered it, Parallax would know they were pulling their leg. Same with Objective-C. But with C++ it is just vaguely possible that this could happen - at least until the customer asked for some benchmark results and discovered how much faster their product would run with even a small ARM processor.
Ross.
P.S. I've seen that article (or a very similar one) before. The most persuasive counter argument is of course the Arduino itself. Why does the Arduino not support the full C++ language? ...
Why does the Arduino not support the full C++ language?
I was waiting for that, or similar, question.
I might counter that and say "Why do most C implementations, on MCUs or even my PC, not support the full C language?
Sill question? No. In C I can:
1) Declare huge arrays, that does not mean that I will get them at run time. Why not, language says I can?
2) Write massively recursive functions that will crash when I try to run them. Why, language says I can?
3) Access 2 byte and 4 byte ints that are not alligned on 2 or 4 byte boundaries. This may well fail on a machine, eg 68000, ARM, that will throw a bus error on misaligned memory accesses. Why, language says I can?
4) And so on.
Naturally this is dumb and I have to write my code with these limitations in mind.
Similarly C++ offers a huge range of features that may not make any sense to use on a small system. So, just use what makes sense like you do in C.
Now, who says Arduino does not support the full C++ language? As far as I know it's the same GCC C++ that I use on my PC.
Perhaps the full gamut of libraries is not available. Naturally they are not suitable or too big. But then you and I have always see language and libraries in a different light. In my mind the language is the syntax and symatics, it is not the libraries. Despite the fact that some functions and classes are mandated by standards organizations. If I don't have room for printf in my C programs on a tiny PIC or AVR that does not mean I am not using the full C language. In my mind anyway.
RossH,
I think you have some misguided lofty impression of what C++ is... The language (not the STL or other Smile piled on top) is really quite simple, and really quite suitable for small processors. With a good compiler, C++ source code can be significantly smaller (less actual text typed in by the coder) and produce equivalent output to a straight C version given the same tasks. In fact, in some cases it can produce the same results from less actual output assembly. I'm just baffled by your constant dismissing of C++ as being something far too big and cumbersome for a small processor. Also, I will most certainly write C++ code for the Prop 2. As will MANY of parallax's future commercial customers that will use the GCC stuff on Prop 2.
Others:
I am sorry for the delay in getting details about the Prop2 instructions, I underestimated the amount of time it would take to get all the details about them from Chip. Mostly because many of the new instructions are very rich in capability and features. In fact, I ran out of time with Chip (had to come home) and there are a few instructions that I don't have info for yet. I'll get the data I have posted soon (next few days), and get more info later from Chip.
Regarding private forums for GCC and LMM2 discussions and development. I spoke with both Chip and Ken today, and we are all in agreement that we do not like that idea at all. The intention is that this all be as open as possible. They do not want to hide stuff in private forums. They accept that occasionally a private email discussion or phone call might be needed, but expect that those will be uncommon and the results of those will still end up being posted in open forums. The intention all along is that the GCC stuff and LMM that runs it would be completely open source and open developed. Why would we want to hide on private forums? It doesn't make any sense.
RossH,
I think you have some misguided lofty impression of what C++ is... The language (not the STL or other Smile piled on top) is really quite simple, and really quite suitable for small processors. With a good compiler, C++ source code can be significantly smaller (less actual text typed in by the coder) and produce equivalent output to a straight C version given the same tasks. In fact, in some cases it can produce the same results from less actual output assembly. I'm just baffled by your constant dismissing of C++ as being something far too big and cumbersome for a small processor. Also, I will most certainly write C++ code for the Prop 2. As will MANY of parallax's future commercial customers that will use the GCC stuff on Prop 2.
Sorry Roy, but me and Wikipedia both disagree with you :
Of course, you call call anything "C++" if you like, just as (to take up a point in Heater's email) you can call anything "C". Just don't try and pretend you are ANSI/ISO compliant if you do not implement the whole standard - it just annoys people. An implementation that does not conform to the standard is largely useless for most professional purposes. It is also (ultimately) doing a disservice to hobbyists to offer them tools that they will not be able to use for professional purposes should they ever choose to do so.
And I think you misunderstand my objections to C++. When I first moved from C to C++, I thought C++ was the best thing since sliced bread. But eventually I learned better. Over the years, and for various companies, I have been involved (as a programmer) in large-scale industrial real-time telemetry applications (power and water distribution, building management, fire control, process control, power station control, etc, etc). I have helped build these systems in Assembly (yes, I'm that old!), C, Modula-2, C++ & Ada. In some cases I have redeveloped essentially the same system in several of these languages (as various language fads have come and gone).
Here are some interesting conclusions I can draw from 30+ years experience for you:
Ranking these systems in terms of longevity (shortest in-service life to longest):
C++ (shortest service life), Ada, Modula-2, Assembly, C (longest - in fact still in service)
Ranking these systems in terms of performance (slowest to fastest):
C++ (slowest), Ada, Modula-2, C, Assembly (fastest)
Ranking these systems in terms of maintainance cost (most expensive to least expensive):
C++ (most expensive to maintain), Ada, Modula-2, Assembly, C (least expensive to maintain)
Ranking these systems in terms of complexity (most complex to least complex):
C++ (most complex), Assembly, C, Modula-2, Ada (least complex)
Ranking these systems in terms of defects found during their lifetime (most bugs to least bugs):
C++ (most bugs), Assembly, C, Modula-2, Ada (least bugs)
Of course, there are many reasons for the relative ranking, and it is not all that simple to compare them without being at least partially subjective (because the compiler and computer technology was not constant for the whole time). You could certainly argue a ranking here or there. But one thing is absolutely certain - the most complex systems, that performed the worst, were by far the costliest to construct and maintain, and were most defect prone were the C++ systems. In all cases they were pretty much junked almost as soon as they were finished (in fact several of them were junked before they were finished). I would happily agree with you that a large factor in the terrible performance of C++ in real-time applications is not the core language, but the STL (and its various precursors) - but you can't really call it C++ without this component.
Of course, everyone now says C++ compilers have come a long way - but what they tend to forget is that so have other compilers. Ada compilers are easily the most sophisticated compilers yet built - far and away more sophisticated than any C or C++ compilers. But even the lowly C compilers have improved over the years.
So I don't dismiss C++ lightly, or with no evidence. And I do know that C++ can be used effectively in embedded environments - provided you either have a surfiet of processing power and memory, or limit yourself to a subset of the language (as does the Arduino). My point (which I have made before) is that the subset to which you have to restrict yourself to is near enough to C to make me wonder why anyone would bother with C++ for an embedded application. And the evidence (of course) shows that most professional developers simply don't bother with C++ for such purposes. They use C. Or assembly. In embedded applications it is mostly hobbyists who use C++ - or rather the subset of C++ available on the Arduino.
I'm all in favor of GCC for the Propeller. But do it for the right reasons. Not spurious reasons based on some incorrect perception that customers are going to fall at your feet just because you offer GCC. Or that the Propeller is going to be used in the next iPhone or replace the Arduino just because it offers GCC. This simply isn't going to happen. GCC may help a bit - but that's all.
Of course, you can say "Then how come the Arduino is so successful?". Well, the answer is not GCC. It has a lot more to do with the "wiring" libraries provided, which simplify development for people who are not professional programmers, the IDE proivided (ditto) and the fact that everything (hardware and software) is open source and cheap as chips. Much cheaper than any equivalent Parallax development boards.
Others:
I am sorry for the delay in getting details about the Prop2 instructions, I underestimated the amount of time it would take to get all the details about them from Chip. Mostly because many of the new instructions are very rich in capability and features. In fact, I ran out of time with Chip (had to come home) and there are a few instructions that I don't have info for yet. I'll get the data I have posted soon (next few days), and get more info later from Chip.
Regarding private forums for GCC and LMM2 discussions and development. I spoke with both Chip and Ken today, and we are all in agreement that we do not like that idea at all. The intention is that this all be as open as possible. They do not want to hide stuff in private forums. They accept that occasionally a private email discussion or phone call might be needed, but expect that those will be uncommon and the results of those will still end up being posted in open forums. The intention all along is that the GCC stuff and LMM that runs it would be completely open source and open developed. Why would we want to hide on private forums? It doesn't make any sense.
Glad to hear it - it certainly seemed to me that the GCC effort was in danger of becoming a private affair to which the wider community was not expected to contribute. I think Bill felt a bit the same way. I know everyone is busy (what with UPEW and everything) but I would have thought that some update on the outcome of the webinar could have been issued by now. For goodness sake - I attended the webinar and I still feel left in the dark! How do you think other interested onlookers feel?
Now, who says Arduino does not support the full C++ language? As far as I know it's the same GCC C++ that I use on my PC.
No - it uses AVR-GCC. See this link. No C++ standard library functions. No templates. No dynamic memory allocation (new, delete etc). No exceptions. These limitations alone would rule out more than 90% of all pre-existing C++ applications running on an Arduino.
the Arduino language is merely a set of C/C++ functions that can be called from your code. Your sketch undergoes minor changes (e.g. automatic generation of function prototypes) and then is passed directly to a C/C++ compiler (avr-g++). All standard C and C++ constructs supported by avr-g++ should work in Arduino.
"Arduino" is an Italian word meaning "friend". It is also a common boys name in Italy. If it were my name I might get a bit miffed at how it is abused around here.
"arduino" doesn't exists in the italian dictionary and "Arduino" is a male name but not common, it is a past name and I really doubt that nowadays someone will call his son like this
But perhaps even being an italian I could be wrong
PS.: to team members - Interesting thread, keep the good work going on. I wish success to all of you and if someday you will need and I can help I will, even only with valium
Thanks for very nice description why I don't like "C".
Most of people that read --- IT is C++ else Other type of "C" not consider if it Are ANSI/ISO compatible.
BUT most of "C" variants on Micros are NOT compatible with that -- And NOT so portable them will it be.
Most of code moving from one type of Micro to another need some rewrite in some degrees. Even if it is same variant of "C" used on that another Micro.
BUT I understand NEED for "C" of any variant on Propeller/Propeller II. That Give people that can only program in "C" possibility to be comfortable to rewrite that parts of code to PORT it to Propeller/Propeller II
And that is biggest Advantage of having any type of "C" that support Propeller/Propeller II.
Of course, you call call anything "C++" if you like, just as (to take up a point in Heater's email) you can call anything "C". Just don't try and pretend you are ANSI/ISO compliant if you do not implement the whole standard - it just annoys people. An implementation that does not conform to the standard is largely useless for most professional purposes. It is also (ultimately) doing a disservice to hobbyists to offer them tools that they will not be able to use for professional purposes should they ever choose to do so.
>
Comments
Thanks, Sapieha - but just wait till you see how much better Catalina works on the Prop II - I'll make a C programmer out of you yet!
Ross.
I freely admit proper use of FCACHE is not trivial, but neither is writing any good compiler. If writing quality compilers was easy, GCC, LCC, etc would be lost in a sea of competitors.
Part of the reason that existing LMM compilers don't use it effectively is due to a lack of documentation with examples of how to properly use FCACHE. I will be releasing some more documentation on my site, possibly later tonite, that I wrote a couple of years ago for a proposed series of articles for Circuit Cellar. Unfortunately due to urgent consulting contracts, I did not finish the series in time and it never got published. I've been too busy since to try to submit it to another magazine, however as long as the pdf's are only available from my site, I still may be able to do so. As it is, I plan to do a series on LMM2 and submit those.
Why did I not publish them earlier? Since I freely published my LMM, I thought to use it to get more good consulting work by publishing my findings in a popular magazine.
I think that experienced compiler back end writers could do a good job on using FCACHE to optimize code if and only if:
The compiler writers don't try to dictate how the kernel should be written, instead listen to the kernel designer on how FCACHE should be used.
Why?
They simply have not spent more than three years working on it, and on getting to know the propeller inside out, sideways - and very very few will have anywhere near my level of interest in processor architecture.
Given ample time (somewhere between 1-2 years), good compiler writers experienced with multiple architectures (RISC, CISC and VLIW at a minimum) they could duplicate my research and findings (assuming similar CS backgrounds and similar unusual level of interest in past/present/future processor architectures) and then they could write a very good LMM kernel.
Heck, I would not dream of telling back end writers "this is how you must write the code that manipulates the intermediate code to produce the desired result" - I would say "here is the basic kernel, here are some general design principles of how to do FCACHE properly, now study that, and come back to me in a week with your ideas - BUT you are forbidden to take the easy way out and just make a zillion primitives, as that will severely limit your performance". That does NOT mean that they could not get a few helper functions that makes the work easier. It does mean using a large FCACHE properly.
Unless you are designing a new architecture from the ground up, and your compiler writers have worked on processor designs and are well aware of what was done in the past, having them lead the design of the VM - which is basically a hypervisor mode - is a sure road to disaster. I am sorry that I did not have enough time in the Sunday meeting to make this clear off-line.
It would also be a bad idea for me to write the backend - I'd have to spend the years they have invested in learning how to write gcc backends before I could do a good job of that...
I had the definite feeling that Parallax wanted something as soon as possible - probably in 6 months to a year.
If Chip manages to fit in the simple four instruction wide cache (using the existing RDQLONG logic) we will get even better performance, and his improvements to my suggestion will also speed up ZOG, Spin and other VM's.
But even if that does not fit, with proper use of FCACHE, I believe the performance targets can still be met.
The original propeller architecture was a very poor fit for C - LMM made it possible, and Prop2 with the improvements can make C perform quite well - assuming proper use of FCACHE and an extremely detailed low level experience with the Prop.
1) I have been working on it for a long time
2) I know it can be done
3) I am very excited that Propeller 2 is getting close
I do not take your post as an insult, however (please do not take the following as an insult) I am far better qualified to evaluate the possibilities of LMM, and attainable performance levels, due to my CS background, unusual level of interest in processor architecture, and having worked on it since introducing it some years ago.
On re-reading, I appreciated your quote :-)
The sooner we get a private forum for GCC development which you suggested, the better.
Bill, please be careful to not allow your god-like self-valuation derail the project.
My wife pointed out that you probably did not intend an insult,
and I do appreciate your agreeing with my points.
Thanks for that "I'll make a C programmer out of you yet!" -
- But as You maybe already know I'm are Hardware guru AND my Programing are mostly in ASM as it's only language that GIVE me possibility to Control Hardware totally.
A little decorum, please! You are both getting all "het up" for the same reason - because of your enthusiasm for the Propeller!
The fact is you both have a significant part to play.
I myself am a little sad that the GCC effort appears to be being undertaken "in private" - but if we want it to take place in public, we will all need to show a little more respect for each other's capabilities!
Ross.
Let me be a lightning rod here - I make this bold prediction about the Prop II:
I know how to make a Prop3 VERY efficient at C, but it requires a level of changes to the architecture that is far too late for Prop2, and I did not want to distract Chip with it.
Wow. Way to belittle anyone who might have thought about contributing.
Bill are you a hardware engineer perchance?
Actually CS, with a heavy emphasis on computer and processor architecture, and as many hardware courses as I could get.
If it is not suitable, for example if he decides that he can not do FCACHE in a reasonable amount of time, I will recommend adopting a platform agnostic version of Catalina which uses professional tools such as makefiles, binary utilities, and libraries, etc... where all code is vetted and reviewed by the community. The other professional partnership alternatives have already been put forward, and will likely be dismissed.
I'm not interested in a 2 man-year back-end port. If a version of Catalina is the way to go then Ross will have full responsibility for the C compiler and VM. Then he can make decisions about what to do there.
As you suggested at the beginning of the meeting, the approach to time is stepwise. This is in line with what Ken and I discussed before. Milestones will be set accordingly. We don't even have an official project start.
Errr ... Ummm ... haven't I always had that?
But thanks, jazzed ... I think.
Thank you.
Once I actually calmed down, and my wife came home and told me I over-reacted, I decided that wifey (once again, painfully) was right. My wife really appreciated your professional "referee" post. ''Nuff said.
Therefore I went back and cleaned up my posts to remove anything I thought was part of the over-reaction.
Yep, that is what I meant. I interpreted it as "if he does not like the concept of LMM, he will try to find an alternative",
Which is why I posted the alternatives I had worked with, in order to give him more data.
As usual, a misunderstanding. I've cleaned up my posts
What I mean is that the compiler and VM would just be one very important part of a larger package. Other parts would be necessary such as a linker, linker scripts, and other common binary utilities. I know your binder does lots of the linker function, but having to constantly add platforms and memory models is a little difficult. GCC has lots of flexibility that presumably many ParallaxSemiconductor target customers have come to expect. IMHO Catalina should also be capable of such things.
Any idea when you will be adding C++ and Objective-C support?
That's easy - I'll add C++ and Objective-C support as soon as someone comes up with a sensible reason why these languages should ever be considered for a professional embedded microcontroller project.
Would you like Java, Fortran and Ada support as well? Same answer!
Ross.
But that all "begs the question" why would we exclude those languages if they are available essentially for free in the GCC environment.
This is a serious question because as the direction of GCC becomes more clear, we'll have to decide whether or not to support other languages. The default answer is to support whatever GCC supports.
Hmmm. The Propeller II (or III for that matter) is unlikely to have enough grunt to sensibly be the processor of choice to run either Objective C or C++ application (except possibly a heavily cripped version like the one used on the ardutellsomeonewhocares).
The processor used on the iPhone (this just from a quick google) is somewhere between 750Mhz and 1Ghz (depending on the model), has a built-in memory management unit, integrated L1 and L2 cache, floating point support and several hundred megabytes of available program space. The Prop II (on the other hand) runs at 160Mhz, has no floating point or memory management, and has only a couple of hundred kilobytes of uncached, unmanaged memory.
Yes, the Propeller has eight cogs - but from a high-level language perspective, each cog is just a 160Mhz processor with round-robin access to a single pool of unmanaged, uncached memory. Even if you had all eight cogs running Objective C, you'd still look sick compared to a single ARM11 or Cortex-A8 processor.
It's fair enough to want to offer all the GCC languages for its marketing appeal, or to try and capture some of the hobbyist market currently claimed by other hobbyist offerings - but let's not fool ourselves into thinking anyone sensible would use the Propeller to run a C++ or Objective-C application when there are other processor can do the job faster - and possibly cheaper (I just checked the prices on DigiKey, and they're frighteningly low even for one-offs!).
Don't get me wrong - I'm sure the Propeller II will find plenty of uses - but not as an iPhone killer. It will find use as an extermely sophisticated embedded micrcontroller, and not as a general purpose microprocessor.
Ross.
I thought I was a bit tipsy last night, wasn't quite sure I was was reading things correctly. Turns out things were getting a bit heated around here. Looks like everyone is getting over excited by the now rapidly advancing Prop II:)
A few things:
"Arduino" is an Italian word meaning "friend". It is also a common boys name in Italy. If it were my name I might get a bit miffed at how it is abused around here.
Languages on the Prop:
Java - No too slow, to big, needs a memory manager, not real-time enough.
Fortran - Only for the old geeks
Ada - Why not? There is even Ada for little 8 bit AVRs
http://sourceforge.net/apps/mediawiki/avr-ada/index.php?title=AVR-Ada
In principle there is no reason code generated from Ada is any bigger or less efficient than that from a C compiler. You may want to switch off all run time checks though.
Go - No idea, probably not.
C++ - Didn't we do this argument on the Zog thread? There is no reason not to use C++ on a small device like the Prop if you can use C. The generated code is the same if you are using C features and the overheads of implementing objects in the style of Spin is none when compared to implementing similar "objectness" in C.
There is nothing crippled about the C++ as used in Arduino. Perhaps the ton of library classes you might expect on your PC is not there. So what? And perhaps new and delete are not a good idea, or big objects on the stack, without a lot of memory and a memory allocator. But that's just the same as avoiding floating point in C if your processor has no FP support.
RossH,
I might:)
Anyway, here is a nice article arguing this point:
http://v2.embedded.com/98/9802fe3.htm
ObjectiveC - No idea.
About LMM and caching and compilers:
Is it not the case that any caching going on in conjunction with LMM is only of any use if the code in the cache is a tight loop? This clearly gives native speed. But for a compiler to make use of this it has to identify such tight loops that might fit in the cache. It then perhaps has to rewrite that loop code, and perhaps code around it, to use in the cache mode.
Now, I'm no compiler writer but it seems to me that:
1) This is asking a lot of the compiler. Probably is not easy to do.
2) In most C code such loops are not so common. things like strcmp come to mind.
My tentative conclusion that a C compiler producing LMM with code caching is unlikely to happen.
Actually, you are perfectly correct. Ada makes much more sense than C++ for a small embedded system - especially Spark Ada (the verifiable subset of Ada intended for safety critical applications).
But my argument is not from a technical perspective - it is from a commercial perspective. If someone seriously tried to tell Parallax that they had to have GCC because they needed Ada, and that they would buy a million Propellers if they offered it, Parallax would know they were pulling their leg. Same with Objective-C. But with C++ it is just vaguely possible that this could happen - at least until the customer asked for some benchmark results and discovered how much faster their product would run with even a small ARM processor.
Ross.
P.S. I've seen that article (or a very similar one) before. The most persuasive counter argument is of course the Arduino itself. Why does the Arduino not support the full C++ language? ...
I was waiting for that, or similar, question.
I might counter that and say "Why do most C implementations, on MCUs or even my PC, not support the full C language?
Sill question? No. In C I can:
1) Declare huge arrays, that does not mean that I will get them at run time. Why not, language says I can?
2) Write massively recursive functions that will crash when I try to run them. Why, language says I can?
3) Access 2 byte and 4 byte ints that are not alligned on 2 or 4 byte boundaries. This may well fail on a machine, eg 68000, ARM, that will throw a bus error on misaligned memory accesses. Why, language says I can?
4) And so on.
Naturally this is dumb and I have to write my code with these limitations in mind.
Similarly C++ offers a huge range of features that may not make any sense to use on a small system. So, just use what makes sense like you do in C.
Now, who says Arduino does not support the full C++ language? As far as I know it's the same GCC C++ that I use on my PC.
Perhaps the full gamut of libraries is not available. Naturally they are not suitable or too big. But then you and I have always see language and libraries in a different light. In my mind the language is the syntax and symatics, it is not the libraries. Despite the fact that some functions and classes are mandated by standards organizations. If I don't have room for printf in my C programs on a tiny PIC or AVR that does not mean I am not using the full C language. In my mind anyway.
I think you have some misguided lofty impression of what C++ is... The language (not the STL or other Smile piled on top) is really quite simple, and really quite suitable for small processors. With a good compiler, C++ source code can be significantly smaller (less actual text typed in by the coder) and produce equivalent output to a straight C version given the same tasks. In fact, in some cases it can produce the same results from less actual output assembly. I'm just baffled by your constant dismissing of C++ as being something far too big and cumbersome for a small processor. Also, I will most certainly write C++ code for the Prop 2. As will MANY of parallax's future commercial customers that will use the GCC stuff on Prop 2.
Others:
I am sorry for the delay in getting details about the Prop2 instructions, I underestimated the amount of time it would take to get all the details about them from Chip. Mostly because many of the new instructions are very rich in capability and features. In fact, I ran out of time with Chip (had to come home) and there are a few instructions that I don't have info for yet. I'll get the data I have posted soon (next few days), and get more info later from Chip.
Regarding private forums for GCC and LMM2 discussions and development. I spoke with both Chip and Ken today, and we are all in agreement that we do not like that idea at all. The intention is that this all be as open as possible. They do not want to hide stuff in private forums. They accept that occasionally a private email discussion or phone call might be needed, but expect that those will be uncommon and the results of those will still end up being posted in open forums. The intention all along is that the GCC stuff and LMM that runs it would be completely open source and open developed. Why would we want to hide on private forums? It doesn't make any sense.
Sorry Roy, but me and Wikipedia both disagree with you
And I think you misunderstand my objections to C++. When I first moved from C to C++, I thought C++ was the best thing since sliced bread. But eventually I learned better. Over the years, and for various companies, I have been involved (as a programmer) in large-scale industrial real-time telemetry applications (power and water distribution, building management, fire control, process control, power station control, etc, etc). I have helped build these systems in Assembly (yes, I'm that old!), C, Modula-2, C++ & Ada. In some cases I have redeveloped essentially the same system in several of these languages (as various language fads have come and gone).
Here are some interesting conclusions I can draw from 30+ years experience for you:
Ranking these systems in terms of longevity (shortest in-service life to longest):
Of course, everyone now says C++ compilers have come a long way - but what they tend to forget is that so have other compilers. Ada compilers are easily the most sophisticated compilers yet built - far and away more sophisticated than any C or C++ compilers. But even the lowly C compilers have improved over the years.
So I don't dismiss C++ lightly, or with no evidence. And I do know that C++ can be used effectively in embedded environments - provided you either have a surfiet of processing power and memory, or limit yourself to a subset of the language (as does the Arduino). My point (which I have made before) is that the subset to which you have to restrict yourself to is near enough to C to make me wonder why anyone would bother with C++ for an embedded application. And the evidence (of course) shows that most professional developers simply don't bother with C++ for such purposes. They use C. Or assembly. In embedded applications it is mostly hobbyists who use C++ - or rather the subset of C++ available on the Arduino.
I'm all in favor of GCC for the Propeller. But do it for the right reasons. Not spurious reasons based on some incorrect perception that customers are going to fall at your feet just because you offer GCC. Or that the Propeller is going to be used in the next iPhone or replace the Arduino just because it offers GCC. This simply isn't going to happen. GCC may help a bit - but that's all.
Of course, you can say "Then how come the Arduino is so successful?". Well, the answer is not GCC. It has a lot more to do with the "wiring" libraries provided, which simplify development for people who are not professional programmers, the IDE proivided (ditto) and the fact that everything (hardware and software) is open source and cheap as chips. Much cheaper than any equivalent Parallax development boards.
That's great! Thanks.
Glad to hear it - it certainly seemed to me that the GCC effort was in danger of becoming a private affair to which the wider community was not expected to contribute. I think Bill felt a bit the same way. I know everyone is busy (what with UPEW and everything) but I would have thought that some update on the outcome of the webinar could have been issued by now. For goodness sake - I attended the webinar and I still feel left in the dark! How do you think other interested onlookers feel?
Ross.
No - it uses AVR-GCC. See this link. No C++ standard library functions. No templates. No dynamic memory allocation (new, delete etc). No exceptions. These limitations alone would rule out more than 90% of all pre-existing C++ applications running on an Arduino.
Ross.
Perhaps you had better write to the Arduino forums and tell them to correct their FAQ.
From http://www.arduino.cc/en/Main/FAQ:
"arduino" doesn't exists in the italian dictionary and "Arduino" is a male name but not common, it is a past name and I really doubt that nowadays someone will call his son like this
But perhaps even being an italian I could be wrong
PS.: to team members - Interesting thread, keep the good work going on. I wish success to all of you and if someday you will need and I can help I will, even only with valium
Thanks for very nice description why I don't like "C".
Most of people that read --- IT is C++ else Other type of "C" not consider if it Are ANSI/ISO compatible.
BUT most of "C" variants on Micros are NOT compatible with that -- And NOT so portable them will it be.
Most of code moving from one type of Micro to another need some rewrite in some degrees. Even if it is same variant of "C" used on that another Micro.
BUT I understand NEED for "C" of any variant on Propeller/Propeller II. That Give people that can only program in "C" possibility to be comfortable to rewrite that parts of code to PORT it to Propeller/Propeller II
And that is biggest Advantage of having any type of "C" that support Propeller/Propeller II.