[tremon]

IIRC, the 386 did not have atomic load/store operations (XADD, CMPXCHG), so it's much harder to write reliable semaphores/mutexes on that platform. I'm surprised OpenBSD supported it for this long.

(edit: it seems they didn't: OpenBSD/i386 hasn't actually supported running on [386sx/386dx] for some time. )

[tinglymintyfrsh]

I'm trying to remember from the last em64t/ia32e & ia32 ISA toy OS I messed around with.

i386 ISA is the bare minimum for functioning protected mode to be better than real-mode DOS. i286 protected mode is absolute trash.

i386 is so bad at dealing with SMP primitives, it was standard practice to have a non-SMP kernel. Then, you get into the business of maintaining 2 kernel flavors or a major kernel feature flag.

For those interested, there is a quirky processor mode trick called "unreal mode" that allows flat addressing without switching to protected mode (no protections, just like real-mode DOS).

[xxpor]

Is there an SMP version of the 386?

You may need locks on a non-SMP system (since you can still have concurrency), but without parallelism you don't need atomics... right?

[tremon]

The 386 still has hardware and software interrupts which might just happen between the load and store instructions, so it's not as simple as "we don't need atomics".

If you were writing code specifically for the 386, I suppose you could implement all semaphores as critical sections to guard against external interrupts; I see no reason why that wouldn't work. But realistically, that code would be more of a museum piece than something you'd want to maintain in a 2022 operating system.

[xxpor]

Ah interrupts, of course.

/me goes back to his polling-only application :)

(we have an interrupt, but it's "the watchdog fired and you're about to die anyway", so not exactly complex to handle...)

[my123]

https://devblogs.microsoft.com/oldnewthing/20190404-00/?p=10...

[xxpor]

of COURSE there's a Raymond Chen blog post about this :D