On 2/20/2016 4:08 AM, Bernd Edlinger wrote:
Sorry, but I don't like this example at all.
First the new example is essentially academic and useless,
When used within a function, basic asm:
- causes difficulties for optimizers
- produces incompatibilities with other compilers
- has semantics that are the opposite of what users expect
- may soon produce incompatibilities with other versions of gcc
Given all this, why would we want our sample to show using basic asm
within a function (as you are suggesting) instead of working to
discourage it?
Contrawise, even people who are advocating for the deprecation/removal
of basic asm (like me) acknowledge that it is needed for top level.
That is why I use it for the sample. I suppose I could grab some actual
top level code from the linux source (like ".symver
__netf2_compat,__netf2@GCC_3.0"). But while it's real-world instead of
"academic," it's also not as clear as I'd like for a sample.
Obviously this testme code isn't going to be placed verbatim in
someone's project. However, if someone wants to use asm macros (a
plausible if uncommon case), this sample shows them how, using a simple,
easy-to-understand (if not particularly useful) method.
In contrast, the "int $3" you seem to favor doesn't really show anything
(even how to do multiple lines). And worse, Jeff's plan is to change
basic asm statements so they clobber ALL registers plus memory. Even a
trivial example shows how this results in gcc generating completely
different code around an "int $3." Which makes it rather problematical
for debugging (can you say heisenbug?), which is the primary use for int 3.
while the previous example could well be used
in real world code, except we could note here
that we also have a __builtin_trap () now.
After reading the documentation for __builtin_trap, I still have
absolutely no idea what it does. Worse, after NOT saying precisely what
it does on any given platform, the docs make it clear that whatever it
does isn't fixed and can change at any time.
I'm a big believer in using builtins instead of inline asm. But based
on these docs, I can't ever see using __builtin_trap myself.
Second if you don't mention that "cc" is already implicitly
clobbered by default, and if it is written here it is ignored
on i386 targets, then everybody will hurry to modify their
asm code when there is no real reason for that.
The meaning of the "cc" clobber is defined under extended asm. The
usage in this sample is consistent with that definition. In the
(unlikely) event that "everybody" decides to change their code, they
will all have (slightly) better documented code which is written in
accordance with the docs. And which behaves precisely the same as what
they have now.
So now what? I have one Bernd who likes the sample, and one who
doesn't. Obviously I think what I'm proposing is better than what's
there now and I've done my best to say why. But me believing it to be
better doesn't get anything checked in.
What will?
dw
