William "Chops" Westfield mac.com> writes: > On Mar 12, 2007, at 5:39 AM, Peter P. wrote: > > > After all, compiler output *IS* machine code written using code > > generators made and optimized by expert assembly programmers. > > Um. Maybe. Too often compilers are written by compiler experts who > AREN'T experts in the assembly language of the target processor. My > university compiler class included only a tiny bit about code > generation, > and most of that was aimed at a "theoretical" machine. (I wasn't very > impressed, being an assembly programmer at the time.) The 'Dragon' book ('Compilers' - Aho, Sethi, Ullmann), which is supposedly about compiler writing (and a standard university text for that) is so abstract that one needs 2-3 additional books to be able to complete a simple compiler based on it. The 'Interpretation of Computer Languages' (Abelman etc - the LISP book) has a similar problem, excepting for the fact that LISP is interpreted so there is a little bit of code to work with. University does not teach practical things (notice that I do not have a degree ...). Not so long ago universities were extremely proud of that, too. And I don't think that they got over it completely. Not that they intend to (except for show, to please the carreer needs of students - I am joking of course. I never saw such an attitude. But I am a terrible liar.). > Likewise, > witness how poorly the gcc "intermediate code" matches the architecture > of many common microcontrollers, for instance. And We're not talking > about the modern set of micros designed with compiler optimization of > branch delay slots and cache handling in mind; we're talking about > quirky microcontrollers with instruction sets from the dark ages. gcc and sdcc are free compilers whose most important merits are that they exist, and that they seem to support large projects using them. That's a lot for free tools. They also set the entry level requirements for commercial tools imho. Charging any money for anything that does less than those two is cheeky imho, and whenever I compare features on some commercial tools I use this benchmark too. There are also other compilers that set the level, like that CP/M C compiler that was released free recently. > >> No compiler will ever be as code-space and/or speed efficient > >> as a good assembler programmer > > > > I think that this is a myth. > > > Nah, it's just not a complete statement. A good assembly programmer > can match even the best compiler, but a good assembly programmer would > be a fool to apply that level of effort to an entire large-ish program, > while the compiler can do so effortlessly. OTOH, a compiler is likely Yes, exactly. And for this, it is best if the assembly programmer writes everything in C and only puts in a function or two in optimized inline or standalone assembly where it matters, and spends the time well polishing that. Several successfull products are written like that, including high speed device drivers, the Linux kernel and others like this. And I try to do it like that when some piece of C is too slow or too large. > to throw away all its supposed space gains by including some massive > library that it needs a tiny piece from. There are things that are Yes but that is not so true for embedded. Most embedded projects use 'leaned' C libraries which contain extra small functions precisely for this reason. Also oftentimes embedded libraries are partially rewritten for the same reason. E.g. leaned printf() and scanf() (if used at all) are very very common, and so are some math function implementations which do not consume huge amounts of space and time. > easy for an assembly language programmer to do, common in embedded > microcontrollers, that are very difficult for a compiler to match > simply because of requirements of the language. Mixed size math (add > 8 bits to a 16bit quantity. A C compiler could do this, but it's NOT I don't think that that is a good example. Things like mixed size math usually don't occur in programs written top down, and putting in an explicit cast at the right place in the source should cause the compiler to issue a single, efficient, sign-extending shift at the right place. > the way that C is defined to work.) Explicit use of the carry bit. I think that there are ways to write code such that the gains of 'carry-bit-using' optimizations which cannot be used with C are compensated for. > Compilers tend to be designed to support and optimize certain classes > of program, and alas embedded applications are seldom among them. > (that's for "generic" compiler technology. And "computer science" > as applied to compilers. And education. It's certainly possible > that any given vendor has managed to figure out how to optimize > embedded applications on "typical" microcontrollers and does a very > good job. But I've seem enough compilers do enough stupid things on > enough targets that I don't trust this supposed "super optimization" > will happen very often. I am not sure whether vendors are the manufacturers of the best compilers. Vendors sell silicon first, and unoptimized compilers sell more silicon. This is a little evil to say but it's true. The only push factor is competition, in the form of a better compiler supplied by a competing vendor, or by a free compiler (like sdcc or gcc) which would make the vendor's tools look bad if they would not be able to do more than them. F.ex. I have difficulty to understand vendors who make Windows-only tools (which often have a cheezy look+feel), and sometimes even want money for them. Peter P. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist