Re: Wonly-top-basic-asm

[David Wohlferd <dw@LimeGreenSocks.com>]

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