I can wholeheartedly support Mike's comments on professional programmers. Sometimes you just can't get away from assembly language. I would go further and say that there is not a single object that I've used from the object exchange without modifying in some way - or even just using as a tutorial and then doing a complete re-write - eg my MCP3208 object does multi-sampling and custom filtering without any interaction from Spin and I trimmed out the DAC outputs. If you're going to sell products/code "professionally", then the buck stops with you and you have to know how to fix it if it breaks.
One thing I've discovered about code-reuse is that for me it just simply doesn't happen when it comes to "embedded" products. When writing Windows applications (and I'm sure it's the same for Linux and MAC) you *have* to use third party libraries - the Windows API is by definition third party, but there are also many visual components that you simply can't avoid (eg. OpenGL). But, embedded systems tend to be small and have a certain level of uniquenes from product to product. I must admit that these days many engineers put "embedded" and "linux" together, but the Propeller 1 is several levels of "smallness" down from that.
I've been programming in C since the early 90's, and have done so on multiple processors. Since then I've also used Pascal/Delphi, Forth, multiple flavours of assembler (6 at least), and C# (for my modifcations to GEAR). Spin is great glue for tying processes together - just a little slow - but very similar to Pascal/C (aside from oddities like <= vs =<).
I guess what I'd like to know is: What do all those mythical pre-existing C files do that you want to include on the Propeller? Is it that some of them will never appear on Propeller 1 simply because they're too big - eg Linux. Or, if you had a look in the object exchange would you find that most of what you need has already been written?
I suspect that C is demanded by managers who understand catch phrases like "industry standard", but that doesn't make it the definitively correct answer!
I think the C compiler will find it's own niche, but I suspect the majority of Propeller programming will continue to use the wealth of spin + propeller assembly knowledge that's available.
> re: But this is not sufficient in my opinion. It would be better if I could compile e.g. a whole file (a driver or something else)for the use in "COG" without overhead of LMM.
> It would be possible to load this assembler code then also from an external memory (e.g.SD-card) what frees up some memory in HUB.
First of all, drivers can be written in asm language and they do not have the LMM overhead. Second, to have non-LMM C, it will requires more or less a different backend and the biggest issue may be how to support function calls. The PASM CALL does not use a call stack, and this will not do for C recursive function, for example. So now we will need to make some tradeoffs.
My guess is that we will support "small model" native C at some points, but lets finish FP support first.
BTW, I beg to differ on code reuse in embedded projects. We probably have more commercial embedded C users than other compilers and code reuse is definitely not a myth amongst our customers, and yes these are 8 and 16 bits micrcocontroller users.
Code reuse is a myth ... if you don't design for it, if you intentionally re-invent to keep products maintainable by newer generations, if you are just too stubborn to accept someone else's way of doing things, or just like puzzles.
First off all, I don't want to bother the assembler-users. Keep cool! Don't beat me .
There are certainly projects where you have to program in assembler, because you can't (or don't want) for a reason take a faster microcontroller (or maybe there is no faster).
In our company in thousands of code-lines there are only a few in assembler (e.g. "put the controller in sleepmode" or something like that hardware specific thing). And yes we use until now only 8-Bit or 16-Bit Controller (@4-16MHz).Anyway far away from linux or windows.
Subject code reuse:
If you have a long term product-line with different devices but similar/same funcionality (some with graphic display others with 7-Segment or without display, with or without RS232, 100 or only 1 input/output, small cheap controller or bigger one...),
there is much code that is in every device the same, written in C, because you need only to recompile it (For example a driver for an ADC or special string-formatting routines, because printf is to big.....).
The object exchange for propeller is good for private use or for learning. Except maybe the code from parallax (Chip Gracey..) you can't trust it. You have to look over it, change things... So you have to use or write your own code.
With C your much more open for a new controller without "reinventing the wheel". Thats my opinion. Have not to be yours.
And maybe the propeller is simply not the right microcontroller for me.
@richard
Functions could be automatically "inline", if used. But you're the specialist and you have to decide what you can do or what you want to do (first).
dnalor mentions "inline" ... I seriously miss inline functions in ICC mainly because of normal function overhead. Perhaps that is not part of the C89 standard?
That's correct. inline is not part of the C8x standard. Moreover, it's actually pretty difficult todo an efficient job. There is quite a bit of pull from customers to have it though so I will probably look for a solution.
It'd be fair to say that C use and professional use go together. Secondary schools are going to be more than happy with teaching Spin and nothing more. And the hobbyists are mostly, for the moment, happy with Spin+Asm.
The next question is how many professional developers have reeled in the Prop and been pumping out the projects?
The main thing holding me back from buying ICC for the Propeller immediately is the lack of a debugger. Even that lack probably won't stop me from buying it soon, I'm just starting to use the trial now.
The second biggest concern I have is about code size. I've seen a couple mentions of it not being very good yet on that front. I think those two things should be top priorities. In fact, in the case of this small environment, I am more concerned about the code generation being compact than I am about it being the fastest it can be... Sure I want it fast but not to the point of being so large it's useless.
I don't need FP in this environment, and could care less about it being added at all, let alone soon. It's very unlikely that it would not be fast enough to be usable for anything I would want it for anyway. I'm just fine with integer and fixed point math.
I'm a professional programmer and I use C/C++ all day every day, and I want a good C compiler on the Propeller.
Certainly don't need a debugger. The Propeller is so direct and simple that setting up a debugger is no help imho. An assembly dump, if you are suspicious of the resulting compiled output, and some decent hand coded diagnostics is all you should need in this sort of system.
1. Enable novice programmers get a feel of code operation.
2. Ability for anyone to verify function of new code by tracing behaviour (professional unit testing).
3. Ability to decode quickly what caused a "core dump" in a complicated system.
4. Provide entertaining threads of discussion in forums, but are never debated professional settings [noparse]:)[/noparse]
A debate of this is not healthy. The debuger usefulness thread I was involved in resulted in a virtual fist-fight. Then later I saw an earlier post of the same appeal for a debugger from a primary antagonist (very entertaining to discover such hypocrisy).
I believe Jazzed is right; arguing for or against debuggers, debating whether essential or not, is fairly fruitless. Those who want or need them want or need them, those who don't don't. It's a simple personal preference, as is what level of debugging capability is desired. Some people prefer to liberally litter their code with 'printf' others prefer source stepping through debuggers.
There is no ICC debugger at present but I am sure one will arrive with the fullness of time.
My personal opinion is that lack of C didn't stop me using the Propeller and lack of an ICC debugger wouldn't stop me using ImageCraft C. Others may, and probably do, feel differently.
Ok, I'll drop any further debate about debuggers here.
I do want to clarify to ImageCraft that I am grateful for their work so far and look forward to future additions. I do not want to come off as all negative here. I mainly just wanted to convey my concerns with the product and it's future development.
Welcome to this community ... take your shoes of and stay a while. Hope you're not discouraged from participating. I would love to see more C source contributions; hopefully you and others can add to the libraries. There are many things left to do.
@ Roy : I hope comments about the 'futility of discussing debuggers' didn't feel directed at you as that wasn't intended.
I'm sure everyone ( certainly the manufacturers ) will be interested in hearing your personal opinion on what's good or bad and your commenting on the lack of a tool and how it affects your usage / purchasing decision was completely valid. It is the associated debate about whether debuggers ( or anything else a particular user might desire ) are needed and their merit which doesn't usually go anywhere IMO.
Yes, I welcome any suggestions. No fist fight though, please
re: debuggers
As mentioned in another thread, I am trying to entice the NoICE author to support the Propeller. Stay tuned.
re: code size
We may address it in different fronts, all are speculations for now:
- Once we have FP in, we may have a little more leeway in lessening the restrictions on the code size on the non-commercial use version.
- I am hoping that we can come up with a "C stamp" solution, and provide a single module with the Propeller and a large amount of data flash or something, so that programs can be as large as the external device. The compiler has no problem supporting this, but we need a fast method of fetching the code.
- Remember that the code size issue is not a C issue per se. We are effectively generating native Propeller instructions so you are seeing the code "bloat" of a 32-bits instruction set. So another possibility is that we can generate bytecode, or 16 bits LMM code, etc. at the cost of a) slower execution, and b) yet another "asm" language for the metal-to-the-floor super users and debugger users.
I am really hoping someone can solve the bandwidth issue of fetching instructions from external device though....
- I am hoping that we can come up with a "C stamp" solution, and provide a single module with the Propeller and a large amount of data flash or something, so that programs can be as large as the external device. The compiler has no problem supporting this, but we need a fast method of fetching the code.
Hey! Steal my thunder! ··:P:P ...·Not mine really, but I'm certainly working on an external execution memory engine.
With 8 flash devices for 16MB memory or EEPROM for 128/512KB memory at·~5.2Mbyte/sec or ~1.3MIPS·of LMM with ~4 SOT8 per square inch, a big "C-prop" or whatever may be possible in a 28 pin DIP package (~10 IO required for 8 devices allows 22 user port bits). Of course the boot EEPROM would also be necessary, but the EEPROM pins could be brought out for user device sharing as could the serial pins, reset, and·brownout. Check my numbers·please.
re: Jazzed
Sorry Someone alerted me to the Hydra HX512 RAM board that can do read almost as fast a Hub read. Only problem I see is the cost ($60!). I think a "stamp" with 128K/512K would be sufficient for most people's need. Certainly it will make the Propeller more appealing for certain people, I think....
ImageCraft said...
re: Jazzed
Sorry Someone alerted me to the Hydra HX512 RAM board that can do read almost as fast a Hub read. Only problem I see is the cost ($60!). I think a "stamp" with 128K/512K would be sufficient for most people's need. Certainly it will make the Propeller more appealing for certain people, I think....
I have one of those, but it is not a fast random access device; it·is a fast sequential block device. There is little difference in price between a 16MB serial flash configuration and a 512KB serial EEPROM configuration, and you can use the same FAB for both products. It's just a matter of software [noparse]:)[/noparse]
BTW, I beg to differ on code reuse in embedded projects. We probably have more commercial embedded C users than other compilers and code reuse is definitely not a myth amongst our customers, and yes these are 8 and 16 bits micrcocontroller users.
I have emailed the NoIce folks regarding support for the Propeller and ICC.
In the mean time, I am am looking at doing some form of simple debugger using the method you outlined in another thread. ( DIY ImageCraft C Debugger...·http://forums.parallax.com/showthread.php?p=746581·)
The finit and clibinterface functions are in the address range from 0x110 to 0x12E.
The FCACHE code uses 0x110 to 0x130 as it's buffer for placing code to run. Overlapping this space.
This is fine for the finit function since it's never run after first startup, so it's safe to smash.
However the clibinterface code which starts at 0x11F could be smashed by and FCACHE, and that doesn't seem like a good idea.
Perhaps I am missing something? Is this clibinterface code copied someplace else? (doesn't look like it) The comment right about the clibinterface: line says that it's at 0x1EE, but it's not.
Comments
One thing I've discovered about code-reuse is that for me it just simply doesn't happen when it comes to "embedded" products. When writing Windows applications (and I'm sure it's the same for Linux and MAC) you *have* to use third party libraries - the Windows API is by definition third party, but there are also many visual components that you simply can't avoid (eg. OpenGL). But, embedded systems tend to be small and have a certain level of uniquenes from product to product. I must admit that these days many engineers put "embedded" and "linux" together, but the Propeller 1 is several levels of "smallness" down from that.
I've been programming in C since the early 90's, and have done so on multiple processors. Since then I've also used Pascal/Delphi, Forth, multiple flavours of assembler (6 at least), and C# (for my modifcations to GEAR). Spin is great glue for tying processes together - just a little slow - but very similar to Pascal/C (aside from oddities like <= vs =<).
I guess what I'd like to know is: What do all those mythical pre-existing C files do that you want to include on the Propeller? Is it that some of them will never appear on Propeller 1 simply because they're too big - eg Linux. Or, if you had a look in the object exchange would you find that most of what you need has already been written?
I suspect that C is demanded by managers who understand catch phrases like "industry standard", but that doesn't make it the definitively correct answer!
I think the C compiler will find it's own niche, but I suspect the majority of Propeller programming will continue to use the wealth of spin + propeller assembly knowledge that's available.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's automatic: if you have a small enough loop, it will be put that. e.g.
; for (n = 0; n < 10; n++)
mov R5,#0
@FCACHE
L2:
.dbline 9
; i += i;
mov R15,R4
add R15,R4
mov R4,R15
L3:
.dbline 8
add R5,#1
.dbline 8
cmps R5,#10 WC
IF_B jmp #L2
@FNEXT
.long 0
The cache size is currently fixed at 0x20 longs.
> re: But this is not sufficient in my opinion. It would be better if I could compile e.g. a whole file (a driver or something else)for the use in "COG" without overhead of LMM.
> It would be possible to load this assembler code then also from an external memory (e.g.SD-card) what frees up some memory in HUB.
First of all, drivers can be written in asm language and they do not have the LMM overhead. Second, to have non-LMM C, it will requires more or less a different backend and the biggest issue may be how to support function calls. The PASM CALL does not use a call stack, and this will not do for C recursive function, for example. So now we will need to make some tradeoffs.
My guess is that we will support "small model" native C at some points, but lets finish FP support first.
// richard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
There are certainly projects where you have to program in assembler, because you can't (or don't want) for a reason take a faster microcontroller (or maybe there is no faster).
In our company in thousands of code-lines there are only a few in assembler (e.g. "put the controller in sleepmode" or something like that hardware specific thing). And yes we use until now only 8-Bit or 16-Bit Controller (@4-16MHz).Anyway far away from linux or windows.
Subject code reuse:
If you have a long term product-line with different devices but similar/same funcionality (some with graphic display others with 7-Segment or without display, with or without RS232, 100 or only 1 input/output, small cheap controller or bigger one...),
there is much code that is in every device the same, written in C, because you need only to recompile it (For example a driver for an ADC or special string-formatting routines, because printf is to big.....).
The object exchange for propeller is good for private use or for learning. Except maybe the code from parallax (Chip Gracey..) you can't trust it. You have to look over it, change things... So you have to use or write your own code.
With C your much more open for a new controller without "reinventing the wheel". Thats my opinion. Have not to be yours.
And maybe the propeller is simply not the right microcontroller for me.
@richard
Functions could be automatically "inline", if used. But you're the specialist and you have to decide what you can do or what you want to do (first).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
The next question is how many professional developers have reeled in the Prop and been pumping out the projects?
And for many micros its about the only HLL outside of BASIC available.
The second biggest concern I have is about code size. I've seen a couple mentions of it not being very good yet on that front. I think those two things should be top priorities. In fact, in the case of this small environment, I am more concerned about the code generation being compact than I am about it being the fastest it can be... Sure I want it fast but not to the point of being so large it's useless.
I don't need FP in this environment, and could care less about it being added at all, let alone soon. It's very unlikely that it would not be fast enough to be usable for anything I would want it for anyway. I'm just fine with integer and fixed point math.
I'm a professional programmer and I use C/C++ all day every day, and I want a good C compiler on the Propeller.
1. Enable novice programmers get a feel of code operation.
2. Ability for anyone to verify function of new code by tracing behaviour (professional unit testing).
3. Ability to decode quickly what caused a "core dump" in a complicated system.
4. Provide entertaining threads of discussion in forums, but are never debated professional settings [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
I can't stand not having a debugger. They save so much time and frustration.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
There is no ICC debugger at present but I am sure one will arrive with the fullness of time.
My personal opinion is that lack of C didn't stop me using the Propeller and lack of an ICC debugger wouldn't stop me using ImageCraft C. Others may, and probably do, feel differently.
I do want to clarify to ImageCraft that I am grateful for their work so far and look forward to future additions. I do not want to come off as all negative here. I mainly just wanted to convey my concerns with the product and it's future development.
Roy
Welcome to this community ... take your shoes of and stay a while. Hope you're not discouraged from participating. I would love to see more C source contributions; hopefully you and others can add to the libraries. There are many things left to do.
C-ya.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
I'm sure everyone ( certainly the manufacturers ) will be interested in hearing your personal opinion on what's good or bad and your commenting on the lack of a tool and how it affects your usage / purchasing decision was completely valid. It is the associated debate about whether debuggers ( or anything else a particular user might desire ) are needed and their merit which doesn't usually go anywhere IMO.
re: debuggers
As mentioned in another thread, I am trying to entice the NoICE author to support the Propeller. Stay tuned.
re: code size
We may address it in different fronts, all are speculations for now:
- Once we have FP in, we may have a little more leeway in lessening the restrictions on the code size on the non-commercial use version.
- I am hoping that we can come up with a "C stamp" solution, and provide a single module with the Propeller and a large amount of data flash or something, so that programs can be as large as the external device. The compiler has no problem supporting this, but we need a fast method of fetching the code.
- Remember that the code size issue is not a C issue per se. We are effectively generating native Propeller instructions so you are seeing the code "bloat" of a 32-bits instruction set. So another possibility is that we can generate bytecode, or 16 bits LMM code, etc. at the cost of a) slower execution, and b) yet another "asm" language for the metal-to-the-floor super users and debugger users.
I am really hoping someone can solve the bandwidth issue of fetching instructions from external device though....
Hey! Steal my thunder! ·
Timmoore has demonstrated a 4 device I2C interface that gives about·"~2.6Mbyte/sec" throughput. See http://forums.parallax.com/showthread.php?p=737981
With 8 flash devices for 16MB memory or EEPROM for 128/512KB memory at·~5.2Mbyte/sec or ~1.3MIPS·of LMM with ~4 SOT8 per square inch, a big "C-prop" or whatever may be possible in a 28 pin DIP package (~10 IO required for 8 devices allows 22 user port bits). Of course the boot EEPROM would also be necessary, but the EEPROM pins could be brought out for user device sharing as could the serial pins, reset, and·brownout. Check my numbers·please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Sorry
Email the NoICE people to express your support!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Hi Richard I agree with you on that.
Cheers
PS I sent to NoIce about Prop support.
In the mean time, I am am looking at doing some form of simple debugger using the method you outlined in another thread. ( DIY ImageCraft C Debugger...·http://forums.parallax.com/showthread.php?p=746581·)
Roy
The finit and clibinterface functions are in the address range from 0x110 to 0x12E.
The FCACHE code uses 0x110 to 0x130 as it's buffer for placing code to run. Overlapping this space.
This is fine for the finit function since it's never run after first startup, so it's safe to smash.
However the clibinterface code which starts at 0x11F could be smashed by and FCACHE, and that doesn't seem like a good idea.
Perhaps I am missing something? Is this clibinterface code copied someplace else? (doesn't look like it) The comment right about the clibinterface: line says that it's at 0x1EE, but it's not.