alexr: you really do need clobbers if you want to use inline supervisor calls. I don’t see any way around it.

Generating object files directly would help somewhat with inline assembler, assuming gcc included an assembler, but it wouldn’t help much otherwise. Several years ago we looked into it, but we realized that it would only help with compile time, and the savings in compile time would be quite small–a couple of percent. The assembler is fast.

I consider clobbers and the other GCC markup to be abhorrent. Everybody gets them wrong. I mean everybody: kernel engineers and GCC committers alike.

It’s way past time for GCC to generate object files directly.

Actually, because of this, I kind of find it amusing that you mention add
with carry instructions, heh.

So you can’t use inline asm to generate condition codes that if
statements act upon, for example. And this leads to a lot of extra
unnecessary code.

it also makes things like extremely space and time efficient assertion
implementations not possible either. We have this macro called BUG_ON()
in the Linux kernel that just traps on a given condition, but with certain config
options enabled it also will provide the source file and line number in the
logs when it triggers.

The most optimal implementation would be a builtin_trap() that allowed
annotations to be assosciated with the trap instruction address. The
power of builtin_trap() is that it is “noreturn”, and also on platforms like
sparc we can use conditional trap instructions. Nearly zero cost assertions
But when you try to use inline asm to add instruction pointer based annotations
you can’t do anything sane because getting at the condition codes calculated
by an expression is simply not possible.

This applies both on the way into the asm and also on the way out.

It would be really hard to provide this kind of facility for a number of
reasons. For one thing, gcc likes to invert tests and use the reverse
branch during optimizations and code generation, and there is no
easy way to express that in the asm syntax.

I think the ARM backend of GCC tried to support condition code access
with some kind of asm syntax, but that got ripped out because it could
never work reliably.

gcc’s asm syntax allows you to specify exactly what the asm generates, and thus the optimizer can actually delete the asm if it is unused (and not volatile). This is very useful when working with things like add-with-carry, where the optimizer can reasonably determine that the result is not needed in some cases.

In other words these other asm syntaxes are easier to use but they are not, I believe, as powerful.