I understand that the operand order is inversed for them, but what about instructions that have more than 2 operands?

Also I'm confused by inline assembly, the gcc kind. https://en.wikipedia.org/wiki/Inline_assembler . There is a "D language" example there too, but it looks like you can't use it mid function like in C?

Those two themes (difference between atnt and inline asm, and inline asm) are somewhat related, because it's pretty hard to use intel syntax with gcc. You have to enable intel syntax at the beginning of inline asm, and disable it at the end of it. I guess it's because gcc historically supported more than just intel processors, they don't care about intel enough. And those are the only processors I will ever see.

AT&T syntax ... erm, the less said the better

But seriously, I think just adding a couple of extra lines to enable and disable Intel syntax is a small price to pay for something that is orders of magnitude more readable. IMO of course.

If I'll actually make a compiler, maybe I'll be able to fix this "extra lines" situation...

Waiting for answers.

Found those interesting notes on inline asm:

https://dlang.org/spec/iasm.html

https://wiki.dlang.org/LDC_inline_assembly_expressions

https://wiki.dlang.org/Compilers

http://llvm.org/docs/LangRef.html#inline-assembler-expressions

First, 3-operand instructions have the operands reversed, so instead of "eax, ebx, ecx" in Intel syntax, it would be "ecx, ebx, eax" in AT&T. There's very few insns with exceptions here (e.g. enter) but I'm not aware of 3-operands exceptions to this rule though.

I don't know anything about D's inline asm, but it looks total shit at a glance, since it copies the one from Visual Studio rather than GCC, which means it doesn't support operand constraints or clobbers which results in trash code. So what's the point of using it if the code is worse than HLL? And if the entire function is in asm, you can just code it in FASM or whatever.

Inline asm is incredibly useful for (forced) inline functions though, but only in GCC since VS generates crap code with it.


What are you confused about GCC's inline asm?

Keep one thing in mind: GCC does NOT parse the asm string and does not understand it. You have to explicitly tell it what the asm does with operands or clobbers. This is great because it allows you to use hacks and "outsmart" the compiler in corner cases, but also because GCC will fully know the intent of the asm if you give the right operands.

Examples: %0 accesses the "zeroth operand" which in this case is the output operand "=a"(some_var). "=a" is a constraint, it specifies the eax register (or rax, ax, al, depending on size of some_var). "=" says it's an output operand, "+" means it's input/output operand. If we used "add" instead of "mov", we'd have to use +.

The beauty here is that GCC knows that some_var has to be placed into eax before the asm, and the result is also in eax (if we used 'add'), so it generates very good code, unlike Visual Studio.

You can specify more constraints to give it more options, like "=abcd" which lets GCC select any of eax, ebx, ecx, edx registers, depending on surrounding code. Or just "=r" which means any general purpose register.

Also, some registers may not have a constraint associated just with them, you can force them with something like this: This code is optimal: GCC will optimize out all the temporaries here to just direct use of the ebp register.

In GCC, variables don't correspond to a register whatsoever. They only correspond to a register during an inline asm, if you force it that way. Otherwise it's free to remove redundant moves, like in the above example. It actually compiles to just: or, if the source was in a different register, it automatically loads it into ebp first, and then does the inline asm. The load into ebp can happen anywhere, since GCC knows about it: it can be scheduled way ahead if it thinks it's optimal.

You should read the GCC documentation about it, since it has far more options and stuff. It even has an "asm goto" when your asm transfers control to somewhere else via a jump or whatever, and yes GCC will know this because you specify the labels as operands, so it will optimize surrounding code and the control flow graph accordingly. That's why GCC's inline asm is superior to Visual Studio and other crappy inline asms.

Just think of operands as the information you tell GCC about the asm. If your asm writes to a register, specify that. If it reads from a register, specify that. If it reads from a specific memory place, specify that. If it clobbers a register (as a temporary), specify that as clobber (read the doc).

Do not use "memory" clobber unless necessary: it tells GCC your asm clobbers ALL memory, so it removes all memory register cache optimizations. If you know what part of memory it accesses, do it like e.g. (assuming p is a pointer to something you write to):


Also D has some nice features I'd like to see in C++ such as "properties", but the C++ committee is full of morons which won't fucking add it already despite the fact it's been requested for ages and also THREE major compilers support it as an extension (but sadly, not GCC, ffs!! Clang, Visual Studio and Intel Compiler all support it as __declspec(property)). I mean GCC C++ maintaners also piss me off a bit because they are so against adding "extensions" to it and want to stick to the shitty standard (which is why I rage at the committee now), while the C front-end guys are much more reasonable and added a ton of extensions. __declspec(property) is a C++ feature though, since it requires C++ classes/structs member functions.

D sucks though, because it has built-in garbage collector which is there even if you turn it off, I'm so sick of that shit really. I'm not against garbage collectors per-se, but rather their forced use on everything, what if I wanted to use a different type of garbage collector? they must be implemented as LIBRARIES or APIs, not BUILT-IN for non-scripting languages, that's downright retarded.

Thank you.

I wonder, if a good compiler will actually analize the contents of inline asm, without me specifying all that constraint info by hand. I wonder if that's possible.

>I don't know anything about D's inline asm, but it looks total shit at a glance, since it copies the one from Visual Studio rather than GCC

there are three compilers for D, it looks like they implement both ways. I don't know D.

>garbage collection must be implemented as a library

Impossible. Qt tried to do that in C++, and they only archived smart pointers. Compiler should analyze the code and see when the deletion of a variable happens, and also do escape analysis to see if GC is even necessary for a variable. Without it, garbage collection can't be used as a safety net.

>__declspec(property)

Haven't heard about it. Seems like just a syntax sugar, not that necessary... Maybe you can just run a preprocessor on your code? Annoying, I know.

Well I suppose it's possible but it's less powerful (or quite complicated, imagine using obscure instructions or raw .byte directives?). As far as inline asm, GCC treats the "asm string" as a black box. All it knows about it are inputs, outputs, clobbers, labels, etc.

For example if you push a register and pop it at the end, you usually don't have to specify it as an output or clobber at all, since its value won't change in the asm. (even though it affects the stack, you don't really have to specify that in this case because it doesn't affect any of GCC's code generation, just don't "change" the stack pointer to something else at exit than it was at entry).

Now imagine a compiler actually managing to scan your asm and seeing that the register's value won't change in this particular case. That would mean it has to literally execute the instructions in a virtual machine or something?

BTW: I didn't know this some years ago, but GCC's inline asm is almost directly tied to its internal RTL representation. That's why it's so powerful: its own instructions are represented similarly at the lowest level before they are assembled. An "asm" to GCC looks like just a big "instruction" with specific inputs/outputs/clobbers etc at the RTL level.

I mean GC like just mark and sweep? Of course, you'll need some metadata to your struct fields and whatnot, I never said you don't need them But at least it's not tied to the language and unable to be changed. If/when C++ adds reflection, this becomes way easier. With builtin garbage collector, you're pretty much stuck though.

Well, C++ itself is syntactic sugar for C code in most cases too

I mean, it's very useful to abstract away field accesses, not just for beautifying code, though I admit, code beauty is one of the reasons I want it. Imagine you're doing a debug build and want to add assertions to a field when it's accessed, to make sure the values fit in a range or whatever condition.

Yeah, you can use a function instead of a field, but beside the fact it's ugly, it changes the API of how you access that field. So code has to be changed, which might not even be mine.

Maybe this struct was a plain simple struct before, just with data. So accessing fields was normal. Now you want to validate its members in debug builds, without changing the syntax (3rd party code or just too much work). Just make the fields properties instead and add the checks, simple and useful. Nothing changes in non-debug builds, since syntax is the same, so you get zero overhead.

That is, if I had this in GCC...

(also, look at the standard library of C++ how many member functions are stuff like size() or begin() or end() and so on, looks like even the committee needs this kind of "functions that should really look like fields")

Delphi/FPC has had properties for a while now. I know you prefer C, but keep this in mind. We've discussed languages before, briefly. I think you would appreciate Delphi/FPC if you gave it a chance.