from Hacker News

Weird architectures weren’t supported to begin with (2021)

by dbaupp on 2/17/23, 11:02 AM with 93 comments

• by ris on 2/18/23, 1:18 PM

  I never agreed with this. Who defines what is considered "weird"? Should all projects declare up-front that it only is designed to work on: - x86_64 and aarch64 - linux, darwin and windows - glibc (no musl) - binutils x.xx - ...

  ... where do you stop before you're defining an exact linux distribution?

  If it weren't for people building and using packages for architectures that are "unsupported", I should point out that there would be no good userspace support for ARM or aarch64. These too were once "weird architectures" that only have good support now because of people building for (and using) these architectures without permission, then shaking all the bugs out. This is currently still happening for risc-v.

  I have to contrast this attitude to CPython, who, while I'm sure they never originally said that their code was designed to run on s390 (risc-v, pick your architecture..), would not go ahead with a change that froze out these users.

  I also don't think the "we're just a poor bunch of small-time package maintainers whose package accidentally became popular" angle quite works, because they call themselves the "Python Cryptographic Authority" and use the prominent package name `cryptography`, which certainly appears to imply some sort of official status. I wouldn't blame people for inferring that its support policies were somewhat aligned with the python foundation's.

• by zamalek on 2/17/23, 6:30 PM

  > The security of a program is a function of its own design and testing, as well as the design, testing, and basic correctness of its underlying platform: everything from the userspace, to the kernel, to the compilers themselves.

  You don't even have to worry about bugs. There are many cryptography primitives that require constant-time to guarantee security. That means that the latency of each machine code instruction could be vital to security. The latency of instructions between vendors within the same architecture is already a concern.

• by jameshart on 2/18/23, 2:39 PM

  There’s always been a weird double standard in open source software where it has been seen as ‘reasonable’ to expect the same code to compile and work on everything from an Arduino to an IBM mainframe, PDP11 to a RISC-V.

  ..But getting it to work on Windows? What? Do you expect the developers to fork out for Windows licenses? Don’t be ridiculous. Heck, some software is still downright snooty about the absurd idea that it should run cleanly on a Mac.

• by cwzwarich on 2/18/23, 1:13 PM

  > The C abstract machine, despite looking a lot like a PDP-11, leaks the underlying memory and ordering semantics of the architecture being targeted. The result is that even seasoned C programmers regularly rely on architecture-specific assumptions when writing ostensibly cross-platform code: assumptions about the atomicity of reads and writes, operation ordering, coherence and visibility in self-modifying code, the safety and performance of unaligned accesses, and so forth. Each of these, apart from being a potential source of unsafety, are impossible to detect statically in the general case: they are, after all, perfectly correct (and frequently intended!) on the programmer’s host architecture.

  I don't disagree with his general point that C isn't really cross-platform, but these are bad examples:

  - The C memory model addresses the issues regarding atomicity, memory ordering, and the safety of unaligned accesses (although users might not like the answer for the last one).

  - Coherence within a C program is guaranteed by the language, so issues with coherence only arise when interacting with an incoherent external agent. How could any language solve this?

  - Are there any examples of self-modifying code that don't already make assumptions about the underlying ISA? If you're already doing that, dealing with data/instruction memory consistency doesn't seem particularly onerous. Even when only targeting AArch64, it isn't possible to write platform-independent userspace assembly code that does this because instruction cache maintenance instructions might not be enabled for EL0.

• by dwheeler on 2/18/23, 1:19 PM

  A lot of the problem is that GCC hasn't supported Rust, and LLVM doesn't support many platforms. Since this article was written (2021), there's been work to implement Rust fully in GCC, as well as ways to call from LLVM the GCC backend (which supports far more architectures). So there's a reasonable expectation that some of this problem will be fixed in the long-term.

  IBM mainframes write most paychecks, and companies do pay some OSS developers to support some of the architectures the author doesn't like. Making it impossible is different.

• by docandrew on 2/18/23, 3:00 PM

  I think the frustrating thing is that, while rust may consider one of these architectures “tier 2” or unsupported or whatever, there’s a Python interpreter that presumably doesn’t, and whoever is using the Python cryptography package expects it to work the same place all their other code does. And very likely it’s some dependency several layers deep. If my code is going to end up architecture-dependent then why bother with an interpreted language in the first place?

• by CJefferson on 2/18/23, 12:10 PM

  I've been trying to officially mark some open source software I work on as not supporting big endian. We don't test it, and I think it's very likely there are some subtle bugs.

  Sometimes someone will ask for support, but (unsurprisingly, I don't blame them) they don't want to put the work into testing up to the standard we achieve on ARM and x64.

• by johnklos on 2/18/23, 1:52 PM

  That's an interesting take. It seems like a modern slant on the old trope of "all the world's a VAX", then "who cares if it's not i386?", and now, "of course it's portable - we support both kinds - amd64 AND aarch64".

  But it's a bit disingenuous. Are developers being overwhelmed by problem reports for things that hardly matter? Looking at NetBSD's pkgsrc, which supports more OSes than just NetBSD, we see about 64,000 patch files for about 26,000 packages. While many packages don't require any patches, some require many.

  This is because for many programs, upstream just don't care. It's not just about odd architectures - they just don't care about NetBSD support, or support for different, alternative OSes. Perhaps that's fine, but consider this - the patches already exist and are tested, and they're maintained in pkgsrc.

  There are times people become indignant about being told how to fix their software for use under systems other than Windows, common Linux and macOS, on CPUs other than amd64 and aarch64. Yes, indignant. Some Python folks don't want to consider anyone would want to use Python on systems (like embedded) that don't have full IEEE floating point emulation. postgresql would rather mark platforms as broken than just let them compile the standard c portions of their code.

  People like to say, "they don't want to spend the time and energy", as if it adds work. No - there are examples where people choose the broken path when the not broken path is just as easy if not easier. Nobody is obligated to add or patch anything, even if the patches are freely given and well tested. But the fact that some people actively fight against portability is disturbing, and should be viewed with suspicion.

  The author of the article seems to have forgotten some history. They mention downsides of the c ecosystem, like the lack of standardized ways to build, the lack of consistent package management, and so on. But in every instance where those things have been imposed, the imposition has been problematic, has it not? Have we not seen security issues with PyPi? Have we not seen the dependency hell which is Ruby?

  The point is that nobody can tell anybody else how to do open source, so we'll always have a hundred different ways to do things. We also can't help that some people will be gatekeepers. But we personally can ignore the gatekeepers and help make things portable.

  Making excuses for why portability is somehow extra work is only encouraging gatekeeping. We don't need to do that - gatekeepers already have enough energy on their own.

• by wizzard0 on 2/18/23, 12:54 PM

  One more example that security cannot be abstracted, packaged and bought in a box.

  The same goes for performance (but that one can be packaged at least sometimes)

• by ergonaught on 2/18/23, 2:37 PM

  > As someone who likes C: this is all C’s fault. Really.

  I think I agree with almost everything in this post except this sentiment.

  Blaming the tool is silly. You may as well blame assembly language, and if you're doing that you may as well blame CPUs and electricity and you know what, physics is harmful, we should rewrite it in Rust.

• by Karellen on 2/18/23, 2:36 PM

  > Imagine, for a moment, that you’re a maintainer of a popular project. [...] You’ve also got a CI/CD pipeline that produces canonical releases of your project on tested architectures; [...] Because your project is popular, others also distribute it: Linux distributions, third-party package managers, and corporations seeking to deploy their own controlled builds.

  > You don’t know about any of the above until the bug reports start rolling in: users will report bugs that have already been fixed, bugs that you explicitly document as caused by unsupported configurations, bugs that don’t make any sense whatsoever.

  If 3rd-party build recipients are sending their bugs directly to you, that's a failure of the 3rd-party builders to take responsibility for their packages. They should be telling you to submit your bugs to them, so they can check their packaging, and then the packagers should talk to upstream only if there are issues to be resolved there.

  > You struggle to debug your users’ reports, since you don’t have access to the niche hardware, environments, or corporate systems that they’re running on.

  Yes, C supports lots of environments, and Rust supports quite a few (and hopefully more, soon), but I think it's perfectly fine for an upstream author to only support a subset of those. The benefits of Free Software is that if you want to get some software running on platforms the original author doesn't support but the language does, you can do that.

  Investigate the bug yourself. Figure out if it's in the app, or a 3rd-party library, or even the toolchain. Submit a patch.

  A good proportion of authors will happily accept patches for systems they themselves can't test on, if it's not too intrusive, and doesn't cause regressions on the platforms the author does support. They might be willing to entertain an intrusive patch series that allows for better cross-arch support, if you're willing to work with them on that.

  And if an author is not interested in helping you scratch your itch (ew! :-), create a fork. That should be easier than ever these days with the version control tools we have now, so much more than when Free Software was first envisioned. The author may even be willing to point other people who want to use their software on your platform your way (e.g. in their README), if only to get those users of their back!

• by rbanffy on 2/17/23, 11:57 AM

  > Give up on weird ISAs and platforms

  NEVER!

• by phkahler on 2/18/23, 2:14 PM

  Yeah why should we even care about s390 for some things?

  https://github.com/solvespace/solvespace/issues/1264

  I don't think big commercial customers are designing airplanes with it.

• by PaulHoule on 2/18/23, 2:06 PM

  Personally C for Arduino programming drives me up the wall. With 32 general purpose registers in assembly language you can often keep all the variables in your inner loop in registers and still have a few left over for the interrupt handler. In C on the other hand you know it is moving the stack pointer around meaninglessly just so it can support recursive functions which aren’t really appropriate for embedded systems.

  I still write C for it because as beautiful as AVR-8 is, it is a dead end and if I need more capability I can take my C program to an ARM and maybe someday a RISC-V board. (I dream of embedding a soft AVR-8 on an FPGA with some special logic but the engineering students I know tell me that the Verilog class was like getting mauled by a bear.). At least gcc meets me halfway and has 24 bit ints in AVR-8.

  For that matter I just got a VisionFive 2 board that I need to put in a case and bring up with Linux. It has been a long time since I had to mess with other peoples C programs and bring them up on a new architecture but I think I’ll be doing it again.

• by pornel on 2/18/23, 1:58 PM

  Are there architectures which LLVM doesn't support, which aren't retrocomputing or 16-bit microcontrollers?

• by DerekL on 2/18/23, 11:02 AM

  Title needs (2021).

• by pyuser583 on 2/19/23, 8:58 AM

  If only we had stuck with Ada.