From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: inefficiency of GCC output code & -O problem Date: 17 Apr 2000 10:30:35 GMT Organization: Aachen University of Technology (RWTH) Lines: 80 Message-ID: <8dep4b$g5f$1@nets3.rz.RWTH-Aachen.DE> References: <38F6137B DOT 47481761 AT mtu-net DOT ru> <8d76dk$dg5$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <38F74CD0 DOT 6987E15A AT mtu-net DOT ru> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 955967435 16559 137.226.32.75 (17 Apr 2000 10:30:35 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 17 Apr 2000 10:30:35 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Alexei A. Frounze wrote: > Hans-Bernhard Broeker wrote: >> Technically spoken, I think we're in the regime of 'undefined >> behaviour', here, i.e. with your example code, absolutely anything can >> happen, from 'it works as expected' all the way to a crash of the >> compiler, or even worse things. > Okay, I mean exactly what you talk here. But why "undefined"??? > Compiler must have difined behaviour or a list of *different valid* > ways that get you to the target. I'm simply disappointed because of > this behaviour. The root of this particular problem is that to detect the inconsistency in your code, the compiler would have to read and understand your assembly code, to quite some extent. It'd have to know that some of the references allowed by the "g" constraint don't work if you add a pair of parentheses around the %0 in the assembly. It'd have to check alternatives it doesn't actually use, in the current compilation. To do all that, big parts of the assembler would have to be duplicated/integrated into the compiler. I don't think the resulting additional code checking capability would be worth that much code bloat. 'Undefined behaviour' is a fact of life, in all programming languages powerful enough to be useful. In particular if low-level details are allowed, like pointers or assembly opcodes. There are cases where no compiler can possibly detect that something forbidden may happen, when that compiled code is executed. Alan Turing proved that long ago (--> the 'halting problem'). > I've never had such problems with other compilers (Borland Pascal/C, > Warcom C). Borland Pascal and C are notorious for their buggy optimizers even without adding inline assembly to the picture. Due to the fact that they do not support any of the 'extended' part of GCC inline assembly, they have to effectively switch off all optimization across any block of inline assembly, or chaos breaks loose. Sometimes, I heard, it does in spite of all those measures. Watcom seems to have inline assembly of comparable power as found in GCC. There, you also get the opportunity to tell the compiler about what that code did, to registers and memory content. At least that's what it looked like in short samples I've seen, in this and other newsgroups. I'm not sure if it also supports loading C variable contents into registers, automatically, though. > Simply don't get me wrong. GCC inline assembly seems the most > unusual thing for me. And running into the "undefined behaviour" > problems is shocking. It's not that shocking if you consider the way GCC works, and read the docs before starting to use a new feature. A compiler that translates from C (or one of the other support frontends) to an intermediate 'pseudo machine language', optimizes based on that, and only shortly before finalization translates the result into the actual asm language of the target hardware will always have some small deficiencies compared to a 'native' compiler. Inline assembly code fits into this procedure quite badly. I actually find the extent to which it *is* supported by GCC quite astonishing. Your point of view seems to be underestimating the stress you're already putting on GCC. Eli Zaretskii correctly pointed out that 'extended' inline asm is actually lacking good documentation. This just may be the GCC makers' way of putting a warning hint 'Here Be Dragons --- proceed at your own risk' across this particular region of GCC's feature space. GCC itself has no way of providing expert help, in this area, so the programmer must be an expert. I fully second the notion expressed by others in this thread: inline assembly is a powerful tool. But like with every powerful tool, it requires some advanced handling skill, lest you shoot yourself in the foot with it. And sometimes, you'll shoot yourself in the foot even though your *know* how to work with that tool. That's why even expert workers still wear their hard shoes and helmets. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.