4 ms·
The author is confused. The points they make are not about x86 vs. non-x86, they're instead about mixing different architectures. Yes, if you write a program an
by lionkor 3y ago
The author is confused. The points they make are not about x86 vs. non-x86, they're instead about mixing different architectures. Yes, if you write a program and deploy it on three machines, and they all have different pointer sizes, endianness, and executable formats (PE, ELF, etc.) then, yes that can suck.
If this article was written 10 years ago, more people would probably agree. But nowadays, its perfectly possible to have a setup where all your machines, from large servers, to laptops, to small embedded devices, are x86, or aarch64, or something like that, and no mixed architecture is present. There are other, possibly more glaring, issues with sharing software across very different setups: Memory requirements, assumptions about filesystem layout, assumptions about syscalls/capabilities, assumptions about security. The architecture is usually at most a cli switch in your build pipeline, all this other stuff isn't.
That said, if you use Rust, Zig, Java, C++ (with Zig C++, for example), C (with Zig CC), building N different binaries for different targets is a bash script with exactly N lines of code. Not sure that's all that hard.
> where [...] people haven't tried their software, software has architecture specific bugs
I have to agree with this, just from the projects I've been part of, reviewed and used in the past. This is not an ARM issue, its an issue of laziness. People are inherently lazy, and they will only build and test on what is convenient. x86 machine at home, x86 ci/cd server, ... guess what isn't being tested on? Non-x86.
That said, there are not that many things that can go wrong on non-x86 in my experience. They're usually little endian, they usually have 32 or 64 bit pointers, sizes, etc., and if they don't, they're likely not magical either.
People who still write C code, but also don't know that they can't just use `char`, `int` and `long` to mean 8, 32, and 64 bit, are the only population that will have issues here. Sadly, that's a lot of people in my experience.
The real issue is everything else, like I said above (fs layout, security, assumptions about OS specific behavior, ...)
- ptspts 3y agoChallenge: specify a mainstream architecture (e.g. targeted by Debian stable) which doesn't have char=1, short=2, int=4, long long=8 bytes with GCC or Clang.
- gpderetta 3y agowell, you skipped long :D
- professoretc 3y agoYeah, skipped the one built-in type that is different between architectures (64-bits on 64-bit Linux, 32-bits on 64-bit Windows).
- gpderetta 3y agoIndeed. And 32-bits on 32-bit Linux of course.
- fooker 3y agoOne major point of divergence is the size and representation of pointers, and people treating pointers as integers. Also floating point formats can vary a bit even with the size being the same. So a piece of code written for one might be subtly wrong for another.
- ColonelPhantom 3y agoAren't pointers pretty much universally 64 bits, except for some old or esoteric machines? And why would you not be able to treat one as an integer? Are there any examples of such ISAs? Finally, floating point formats do differ, but that shouldn't affect anything except precision and binary format. Also I'm pretty sure "float" is standard IEEE 32 bit and "double" is standard 64 bit, with predefined exponent/mantissa sizes. The only thing that could differ between arches is endianness, and by far most ISAs have settled on little endian.
- gpderetta 3y agox86 is hardly esoteric. New software for it is being published today.