Notices by Miod Vallat (miodvallat@hostux.social)

Hey, I wrote this.

http://miod.online.fr/software/openbsd/stories/propolice.html

#openbsd

25 years ago (and a couple months), I got my hands on my first few m88k systems.

Back then, there had been no #OpenBSD release for this platform ever completed due to compiler (gcc 2.8 back then) bugs, we were using a.out binaries without shared libraries, and I had zero knowledge of gcc internals.

Today, OpenBSD/luna88k, which runs ELF binaries and shared libraries, has been switched to PIE userland by default, using gcc 4.2.1: https://freshbsd.org/openbsd/src/commit/NstsoXqDBQGMNHRP

What a journey it has been!

@whitequark To be fair, it's the linker which is passive-aggressive here 😋

@crowdagger Ça s'appelle une salle de shoot, ça !

@dalias Never underestimate that .0000000001% ROI probability!

@dalias Talking about Jeff Atwood again?

Side-quest in the gcc/m88k work: on 88100, the DIV instruction is expensive (38 cycles). It is a bit less expensive on the 88110 (18 cycles), but still a heavy cost compared to other instructions.

Gcc has logic to try and replace a divide by a constant, by a multiplication by its inverse in a Z/2**NZ ring if a proper N can be found. In other words, instead of dividing, it will multiply by a large number, and shift the result to the right by 32 bits.

1/n

Most processors have a 32x32 -> 64 integer multiplication routine, and with this you only need to keep the upper 32 bits of the result and you're done.

(I'm taking shortcuts in the description, but this is quite close to what needs to be done).

On 88100, integer multiply costs 3 cycles. Even with some overhead to compute the result after this multiply, this will still run circles around the DIV logic. 2/n

I noticed that, when compiling with the `-m88110' option, this "replace a div by a constant with magic mult" logic would fire. And give a ~50% speedup for the operation.

But not when compiling without any processor selection option, or when compiling with `-m88100'.

This is because, in the not-targeting-88110 case, the compiler intrinsic for integer divide is more complicated (a "define_expand" rather than a "define_insn"), and this is likely preventing the optimization from being tried. 3/n

So the side quest is to figure out whether there is a way to cause this logic to trigger, and only fallback to the convoluted 88100 logic (which is there for $REASONS, such as early processors not causing a trap when dividing by zero...) when no suitable multiplication logic can be applied. 4/4

And it turns out this was a quick side quest, and a failure: the reason why this logic only triggers when targetting the 88110 is because only the 88110 has the 32x32->64 multiply instruction. 88100 can only do 32x32->32 which is useless here.

There goes a good idea...

It looks like it took me 7½ months to mentally recover from 3 years of bad career choices and forgettable jobs and be back to full brain power.

That's quite a toll these bad choices took on me.

Votre créature sauvage d'Ardèche du jour.

Edit: on me souffle dans l'oreillette qu'il s'agit d'une Rosalie des Alpes.

@whitequark Linker refuses to be checked!

@jpmens isn't supposed to mean ``Remote Holy Code Execution'' in this case?

Student Miod, you'll have a bad grade, and it will be carved in stone for eternity!

@mwl 2025 is a fad. Won't last long - a year at most, probably even less.

@mmu_man Justement, France Travail rend libre.

(désolé)

@joachim On appelle ça de la taboulimie.

#gameoftrees discussion between @stsp and tb@. I now understand why there's ``game'' in the name.

#openbsd