Closing in on BETA ImageCraft C
ImageCraft
Posts: 348
The compiler, assembler, linker and the LMM kernel are code complete. We have run (very slowly since it involves manual loading the code and checking of the blinking LED in the end for a *pass* status (*)) 2000+ trivial, non-sensible, but useful compiler tests. They look something like this:
void main()
{
unsigned int a = { 4352};
unsigned int *p, b, c, d, i, j, sum, x, *s;
d = *(p + i);
sum = a[noparse][[/noparse]i + j] + *(a + i + j)+ *(p + i + j);
b = *(s + i);
}
This one is not an execution test so no need to tell me it won't run
The generated code is decent but definitely can be improved with peephole optimizations which we will be adding. Function calls etc. are working. As are variables in COG registers, COG local stack, HUB stack, and HUB direct data. Pretty much within limits of the hardware, any C integer code should work (we do have a couple failure cases to go through). No benchmark figure yet, but there is no reason to believe it is out of whack of back of envelope estimate. Lack of index mode means addressing even COG stack locals are more expensive than simple register references so there will be further tweaking later.
We are waiting for our software partner to finish the programming code, to be integrated to our IDE. All in all, moving along. Still no firm date yet, but we definitely hope to have a beta soon...
(*) We normally write an instruction set simulator for testing purpose but since the Propeller is unique in so many ways, we thought we will do the testing the hard way until we have enough experience with the hardware before doing the simulator.
// richard
void main()
{
unsigned int a = { 4352};
unsigned int *p, b, c, d, i, j, sum, x, *s;
d = *(p + i);
sum = a[noparse][[/noparse]i + j] + *(a + i + j)+ *(p + i + j);
b = *(s + i);
}
This one is not an execution test so no need to tell me it won't run
The generated code is decent but definitely can be improved with peephole optimizations which we will be adding. Function calls etc. are working. As are variables in COG registers, COG local stack, HUB stack, and HUB direct data. Pretty much within limits of the hardware, any C integer code should work (we do have a couple failure cases to go through). No benchmark figure yet, but there is no reason to believe it is out of whack of back of envelope estimate. Lack of index mode means addressing even COG stack locals are more expensive than simple register references so there will be further tweaking later.We are waiting for our software partner to finish the programming code, to be integrated to our IDE. All in all, moving along. Still no firm date yet, but we definitely hope to have a beta soon...
(*) We normally write an instruction set simulator for testing purpose but since the Propeller is unique in so many ways, we thought we will do the testing the hard way until we have enough experience with the hardware before doing the simulator.
// richard
Comments
Can't wait > Good luck!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
-Phil
Fact is that the Propeller will not stand the slightest chance for a major project done by anyone else but a Propeller addict, without a "professional" integrated development environment, which generally consists of:
- (optimizing) C Compiler
- Configuration/Version Management (or at least a simple link to one, SVN being the barest minimum)
- Reliable debugging (best hardware supported)
- Error free PC-simulation
---
Edit:I am fully aware that this community has done a lot in that direction. However this is far from being acceptable to a project manager having deadlines his annual bonus depends upon meeting them
Edit2: I LIKE the Propeller Tool... I would not have been able to completed my classes with something much more complex!
Post Edited (deSilva) : 3/1/2008 9:20:40 AM GMT
Sorry, for the misunderstanding. I ONLY utter my very personal experience; sometimes -maybe. maybe - just a little bit provocative...
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
deSilva
Registered Member
Posted 2/17/2008 6:51 PM (GMT -4)
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..
Taken from here:
http://forums.parallax.com/forums/default.aspx?f=25&m=254114
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
I also can't wait to buy your new propeller product. Could you please include a reliable terminal program in your IDE that works with both XP and VISTA for output and keyboard input. Thanks for your consideration.
Jim
OK, this should be easy as we have a terminal in our IDE since forever. It definitely works under XP and I haven't heard that it breaks under Vista. Actually, serial comm under Windows is one of those few things that are fairly straight forward, unless you are pushing for msec accuracy type of thing, so it should be all good there.
Hi deSilva, sorry for misquoting. Anyway, we are working hard on this release, and our goal is to be as reasonably fast as possible giving the constraints of support Standard C on the Propeller. No doubt about it, besides the normal compiler tuning (eliminating unnecessary register copies etc.) my guess is that there will be a lot of tuning WRT the LMM and runtime architecture. I haven't thought abotu it fully yet, but since the LMM kernel and the HUB timing is "out of sync" sometimes, *possibly* there may even be opportunities for rearranging instructions to take advantage of that kind of thing, but that needs investigation.
Post Edited (deSilva) : 3/2/2008 2:27:25 PM GMT
Ok, all well and good, now we have a proper terminal program. More problems: Will there be a separate Object Exchange for programs written in ImageCraft C. Will ImageCraft provide full time coverage to answer all our website questions. I personally will need a great deal of instructional material to get started. Will this be provided by you or will it be necessary for deSilva or Mr. deSilva (depending on your level of formality) to write another tutorial. If it is the latter than Mr. D should get started now. Another issue, I am afraid there is a rush to release and it could be very sloppy. How will the first versions of your program be updated for error corrections. How will we be notified about corrected versions and of course, there is always the issue of additional cost of corrected versions. The propeller, in my opinion, is very complicated due to cog interaction. I can visualize many cases where spin programs work and ImageCraft C programs do not work. All these issues will have to be sorted out. In the end, if you are not careful, it could be determined that if your program is relatively simple, than Image Craft C is fine, but if your program is complicated than it is better to stick with the native propeller language. I hope there is enough antacid and patience to overcome this nightmare. It might be better to let Mr. D test your software before it is released to us common folk.
Jim
I suggest you have a look at ImageCraft's website. They have a number of other C compilers for other microprocessors. I think you'll find that they are in the business of providing professionally done C compilers. They're not in the business of teaching people to program. There are all sorts of books on this written by others. Many of the issues that show up around multiprocessing also occur in writing I/O drivers for Linux and there are lots of books on just that subject.
If you feel like you will need a great deal of instructional material, you will not find it included with the compiler. You will need to invest in existing C language introductions and you will need to wait for others to write specific books on using ImageCraft's C to program the Propeller. It's a lot of work to do this sort of thing (writing a textbook) and the market is not very large, so you may have to wait a while.
I suggest you get some kind of general C introduction and work through it using a C compiler available for whatever kind of PC you have. There are several free C compilers and interpreters available for Windows, Linux, and the MacOS. After that, try working through the introduction using ImageCraft's compiler for the Propeller. At that point, you should be familiar enough with C and ImageCraft's compiler that you could apply what's already documented on multprocessor programming in Spin to C.
I am not talking about " learning C ", I am talking about cog interaction problems involving programs written in ImageCraft C. Unfortunately, there are no books about this subject. The propeller is unique.
Jim
Look back at the SPIN language: simple, streamlined, well documented (really!), an excellent tutorial (though you might know my quibbles WRT Blinker2..). It seems that it took this community around a year to find out to sort the different data types in VAR, to avoid things as COGNEW(obj.method,..) or to well understand the difference between data in DAT and VAR.
This with a language where a wealth of most specific examples had been written for, as EVERY Propeller user needs SPIN..
This will be different with the C compiler. I expect that MANY will use the "free" version of the C compiler, but also MANY will stop using it when the learning curve becomes too steep...
Some of Jim's question will be addressed in Imagecraft documentation, but might also need to be extracted... Efficient use of DIRA,OUTA, INA? Interface to other COGs? References to stack-variables, WHAT stack in the first place, fast "Register Variables", usage of something like "VOLATILE".
Mike is right that something similar is in every "embedded C", but what the hell is "similar" when it comes down to debugging
In a very mature C-System you will expect to find the most needed features as linkable modules (Keyboard, Mouse, TV, VGA,...) Of course I expect some of them readily available, as they are needed for integration and testing at Imagecraft. I also expect many holes there during the first months. In contrast to the situation with the early SPIN, I am not so optimistic that all our gifted programmers will at once start porting everything from SPIN/PASM to C...
It has been observed many times here that for efficient Propeller programming, a combination of SPIN and PASM is unbeatable.
The merrits of C lay otherwhere... And it's there where Jim's questions lead to... I think..
Post Edited (deSilva) : 3/2/2008 6:02:14 PM GMT
Beautifully said, please get to work on your tutorial.
Mike
My fear is that if the ImageCraft effort is not successful, the Propeller will get a bad reputation.
Jim
I'm aware there are issues regarding the use of C with the Propeller which remain unanswered, particularly as to how things will be done from a programmer's perspective, and I'm sure ImageCraft are equally aware of that. It's somewhat jumping the gun though to second guess whether ImageCraft provide perfect, adequate or lacking documentation - I'd personally prefer a C compiler available even if documentation is minimal or not finished ( is it ever ? ).
ImageCraft's primary role is to provide the tools to do the job and enough documentation to use the tools and to develop the programs people want to write. Beyond that anything else is a bonus, and it's largely up to the community using the tools to determine the best practice, tricks of the trade and example code to illustrate such things.
Will ImageCraft's C compiler fail to deliver what's needed ? I guess we'll have to wait and see but I cannot imagine they have set out on this project with such a destination in mind.
What I am interested in is teaching people to use a microcontroller (electronic interfacing and algorithms) without having to impose a (new) programming language on them in the beginning. A standard C with the least of deviations would be perfect, including my requests for an IDE as I listed further above
Of course there will be never something as short, simple, and useful as the SPIN "MainDeSilva" in "C"
PUB mainDeSilva DIRA ~~ REPEAT OUTA++Post Edited (deSilva) : 3/2/2008 7:07:10 PM GMT
-Phil
(1) Negative: The avarage attendee of such courses is not able to grasp concepts of a new language in a short time, even if he is fluent in another, but this is rare. The closer the new language is to what he already believes to know for sure, the worse... Software Engineers don't program any longer... Something you and me - being "polyglot" - tend to underestimate. The additional amount of time to teach a "new" language before it can be usefully applied the next weeks in the class is considerable.
(2) Positive: I do not aggree with you that the Propeller needs any specific language. The beauty of its architecture is that it needs nothing at all! It has three variables called DIRA, INA, OUTA. Period. This simplification cannot be emphazised enough!
The timers/counters are hardly more difficult.Video logic is, though...
The missing interrupt system makes it complient to every language!
Post Edited (deSilva) : 3/2/2008 8:34:22 PM GMT
- Product updates: these will be handled as our current product - you download the latest demo and install.
- Object Exchange: currently our product web pages have lists of sample code projects contributed by users. They send them to us, we upload them. For Propeller, may be we can negotiate with Parallax to use their site, but we will see.
- Programming Propeller C efficiently: the goal is to provide seamless optimal code generation for Standard C. That is, our model is always as much as possible, the users do not worry about the specific device underneath and write programs with the semantic they have in mind and we will do our best. What this translates to on the Propeller C, for example, is that local variables will be allocated to registers automatically and goes to COG RAM stack automatically if not enough register is available, and goes to HUB stack RAM if their addresses are taken or if the variable size is too large. This leaves the programmers to worry about the core programming task and not optimizing by hand.
Of course, this will only staisfy 90%+ of the users, there will be some who want to figure out the best way to write an expression to get the best performance.
I hope this addresses (some of) your questions. From our point of view, as obvious as it is, we enter this market to be successful, make lots of money and retire to Tahiti (*). Will Release One be perfect? No, probably not. You guys are kind of gloomy lot though. What's the point of speculating how far a product can fall, and possibly dragging down Propeller, and by implication, Parallax, will do?
(*) OK< the latter part has not happen yet....
1) A minimum of prior declarations. Too much fol-de-rol at the beginning of a program inhibits "getting down to business" with the coding. Ideally, all variables will auto-vivify, and arrays and strings will automagically grow and shrink as necessary. This, of course, entails dynamic heap management and garbage colleciton, the latter being hypothesized in the forum as too complex to fit a 32K RAM footprint. I'm not sure I agree, since the original 16KB TRS-80 Level II BASIC had garbage collection. Once this teething stage has passed, though, I do believe that enforced declarations — or at least a compiler that flags singular variable instances as possible typos — leads to more reliable code. --C --Spin ++QBASIC ++Perl
2) Weak typing (as a corollary to #1): yes, even autoconversion between strings and numbers, where appropriate. Beginners don't need the additional burden that strong typing forces upon them. --C --Spin --QBASIC ++Perl
3) Simple control structures. REPEAT i from 1 to 10 is simple to understand and easy on the eye. FOR (i = 1; i <= 10; i++) {, on the other hand, is rather more intimidating. --C ++Spin ++QBASIC --Perl
4) No GOTOs. Early encouragement of structured thinking, rather than spaghetti-code thinking, has to be a Good Thing. --C ++Spin --QBASIC --Perl
5) No distinction between "procedures" and "functions". There's no difference. Why complicate matters with an arbtrary distinction? ++C ++Spin --QBASIC ++Perl
6) Simple I/O structures with variable-length argument lists. PRINT and printf are much less burdensome than a multitude of pr.dec(var). ++C --Spin ++Perl ++QBASIC
I'm sure there are others, but these are the first that come to mind. I've yet to see an "ideal" beginner's language.
____________________________
@Richard: Don't be discouraged by any "gloominess" you read in the forum. Your primary market won't be the people who currently haunt its recesses but, rather, those still waiting to discover the Propeller through a familiar paradigm. I wish you success and hope you do get to retire to Tahiti!
-Phil
I do have one question though. I understand that some determinism is lost by going to the LMM but how much? Specifically if I were to run a program like the following:
#include <anything_missing.h> int i; int main(void) { i = 0; for(;;) { outp(ADDRESS, i); i++; delay(ONE_MS); if (i == 0x100) { i = 0; } } return 0; }About how much jitter would I see in the output? I am asking because I have a project in the works that reads a serial data stream at a reasonably slow rate (10.4kbps) but has an utterly bizarre waveform which requires close timing accuracy to parse correctly. I realize an accurate number is impossible but a ballpark estimate would be great. Thanks again for the work you are doing for us and I am looking forward to your product.
It was good to hear from you. I am very encouraged by what you said and look forward to my contribution to your trip to Tahiti. My apologies for being a " gloomy gus " about your effort and henceforth my thoughts will only be directed at meeting you in heaven.
Jim
Yeah I would certainly use a counter or timer in the delay() routine rather than relying on processor speed (I've written too many PC programs to do it that way
Regarding C vs. Spin, I don't think I'd shell out $ for a C compiler, but I know a lot of people that would. For example, a friend that's in mechanical engineering has a project that requires a microcontroller, but he isn't really interested in learning more than what's necessary to get the job done. Since he already knew C (and barely; no pointers or structs, etc) he's using a PIC16 with a CCS C compiler. He also likes the whole IDE point and click thing. I think most people who'd rather use the C compiler than SPIN/Assembly are like that, and not really that interested in all the optimizations and standard compliance.