Mail Archives: djgpp/2000/04/17/07:56:00
Alexei A. Frounze <alex DOT fru AT mtu-net DOT ru> 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.
- Raw text -