Hacker News Reader

Comment by protomyth | Hacker News Reader

So, of the list of current platforms:

  alpha     Digital Alpha-based systems
  amd64     AMD64-based systems
  armv7     ARM-based devices, such as BeagleBone, BeagleBoard, PandaBoard ES, Cubox-i, SABRE Lite, Nitrogen6x and Wandboard
  hppa      Hewlett-Packard Precision Architecture (PA-RISC) systems
  i386      Standard PC and clones based on the Intel i386 architecture and compatible processors
  landisk   IO-DATA Landisk systems (such as USL-5P) based on the SH4 cpu
  loongson  Loongson 2E- and 2F-based systems, such as the Lemote Fuloong and Yeeloong, Gdium Liberty, etc.
  luna88k   Omron LUNA-88K and LUNA-88K2 workstations
  macppc    Apple New World PowerPC-based machines, from the iMac onwards
  octeon    Cavium Octeon-based MIPS64 systems
  sgi       SGI MIPS-based workstations
  socppc    Freescale PowerPC SoC-based machines
  sparc64   Sun UltraSPARC and Fujitsu SPARC64 systems

There still seem to be a few that aren't supported by LLVM

View on HN

OpenBSD has long included multiple system compilers as required for supported platforms, at one point gcc 4.2.1, gcc 3.3.6 and gcc 2.95.3 (!) were in the tree. OpenBSD 5.4 was the last version to include gcc2 for a.out/static lib platforms like vax. After 5.5 most platforms were ported to ELF and gcc3 or gcc4 (..if not memory constrained) by Miod Vallat, even when it meant writing compiler backends. At that point gcc2 was finally removed (..along with a lot of old a.out/static architecture cruft that had accumulated).

Now that LLVM/Clang is in, the potentially viable platforms (i386/amd64/armv7?) can work toward switching, while gcc4 remains for the ones that can't yet. I believe m88k is only gcc3 platforms left, but there's a very passionate guy in Japan interested in keeping his OMRON LUNA-88K and LUNA-88K2 workstations alive.

This may all seem strange, but OpenBSD has always strongly been against cross-compiling beyond perhaps initial platform bring up. This means being able to compile a release and packages on the physical machine must work.

mips, ppc and sparc64 are in theory fine on llvm already, in practice there are issues but nothing that can't be worked through, especially given past work OpenBSD has shown on gcc. All 3 are commercially viable for at least a decade.

m88k and sh4 are the odd ducks, and if there were a backend wow that would be painful to build llvm on natively :)

What is the value in continuing to support Alpha, SGI, and PA-RISC?

Were they cool in their day? Sure. But the consumer router you use to hook up an O2 or an Octane to the internet has a more powerful MIPS CPU.

There have been many advantages to running on different platforms, which have various quirks.. different endians, page sizes, strict alignment requirements, stack-grows-up machines (hppa).

It also helps to have systems that are slow or have low memory, occasionally they hit bugs that are unnoticed on modern hardware.

Alpha may have been interesting in that it had some peripheral similarities to PC machines, but were actual 64-bit computers in the 90s. For kernel driver hackers, popping in a PCI network card that was probably never tested on anything besides a x86 PC, getting it to pass packets, and then making it your home firewall, was a thing of beauty.

you interested in one? I got openbsd and openvms disks for you and the machine itself. You can have that beauty again. You can put it next to the HPPA you'll be getting as the door prize.

That's tempting, but I'm probably not nearby. If you're really offering hardware, SCSI disks etc. OpenBSD developers surely might jump at the chance.

http://www.openbsd.org/want.html

There have been many advantages to running on different platforms, which have various quirks.. different endians, page sizes, strict alignment requirements, stack-grows-up machines (hppa).

I think that trying 'oddball' platforms indeed help shaking out bugs. But if that's the goal (rather than supporting the five users that still use such hardware), wouldn't it be more attractive to build pseudo-platforms in an emulator that simulate other architecture choices, and run it on fast and easy-to-get x86_64 hardware?

You don't find races and bugs on emulators the same way as on real hardware. Also, if you do find a bug in your emulated environment, how much time would you spend wondering if the emulator is bad or your code? Also, there is a real chance that the emulator would let stuff pass (like allowing code make memory or bus access on odd address or some other restraint) which really shouldn't be allowed and you would not notice it.

I think of machines like these (disparate architectures (endianess, buses, processors)) as sort canaries, or watchmen for Good Code. NetBSD (my preferred OS) is the same in supporting multiple architectures with one codebase, and I like to think it strengthens the operating system for all platforms.

> But the consumer router you use to hook up an O2 or an Octane to the internet has a more powerful MIPS CPU.

Which consumer routers have 64-bit MIPS CPUs? I thought they'd mostly settled on mediocre 32-bit CPUs.

The Ubiquiti "EdgeRouter" series features Cavium Octeons. They're moderately fast MIPS64 SoCs with hardware offload for a lot of common network operations.

OpenBSD does have a port for the ER series, but it's separate from the SGI MIPS ports:

https://www.openbsd.org/octeon.html

How good is that edgerouter hardware? The price is pretty attractive.

(I just realized that's a pretty subjective question but I actually am interested in the opinion of someone who has interest in the odd corners of openbsd)

I have one for my gigabit connection at home and quite like it. It's able to hit about 933mbps to WAN->LAN which is important.

Note: I don't use OpenBSD on it, just the default OS which is a custom roll of Debian.

It's worth noting that hitting that performance relies on hardware acceleration not available on OpenBSD. I've read it can still manage ~100 mbps on OpenBSD which should be good enough for most people. But keep that in mind if you want serious routing performance and OpenBSD.

Is that a hardware acceleration of some portion of the network stack that's not carrying over to OpenBSD?

It's certainly not a problem for me if that's really just a limit on bandwidth, and not some kind of additional CPU load or network latency.

I believe the router relies on a binary blob that lets EdgeOS (based on Vyatta which is based on Debian) offload routing to some specialized hardware.

I run a OpenBSD router in a PC Engine Apu1d and it's more than fast enough. I can hit 700+ mbps on iperf with a basic pf rule set. Since OpenBSD is in the middle of updating their network stack to enable SMP I'd bet that number will rise with the next couple releases. I found mailing list posts from a year ago that have the iperf benchmarks of the apu1d right at 500 mbps. I'm interested to see if the network changes that landed in 6.0 will mean a measurable difference. This is entirely academic on a 30 mbps connection but I like it when numbers change.

An Octane is still much more powerful than your average consumer router. Don't underestimate the value of memory bandwidth.

That said, the real reason these platforms continue to exist because volunteers continue to maintain them. You would have to ask those individuals what value they derive from the hobby.

There are a lot of 10+ year old pa-risc machines out there than cannot be replaced. I remember an optic fiber network currently in use that had embedded pa-risc in underwater equipment, which means they had to be under maintainable for the 25 years of useable life of the cable.

If anyone knows some similar example please let us know.

Usually this comes coupled with a period-correct OS, i.e. HP-UX.

Yes, you could do an image loader for HP-UX bins on another OS, but that level of technical competence is rare.

The reason why OS people do ports - portable software is good software. Avoiding ISA monoculture avoids shortcuts in kernel architecture. Some ISAs (alpha, sparc64) easily trigger invalid assumptions on ordering, alignment, endianness, etc improving overall quality. Alternative archs are also a great way to learn about areas of the system that are "done", so you can go fix and improve the things that were assumed to be "done" once you have requisite background.

The value is probably that there are OpenBSD developers who want to continue supporting these platforms.

Running on such systems keeps the developers honest. No mass produced CPU implements as aggressive visible memory access reordering as Alpha AXP CPUs and SPARC faults on unaligned memory accesses while other platforms "just" take a performance hit.

Reply on news.ycombinator.com