We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I,ve installed the Compiler and I can,t get even the simplest code to compile properely.
Anyone know where the fix for this bug is?
Or is it a limit of the demonstration version?
void main(void) { cout << "Hello world!"; }
As was highlighted to me before on this thread 'if you know C++, then you also know C'. For the most part yes. But for the part that is not... A K&R Book would be handy
That view does appear to be a generally accepted one. Like the world is flat?
I don't think I have ever seen the opposite of that mentioned; i.e., 'if you know C, then you know C++'. I can not argue with you there.
This REALLY does imply to me that C can (for most practical purposes) be viewed as a subset of C++. Only for the most part
The likening of C and C++ to English and American English you suggest are, I think, just plain stupid.
Accents aside, it would be unusual for an American to not understand a Briton or a Briton to not understand an American. I am not sure where you are from. But I as an American who went to England learn there is a little more of a difference then just the accent. They use words we do not. And some with a very different meaning like C / C++
Give a C program to someone who knows C++ - They will probably be able to follow it. True
Give a C++ program to someone who knows C and no C++ - They may well be very confused with the classes, templates, operator overloading etc etc etc. Very True
Since you said you were making goood progress, I asked about a week ago about a comparison between the two tools.
I'm still interested, so I repeat my question:
Which one generates the smallest code, and what processor are you building for?
Genuine interest - Or hope for failure?
Anyway, FYI ...
Building for an 80C535 - With a lot of spare port pins!
I decided to stick with the IAR because I felt that the development environment is more friendly. I cannot therefore give comparisons concerning code size etc.
As it happens, I ended up using a (rather flippant) suggestion from one of the original posters where I split the program into blocks and having indirect entry points (jump tables) to regions of ROM space. The IAR package is good for locating separate blocks of code. Better still, I didn't reach the limits of the demo version - Ha Ha IAR.
This method allowed me to do what I REALLY wanted to do; i.e., make modular self contained units suitable for class abstraction.
The really good news (for me) is that the demo version is now complete and I am expecting to release the final version to the customer next week.
Embedded systems - Not so difficult after all!
I decided to stick with the IAR because I felt that the development environment is more friendly.
That was my impression too, when I worked with both, the CEIBO and the IAR package, but thats certainly a matter of taste.
Better still, I didn't reach the limits of the demo version - Ha Ha IAR.
When I tried the IAR demo version (about two years ago) it came as a full version that was only time limited. I think it could be used for 30 days without any restrictions or at least without any code size limit. Of course one was only allowed to use it for testing purpose, not for developing commercial products?!
I cannot [..] give comparisons concerning code size etc.
But I can. Here are my experiences: The reason for me, to test the IAR compiler was the fact, that the generated code by the CEIBO compiler reached the 64 KB code size limit of the controller I was using these days. In fact I hit the 64 KB limit for the second time. The first time I could bring it down to about half the size by means of optimization, linker code packing and 'tricky' programming techniques that made the CEIBO create smaller code. That left me with about 30KB free code space (that I urgently needed) but also with quite undebuggable code... And after adding some more source code, the code size quickly aimed for the 64 KB again, as the code bloated somehow exponentially (at least that was my impression). So I decided to have the IAR compete against the CEIBO. Adapting the source code from my CEIBO project to the IAR was very easy but the result didn't turn out to be what I was hoping for. CEIBO vs. IAR final result 64 KB to 63 KB. I considered this to be a draw...
My next step was to rewrite the whole stuff in pure C. That took me a while but it was worth it. In 'C only' the code size was less than 30 KB without linker code packing and with an acceptable optimization level! I can't recall all the details as it has been a while ago but that made me ban both, the CEIBO and the IAR to the depths of my harddrive where they lie untouched since that day...
Summary: IMHO C++ on a 80C51 can not be recommended for 'complex' applications. But the only real advantage of C++ on a 80C51 that I see, that is as Filip said make modular self contained units suitable for class abstraction only turns out to be an advantage in complex applications, doesn't it?
Just my two cents...
Carsten
Hi Carsten,
Nice to hear from somebody who's tried something similar :)
Yes, you're right about the IAR demo limitation - It is fully functional but limited to 30 days use and not to be used for commercial applications. Now the demo has been done successfully, I have the funds to buy the full package.
With regards to the Ceibo demo package, I wasn't sure that it was actually using the Keil compiler underneath???
When I looked at the code it produced (i.e., assembler listing files) it seemed more like that of the SDCC package - But I might well be wrong about that.
I would say that the word 'complex' in this environment is a relative term. Fortunately for me, code and data space are decent (512Kb each using banking) and speed is not critical. If the project goes further forward, I would probably recommend a higher speed core (probably Dallas) for the next boards to compensate for the extra overhead of the C++.
I can understand that for more pressured hardware, the use of C++ is probably not the best choice. As for me, I'm glad I pursued it.
Hi Filip,
the CEIBO produces C code from your C++ source for the KEIL compiler. When you install the CEIBO package, you can work from the KEIL IDE writing your program in C++ . When you hit the compile button, the CEIBO makes C code out of your *.cpp files and then hands it over to the KEIL compiler. You never get to see the actual C code.
Well, 'complex' of course was meant with respect to the 8051 environment. With 512 KB of available space, you certainly can handle a lot of C++ overhead. But usually much more code takes much more execution time when running on your system. On the one hand, you state that speed is not critical on the other hand you say that you might need a faster core to compensate... To get the desired performance you have to decide what's the better approach for you. When you are faster in development using C++ you can probably afford a (more expensive) high speed core. But when you're aiming to sell many units of your product, you might better be using C only, even if it takes you longer to write your program. (Of course you could also switch to another core architecture. When the requirement is 'C++ and speed', an 8051 is not necessarily the first thing, to come in mind...)
As usual, there's not always just black and white but for me, C++ is no longer an option in my 8051 applications.
Hmmm ... When I installed the Ceibo demo package it was on a clean PC (i.e., no Keil etc) and the only thing I got was the Ceibo IDE.
I've just looked back in the 'bin' folder and found the givaway SDCC.EXE and SDCCLIB.EXE. No Keil components to be found.
Ok ... I see ... It uses Keil if installed.
On the one hand, you state that speed is not critical on the other hand you say that you might need a faster core to compensate...
Sorry, what I mean is that future requirements for the project might need more processing - That might justify a faster core.
I take your point concerning costs but, fortunately for me here, this project will only ever be small(ish) quantities and the processor etc is not a real issue.
However, that said, I may venture into ARM ;)