Hacker News Reader

No support for multiple return values (in registers). There's structs, but that means returning via memory because, well, see point 1.

Return values in registers are a machine level optimization. Whether something is in a "register" is up to the CPU today on most CPUs. If you set a value in the last few instruction cycles, and are now using it, it probably hasn't even made it to the L1 cache yet. Even if it was pushed on the stack. That optimization made sense on SPARC, with all those registers. Maybe. Returning a small struct is fine.

There's an argument for multiple return values being unpacked into multiple variables, like Go and Python, but that has little to do with how it works at the machine level.

Missing operations such as popcount, cttz, simultaneous div/rem, or rotates.

Now that most CPUs have hardware for those functions, perhaps more of those functions should be visible at the language level. Here's all the things current x86 descendants can do.[1] Sometimes the compiler can notice that you need both dividend and remainder, or sine and cosine, but some of those are complicated enough it's not going to recognize it.

Traps are UB instead of having more predictable semantics.

That's very CPU-dependent. X86 and successors have precise exceptions, but most other architectures do not. It complicates the CPU considerably and can slow it down, because you can't commit anything to memory until you're sure there's no exception which could require backing out a completed store.

[1] https://software.intel.com/sites/landingpage/IntrinsicsGuide...

"There's no "bitcast" operator that changes the type of a value without affecting the value."

Technically, you are supposed to use unions for that, though it's a pain. The PostgreSQL codebase is compile with -fno-strict-aliasing so that a simple cast will get the job done, but obviously that's technically out of spec.

Actually, the guideline I've heard is that memcpy should be used, since memcpy has the magic property of copying the bytes without affecting the destination type. Unions are only legal in C99 and newer (although C99 erroneously includes this in its list of undefined behavior--this was fixed in C11); C89 and any version of C++ don't permit this behavior.

I keep hearing this rumor, but C99 did not erroneously include unions-as-type-punning in a list of undefined behavior. The normative language is unclear, but clarifications were added1][2].

1: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_257.htm

2: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm

The parent comment seems to be saying that C99 does allow type punning with a union, with an explicit clarification as you say. In C89 it was ambiguous and in C++ it is explicitly disallowed (you are supposed to use memcpy).

Sorry, I misread the parent comment. Now it's too late to delete mine, please ignore.

Or better, memcpy.

Which in this case may or may not copy memory. You're only able to express changing the meaning of some specific bytes by moving them which is the contrary of what you meant. Sure you're not moving things because normally the compiler will (and does) optimize, but you must say that you need the bytes to be copied.

> * Missing operations such as popcount, cttz, simultaneous div/rem, or rotates.

gcc/clang offers builtins for most of these. And if you give the compiler the right march parameter it'll quite likely turn your hand-rolled code for these operations into the x64 instruction you're targeting. Try it on Compiler Explorer.

There's no "bitcast" operator that changes the type of a value without affecting the value. The most common workaround involves going through memory and praying the compiler will optimize that away (while violating strict aliasing semantics to boot).

Access through a union allow the same region of memory to be interpreted as different types.

No support for multiple return values (in registers). There's structs, but that means returning via memory because, well, see point 1.

No mainstream compiler will ever not optimise that.

> Access through a union allow the same region of memory to be interpreted as different types.

…only in C.

> No mainstream compiler will ever not optimise that.

Actually, it's mandated by the System-V ABI for structures of an appropriate size.

Which is not supported in every OS out there.

Right, but System-V is fairly mainstream, which is why I brought it up.

Using a union still has the going-through-memory problem, though. I spent a day or two trying to coax clang into doing the efficient thing with a union a couple years back when I could have gotten the job done in 30 minutes with raw assembly (alas...)

RE: Return values, you'd be surprised. You can't assume you'll get properly optimized code for something like that in WebAssembly for example, despite the fact that you're using an industry-standard compiler (clang) and runtime (v8 or spidermonkey).

> Using a union still has the going-through-memory problem, though.

Not with modern compilers: https://godbolt.org/z/e6sRqh

That's a compile-time constant, effectively. What matters is real code.

https://godbolt.org/z/MPCuw-

> * Missing operations such as … simultaneous div/rem

Doesn't the div function do this?

> * There's no "bitcast" operator that changes the type of a value without affecting the value. The most common workaround involves going through memory and praying the compiler will optimize that away (while violating strict aliasing semantics to boot).

> * Missing operations such as popcount, cttz, … or rotates.

Thankfully, these are coming in C++20.

Don't forget arithmetic operations that can detect various corner cases.

Writing something like:

  sum = x + y;
  if(sum < x || sum < y) {
      ...
  }

And then hoping the compiler will optimize your if statment to a single overflow CF check is a bit silly.

That would not prevent the overflow from actually happening, which would be technically UB if the sum is a signed type. It is possible to catch overflow in the last instant like this (in the last instant before executing the addition instruction) but the test is more involved. It's a pity that there are no standardized tools (AFAIK) but it's not possible to write a substantial piece of code in this way, anyway.

What you would generally do is assume that x and y can't be overflow. I.e. you need to have a rough idea what quantities you will process. And put a few checks and assertions in strategic locations.

Right, I was assuming x and y were unsigned types at least as large as an integer. Tests for other types are different.

If you just use `sum < x` or `sum < y` rather than both, C compilers do reliably perform that optimization. (You don't need both; `sum < x` and `sum < y` are always both false or both true.)

Is there any low level language, which is actually close to modern x86_64?

Probably the closest you'll find today is LLVM IR (or maybe there's a slightly closer IR in some other compiler). In terms of languages you'd actually like to program yourself, Rust and C++ are slightly closer, but that's mostly a factor of trying to incorporate more hardware features rather than modelling hardware better.

Does anyone code directly in LLVM IR? I've had the thought of toying with it as a better portable assembly with a crazy optimizer behind it...but since the LLVM folk want it to be an implementation detail they warn against it due to how volatile it is across versions.

I'd be really interested to hear experiences of people who have done it though, even as a toy.

I've coded directly in LLVM IR a few times (mostly for testing). It's not pleasant, primarily because you have to manage the SSA construction yourself, although the CFG can also be annoying.

There is a small, very restrictive class of LLVM IR that is going to be effectively stable, and even portable. Stripping debug information goes a long way to making your IR readable by newer versions of LLVM, and staying away from C ABI compatibility (especially structs) can make your code somewhat portable.

LLVM IR isn't exactly portable, so that doesn't really work.

The bitcode variant used by Apple for their OSes tends to be more clean in that regard.

The only language close to modern x86_64 is x86_64 itself. Well, no, not really, because assembly instructions get dispatched as micro-ops…