No-one cares anymore about ancient computers or weird specialist systems of course, but don't neglect my important requirements by breaking compatibility with any the platforms I am relying on at any point in time. We also need all of the most aggressive optimisations that compiler writers can come up with—this is high-performance code, after all!—but we certainly don't have time to deal with any breaking changes that would force revisions to our big important codebases. Make sure we can realise significant performance gains with just a simple recompilation. But remember to keep everything straightforward and close to the machine: we really hate all that weird UB which it's so easy to trigger by making an obvious, reasonable assumption which turns out to be wrong for some inexplicable reason.
But the industry ultimately runs on compatibility, so I get why they do it. But if compatibility breaks, wouldn't hardware vendors die out? If you look at PLC and other hardware manufacturers, they're not even using modern coding. They're still running on old code. They say it's 'safe and certified code,' but in reality, it's just legacy code.
Because in hardware, programmers, aside from researchers, are often paid much less and work in worse conditions compared to their software counterparts. At a software company, code is the product itself. But in manufacturing, software is treated as a cost attached to machines worth billions of dollars. While equipment and sensors keep getting updated and more expensive, the people connecting everything are seen as a cost cutting target. So hardware programmers generally have good job security, but their salaries aren't high. In that situation, asking them to learn something new instead of sticking with the old ways usually gets resistance, because they're not being properly compensated for that learning
Conceptually intmax_t is a generic type of the form intmax_t<T>. Since C does not have generics, the T is chosen by the compiler during compile time.
But this means that the first time you compile any shared library with an intmax_t parameter or return value in one of its functions, you have permanently baked in the type parameter T to whatever the compiler chose it to be at that moment in time.
You cannot retroactively change intmax_t even if you change the symbols, because intmax_t runs into the same problem any generics system does, you cannot retroactively add instantiations for future types that were not explicitly compiled into the dynamic library.
Even if C gets generics and intmax_t would become obsolete either way, because you don't need intmax_t<T>, you can just have T.
intmax_t is only interesting for choosing the T and even then it is only interesting inside function implementations and never in their signatures.
So my conclusion is that intmax_t was a failed attempt at trying to be "clever" with the idea of introducing generics without introducing generics. This is an idea that is so doomed that anyone trying to rescue it, didn't really understand the problem with intmax_t.
I was battling GCC… until the new guy (a smart business major) pointed out I could just compile from Lua to ASM directly. Claude was happy to write a compiler over night. :facepalm:
Oh just that it made me confront ABIs. I have a special purpose use case (home automation), so I wasn’t worried about general purpose compilation, just the subset of lua that fable tends to write for the prompt we use.
I have no idea how it’s implemented. Lua goes in, position-independent dependency-free xTensa LX7 code comes out the other. Maybe I should read the code?
It’s extremely fast. 3kB of lua becomes 1kB of machine code. I’ll have to get a blog post together on it.
Should have a (2022) in the title, not that anything has changed (AFAIK), but the sky didn't fall either ;)
In the end, OS/CPU combinations define ABIs, compiler toolchains (no matter what language) can't do much more then follow (if they want to be able to talk to the operating system at least). E.g. if one day operating systems implement stable Rust-friendly ABIs, then C compilers will have to adapt to those conventions instead.
One of the most frustrating things in my opinion about new systems languages, is that they refuse to have a stable ability to, so everything has to pretend to be C at the boundaries.
When Rust chose an unstable ABI it did so for a good reason. I personally think the only place where a stable ABI would be warranted is inside the panic machinery and this is mostly because it is kind of annoying to write perfect no panic Rust just to get rid of the 300KiB overhead but even here I'd take my time, possibly decades, before making the decision to have a stable ABI.
The wrong decision is to choose to support a stable ABI and lock in design mistakes early on.
I'm already hinting at the solution so I'll be taking my leave for now.
> // Proposed: Transparent Aliases
> _Alias g = f;
I think defining a constant function pointer should work. As long the compiler doesn't store this pointer in the result executable and optimizes-out all calls via it into calls to the source function.
The root cause of all C ABI problems are shared libraries. They give so much trouble with little to no benefits. Ideally no application should use them. All dependencies should be compiled from sources with the same compiler and standard library. System libraries aren't needed either, it should be possible to perform syscalls directly. In such approach no ABI incompatibility can happen.
One may say, that shared libraries can save some space for both disk storage and RAM. But such savings aren't that huge and in some cases are even negative - if a library is linked-in, it's possible to discard unused functionality and even inline many library functions.
This has been somewhat argued to death, but even if you put aside operational concerns with static linking (security/size/independent upgradability), many attempts to do away with shared library ABIs end up reinventing them--at least for software whose job it is to integrate with other software on the machine, which is a lot of it.
If you statically link a cryptography stack, you suddenly need a lot more information about what certificate/cipher systems are available on the host via IPC. If you statically link media codecs, you suddenly need a lot more information about hardware acceleration from the host via IPC. If you statically link libraries to manipulate binary data in some shared format, you need extra code to runtime-determine things like endianness. If you're asking hardware to do chunky numerical math, suddenly you need to prepare data with specific widths/sizes and you need to determine that from somewhere.
Windows did good work here with COM, but the average windows app is both more self-contained and targets fewer configurations than a Linux app, so many of those issues don't come up as often as they do on Linux. Linux has a long way to go here, both because there's nothing as capable/ubiquitous as COM there, and because so much Linux software is small and therefore necessarily not self-contained (not talking about the UNIX philosophy and shell tools here--talking more about runtime intermediate layers like VAAPI or compat shims or protocols with multiple implementations).
29 comments
[ 4.0 ms ] story [ 116 ms ] threadBecause in hardware, programmers, aside from researchers, are often paid much less and work in worse conditions compared to their software counterparts. At a software company, code is the product itself. But in manufacturing, software is treated as a cost attached to machines worth billions of dollars. While equipment and sensors keep getting updated and more expensive, the people connecting everything are seen as a cost cutting target. So hardware programmers generally have good job security, but their salaries aren't high. In that situation, asking them to learn something new instead of sticking with the old ways usually gets resistance, because they're not being properly compensated for that learning
Conceptually intmax_t is a generic type of the form intmax_t<T>. Since C does not have generics, the T is chosen by the compiler during compile time.
But this means that the first time you compile any shared library with an intmax_t parameter or return value in one of its functions, you have permanently baked in the type parameter T to whatever the compiler chose it to be at that moment in time.
You cannot retroactively change intmax_t even if you change the symbols, because intmax_t runs into the same problem any generics system does, you cannot retroactively add instantiations for future types that were not explicitly compiled into the dynamic library.
Even if C gets generics and intmax_t would become obsolete either way, because you don't need intmax_t<T>, you can just have T.
intmax_t is only interesting for choosing the T and even then it is only interesting inside function implementations and never in their signatures.
So my conclusion is that intmax_t was a failed attempt at trying to be "clever" with the idea of introducing generics without introducing generics. This is an idea that is so doomed that anyone trying to rescue it, didn't really understand the problem with intmax_t.
- 2023-06-10, 64 points, 16 comments: (https://news.ycombinator.com/item?id=36249253)
- 2022-03-13, 175 points, 129 comments: (https://news.ycombinator.com/item?id=30660528)
Does it follow the lua spec?
How are tables implemented?
How fast is it compared to normal Lua, luajit interpreter, and luajit jit?
I have no idea how it’s implemented. Lua goes in, position-independent dependency-free xTensa LX7 code comes out the other. Maybe I should read the code?
It’s extremely fast. 3kB of lua becomes 1kB of machine code. I’ll have to get a blog post together on it.
Rust is the new black and it will supplant C/C++ and almost everything else short of virtual machine languages like Java/C#.
In the end, OS/CPU combinations define ABIs, compiler toolchains (no matter what language) can't do much more then follow (if they want to be able to talk to the operating system at least). E.g. if one day operating systems implement stable Rust-friendly ABIs, then C compilers will have to adapt to those conventions instead.
Unnecessary hubris. I assure you the original ABI authors were plenty smart and just faced a different set of problems.
> Our forebears are either not interested in a world without the mounting, crushing debt or just prefer not to tackle that mess right now
The article mentions the organizational/social part of this problem, but then goes on to drop this turd.
I can also assure you that our forebears were neither malicious or lazy; but faced the same problem this proposal does.
I don’t like seeing such disrespect for the folks who laid out the groundwork for us.
You're taking the idea of respect too far.
When Rust chose an unstable ABI it did so for a good reason. I personally think the only place where a stable ABI would be warranted is inside the panic machinery and this is mostly because it is kind of annoying to write perfect no panic Rust just to get rid of the 300KiB overhead but even here I'd take my time, possibly decades, before making the decision to have a stable ABI.
The wrong decision is to choose to support a stable ABI and lock in design mistakes early on.
I'm already hinting at the solution so I'll be taking my leave for now.
In my opinion, that's the correct thing to do anyhow, even for bigger systems
I think defining a constant function pointer should work. As long the compiler doesn't store this pointer in the result executable and optimizes-out all calls via it into calls to the source function.
One may say, that shared libraries can save some space for both disk storage and RAM. But such savings aren't that huge and in some cases are even negative - if a library is linked-in, it's possible to discard unused functionality and even inline many library functions.
If you statically link a cryptography stack, you suddenly need a lot more information about what certificate/cipher systems are available on the host via IPC. If you statically link media codecs, you suddenly need a lot more information about hardware acceleration from the host via IPC. If you statically link libraries to manipulate binary data in some shared format, you need extra code to runtime-determine things like endianness. If you're asking hardware to do chunky numerical math, suddenly you need to prepare data with specific widths/sizes and you need to determine that from somewhere.
Windows did good work here with COM, but the average windows app is both more self-contained and targets fewer configurations than a Linux app, so many of those issues don't come up as often as they do on Linux. Linux has a long way to go here, both because there's nothing as capable/ubiquitous as COM there, and because so much Linux software is small and therefore necessarily not self-contained (not talking about the UNIX philosophy and shell tools here--talking more about runtime intermediate layers like VAAPI or compat shims or protocols with multiple implementations).