cstoneMar 5
Miod Vallat

Good morning! Today, the last part of the #OpenBSD/sgi story is available.

In this episode, hardware conditions documented as "Can't happen" happen, and support for one particular CPU model "everyone agrees will never get supported by free software" gets nevertheless written.

Read it at:
http://miod.online.fr/software/openbsd/stories/sgi6.html

You can also now read the whole story in one page:
http://miod.online.fr/software/openbsd/stories/sgiall.html

I'll return to the usual "new material on wednesdays" schedule next week.

OpenBSD on SGI, 6/6: The last challenges

Mar 5 at 5:46amWeb
Show threadLudovic :Firefox: :FreeBSD:Mar 5

@miodvallat very interesting series, can't wait for what might be coming up.

Nice details on plenty of #sgi hardware. #retrocomputing

Show threadmirabilosMar 5

@miodvallat hhwhuh?

the assembler will do an optimization pass itself and reorder instructions to get faster code.

The assembler? Its job is to assemble, not to optimise… does gas really do that?

FWIW, little-endian MIPS (o32 and n64) lived on in Debian until bookworm (released 2023-06-10), and for about a year and a half more in unstable; big-endian MIPS did indeed get removed earlier. Pity.

Show threadMiod VallatMar 6
@mirabilos MIPS defines many assembler instructions which are actually macros, which expansion will depend on the actual operands. In other words, the assembly output of the compiler is in fact an intermediate ("high-level") assembly language, which as(1) compiles into real assembly language.
Show threadmirabilosMar 6
@miodvallat yes, of course, but would it reorder instructions?
Show threadMiod VallatMar 7
@mirabilos To fill delay slots. The assembler can either let you handle delay slots in "noreorder" mode, or let you work as if they did not exist, and will reorder instructions so as to fill them as best as it can. This can be useful for beginners.
Show threadmirabilosMar 7

@miodvallat … ah.

I vaguely remember seeing them, but…

`move' `reorder' `volatile' These control whether and how the assembler may re-order instructions. Accepted for compatibility with the OSF/1 assembler, but `as' does not do instruction scheduling, so these features are ignored.

… and I only ever worked in “no reorder” mode in SPARC and what bit of MIPS assembly I hacked around back in FreeWRT days.

Delay slots did require some time to get used to them, mind-bending at first, but they are quite nice. (On SPARC, anyway.)

Show threadMiod VallatMar 7
@mirabilos That part of the documentation you're quoting applies to Alpha, not MIPS.
Show threadmirabilosMar 7
@miodvallat ah, but I cannot find anything else about reorder in the docs…
Show threadMiod VallatMar 7
@mirabilos This only shows that the documentation is incomplete. Good thing we also have the source code, don't we? In this case, gas/config/tc-mips.c
Show threadmirabilosMar 7
@miodvallat ah ok, TIL
Show threadStuart Longland (VK4MSL)Mar 5

@miodvallat Interesting prospective there… I saw things from the Linux/MIPS side of things.

I had a R4600SC 133MHz Indy (acquired in 2003) with 8-bit Newport graphics, never tried running OpenBSD on it, but it came to me running Irix and it was the first machine I tried Debian with. I'd later join the Gentoo/MIPS team and assist there.

I remember it being a cantankerous beast to get running with Linux 2.6, but it was quite stable with Linux 2.4, even in 64-bit mode. However, with no MIPS-III n32 or n64 stages, I was still stuck with a o32 userland.

Indigo2 R10000 was another… and yeah, I remember gcc needed a special patch for `-mcache-barriers` which was used when building the kernel. Get a dodgy kernel, and the thing was like an ice-skating hippo, interesting to watch but not pretty! The IP22 hardware was _not_ designed for a speculative-execution CPU like the R10000.

I seemed to recall some Linux support for the O2 R10000 (which was a bit better, there were some hardware features in the IP32 platform that allowed it to work), but it was in its infancy. Not sure if that extended to the R12000 O2.

Show threadTodd KnarrMar 6
@miodvallat "Can't happen" is inevitably a false statement. In software, if it really "couldn't happen", the compiler would be complaining about unreachable code. If it isn't, it's not "can't happen" but rather "must not be allowed to happen".
Show threadmirabilosMar 6
@tknarr @miodvallat this is a hardware thing tho
Show threadTodd KnarrMar 6

@mirabilos @miodvallat Same principle. If it really couldn't happen, your design software would've optimized those gates out of existence because they don't affect the outputs.

Related to the switch labelled "magic" and "more magic" and a note "do not change switch position".

Show threadmirabilosMar 6

@miodvallat @tknarr that’s… a very naïve worldview.

and a very mid-2020s worldview that does not apply to 1990s hardware

Show threadMiod VallatMar 6
@tknarr @mirabilos Well, the fact that the hardware had the ability to report this condition obviously hints it can happen. But documentation writers can be abused and write too confident sentencies 😋