Re: Asm programming capability?

On Jun 10, 3:19 pm, "cr88192" <cr88...@xxxxxxxxxxx> wrote:
"Antoninus Twink" <nos...@xxxxxxxxxxxxxx> wrote in message

news:slrnh30976.2lk.nospam@xxxxxxxxxxxxxxxxx

On 10 Jun 2009 at 17:47, cr88192 wrote:
inline asm is less of a hassle than external ASM, but then it is compiler
specific (and, in the GCC case, forces use of GAS syntax, ...).

To be honest, that one seemingly trivial difference is enough to make me
use externally assembled asm on the rare occasions I need it. Though I
vaguely remember reading somewhere that gcc is doing an increasingly
good job of accepting Intel syntax - I don't know if it's reached the
stage of being really usable yet?

I hadn't heard of it, I may go look into this...

now, if gcc's inline assembler was like Borland's or Microsoft's
inline ASM (AKA: much nicer looking, and Intel syntax), I would
probably use inline ASM...

Exactly. Not one of the GNU folks' better design decisions IMO.

yep...

oddly, my compiler doesn't really support inline ASM at present...
then again, if it did, I would probably use the Borland or MS style...

Inline assembly is (IMO) a pretty bad idea in general.

consider:
_asm mov ax, 0xf ; move 15 into the AX register of our 8086

....

_asm mov eax, 0xf; move 15 into the EAX register of our P4

....

_asm mov rax, 0xf; move 15 into the RAX register of our AMD 64

You will notice something strange about the above instructions which
all accomplish the same purpose. The names of the registers have
changed over time. So assembly code ages until it becomes useless.
Back in the bad old days, we had to calculate segments and offsets to
make an address. Now we have easier ways due to the larger address
space. So the techniques change over time. Also, the clever things
like XOR ax,ax to put a zero in ax fastest are not as clever as they
used to be since mov rax,0 is just as good now-days. And the
registers also widen over time. The ax register only held 16 bits.

In short, inline assembly is a mistake. It will obsolete your code
totally in a few years. And when the new whiz-bang chip comes out,
you will be doing a full rewrite.

Once in a great while, it is an evil necessity. But most of the time,
it is a choice you will rue in a few years if you decide to do it now.

IMO-YMMV

.

Relevant Pages

  • [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact
    ... gcc _does_ have a perfectly fine notion of how heavy-weight ... an "asm" statement is: just count it as a single instruction (and count ... I doubt that it's the inline asm that was the biggest reason ... size increase/decrease of the core kernel, ...
    (Linux-Kernel)
  • Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning
    ... I just ran a sample build for x86-64 with gcc 4.3.0, ... As shown by the delta from Andi's patch, ... inline a higher level of inline functions for the same bogus reason. ... weight of the asm statement... ...
    (Linux-Kernel)
  • Re: [PATCH] serial/8250: fix uninitialized warnings
    ... GCC considers no-return) or explicitly (if the arch uses inline ... asm or the generic bug.h code) ...
    (Linux-Kernel)
  • Re: [PATCH] x86: fix inline assembly constraints
    ... static inline void atomic_add ... You never know when you're going to trigger a new bug in some ... sometimes gcc did have bugs with its obscure inline asm ...
    (Linux-Kernel)
  • Re: asm volatile
    ... I was wondering what does "asm volatile" do. ... Anyway, it tells the compiler to not move things around, inline, loop-unroll, optimize or even remove the code. ... It basically tells GCC not even try to think about what the ASM code does and what the side-effects are. ... First: If you write inline asm-code in gcc and don't get the constraints right (no shame - it's a horrible syntax) or 2nd: You simply don't have no visible side-effects because you talk to some kind of memory mapped IO or special registers GCC has no idea about. ...
    (comp.arch.embedded)