Are there any 8051 C++ compilers ?

Not in this country. If you are a smaller fish, then you have to stick to the letter of a contract. If the contract is vague and contradictory, then it just means that one has to keep changing the product and spec until they have something completely different from what they asked for initially. The biggest problem with these specs, is that they do not contain the actual requirements. They contain somebodies half baked thoughts on what they think the solution to their problem is. Add some current buzzwords to the mix, and you have --- "The perfect specification".

If you are a bigger fish, then such a contract is quite nice. The legal department should then be twice the size of the engineering department of course. The only problem with this, is that engineering will still have the sort end of the stick.

Regards Anton Erasmus

Reply to
Anton Erasmus
Loading thread data ...

Most of the people I end up helping with their systems were much happier and productive with programs like Wordperfect for DOS than they are with MS Office XP. People who were quite productive with the former, only needed help when the hardware failed, now asks for assistance quite frequently. They also needed to upgrade their hardware to something at least 10x faster with the end result an overall less reliable and slower system. These people only use the new stuff because they do not percieve an alternative.

Regards Anton Erasmus

Reply to
Anton Erasmus

Ahem. Linux does not give userland tasks IOPL by default. Therefore, it requires me to jump through at least one hoop, no matter how large, well-illuminated and conveniently close to the ground that hoop might be. And I hope now you won't be telling me that Linux has the same potential for realtimeness as, say, DOS?

I was quite careful in my choice of where I said "current operating systems" (Note my qualifier of "mostly"). The only place where I think I should have added "mostly" or "in the main" is the one part I've requoted above.

Reply to
Lewin Edwards

... snip ...

Harrumph - try WordStar under CP/M.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

Jonathan Kirwan wrote

In

know

will

that

taken

Odd. My impression was that with the exception of old GCCs, all C++ compilers avoids laying down storage for simple consts, such as

const int a = 7;

Even the first C++ compiler, Cfront, did that 20 years ago.

-- Bjarne Stroustrup;

formatting link

Reply to
Bjarne Stroustrup

Richard Pennington wrote

Just a historical detail. const - with its current semantics - was introduced into C++ well before the C committee added a const with different, and less useful, semantics. Maybe the C committee should have decided on compatibility or used a different syntax to avoid unnecessary confusion with C++.

Yes. That would be very nice. See

formatting link

You might like to consider the ISO C++ committee's technical report on performance issues. It addresses a lot of issues related to embedded systems:

formatting link

-- Bjarne Stroustrup;

formatting link

Reply to
Bjarne Stroustrup

Bjarne Stroustrup wrote: [snip]

I wish I had been more aware of that process as it was going on. I was completely stuck in C at that time.

Thanks for reminding me of that. I'd read that before and completely agree, obviously.

Thanks for pointing that out, I hadn't seen it before.

It's kind of funny how much resistance to change I've seen during my career. I started out writing C compilers for 8 bit micros in the '80s. At that time "everyone" was certain that C could never replace assembly in those applications. I think it took several years, as new graduates got into the swing of things, before C became readily acceptable.

One ramification of that change was that technical support questions changed. A typical question originally was "How can I determine my maximum stack usage?" This question morphed over time into a long discussion that, in the middle, after asking the user about their stack usage, resulted in the question "What is a stack?"

For the last many years that battle has become C vs. C++. It is still raging. I currently work for a large medical equipment company. We are just now starting to use C++ extensively for embedded development. It took a long time before everyone could become comfortable with all of C++'s "hidden overhead". Unfortunately, part of the problem is that many people take the hidden overhead for granted without actually understanding what and where it is.

I have a book (the name of one of the authors is strikingly similar to yours) called "The Annotated C++ Reference Manual" (Ellis and Stroustrup, 1990). I recommend this book to everyone I can because it explains why and how the language works, even down to how a compiler might implement a language feature. An outstanding book for someone wanting to know how C++ works, rather than just how to use C++.

-Rich

--
Richard Pennington
Email: rich@pennware.com
 Click to see the full signature
Reply to
Richard Pennington

In one word -- "no"!

Reply to
Everett M. Greene

Thanks! Very useful document.

--
Guy Macon
Reply to
Guy Macon

They also greatly miss the simple "type the name of the program and hit enter" user interface.

Reply to
Guy Macon

I wouldn't dream of it. I really like using DOS to load an embedded program that takes ofer the computer and runs until someone cuts the power. I also rather like QNX, but for a different class of applications that the ones where I use DOS.

--
Guy Macon
Reply to
Guy Macon

In

know

will

that

taken

That was my impression, too, but I haven't exhaustively tested. For what it's worth, here's what g++ version 3.2.2 did. From this input file:

#include

const int seven = 7; const int eight = 8; const int unused = 99;

int main() { std::cout

Reply to
Ed Beroset

I am surprised to see the 7 and 8 at all - I would have expected the compiler to do compile time computations and have generated load 15. I am not surprised that 99 is missing, it was never used. So I expect your hex dump at 07c0 and 07c2 is of something else, such as symbol tables. Try using objdump -dS

--
"Churchill and Bush can both be considered wartime leaders, just
 as Secretariat and Mr Ed were both horses." -     James Rhodes.
Reply to
CBFalconer

Yes, as I stated above I know the difference between compile-time constants and run-time constants. What I was trying to ask was why and how it was determinted that "C" was the "peculiar" case and "C++" the normal, ordinary case.

--
Grant Edwards                   grante             Yow!  I have many CHARTS
                                  at               and DIAGRAMS...
 Click to see the full signature
Reply to
Grant Edwards

It did load a 15 directly if you examine the assembly version (with my comments added), but it still left the 7 and 8 in a data section.

Since this is data, better is objdump -sx which dumps the contents of each section. Here's the .rodata section:

Contents of section .rodata: 80487a0 03000000 01000200 73657665 6e20706c ........seven pl 80487b0 75732065 69676874 20697320 00000000 us eight is .... 80487c0 07000000 08000000 ........

They're really there. Once again, I should point out that this is with no command line options, so no optimizations are turned on. When I turn on the lowest level of optimization (-O1), they all go away:

Contents of section .rodata: 80487f4 03000000 01000200 73657665 6e20706c ........seven pl 8048804 75732065 69676874 20697320 00 us eight is .

Ed

Reply to
Ed Beroset

Holy Bejasus, if they've got that much money to burn they can get a C++ compiler WRITTEN complete with full documentation hand written by nuns on gazelle skin parchment and illuminated with pretty pictures of all the saints.

Paul Burke

Reply to
Paul Burke

... snip ...

IMO the C version is more useful. You can write a routine that takes a parameter such as:

int foo(const char *bar);

and happily pass it strings (or whatever else via pointers), secure in the knowledge that the item will not be munged (barring evil doings in foo).

The Pascal technique of a CONST section, where all such items can be defined (and are NOT variables) makes more sense then the C++ const to me. It can be simulated with defines.

--
"Churchill and Bush can both be considered wartime leaders, just
 as Secretariat and Mr Ed were both horses." -     James Rhodes.
 Click to see the full signature
Reply to
CBFalconer

While it's certainly true that there are technical differences, in reality a well-written C program will be perfectly good C++, with the same functionality (although the generated code is not guarenteed to be the same). A "perfectly fine C program" will not contain code that relies on "implicit int" declerations, convertions to and from *void should be explicit not implicit, and sizeof('a') is pretty unlikely to turn up in a real program. It is possible to write code that is legal and compiles as C or C++ while having significantly different functionality, but that's more as an accademic exercise.

However, C and C++ are different types of language - just because well-written C programs work fine when compiled with C++ does not mean that sticking to plain C is a good way to write C++ programs.

Reply to
David Brown

I did not say that there has been no progress in the real ease of use and usefulness of applications like word processors. My point is that most of the stuff added with the dominance of Windows has taken up CPU resources without adding much if anything for the typical Word Processor user. The fact that MS Word dominates only exaberates this for in my opinion MS Word is a bad design, badly implemented. With many of the older Word Processors people gradually learned how to do Word Processing - with Word people gradualy learn the short cut keystrokes of Word, they tend to have no concept of the principles they are supposed to use in getting the layout they want etc.

Regards Anton Erasmus

Reply to
Anton Erasmus

Objection, your honour! As I've just explained, well-written C programs don't contain casts of malloc() return values (or of pointers passed to free() into (void *), for that matter), whereas "perfectly good C++" would absolutely have to have those.

No, they shouldn't. As a rule of thumb, well-written C code needs

*no* explicit casts between pointer types at all. In such code, each and every such cast that really has to be spelled has to be accompanied by a serious, in-depth comment explaining why it's needed.

What's worse, there's a good chance that if you get yourself into the habit of writing such casts all over the place, you're going to hide some real mistakes behind that blanket of smoke and mirrors. And it will make code the harder to maintain because explicit references to objects' types are spread in much more places than they have to be.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.