4 ms·

Yet, they dropped support for i386DX and some older (386) Cyrix?

tremon 4y ago
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. )
- xxpor 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
    https://devblogs.microsoft.com/oldnewthing/20190404-00/?p=102383 https://devblogs.microsoft.com/oldnewthing/20190404-00/?p=10...
    - xxpor 4y ago
      of COURSE there's a Raymond Chen blog post about this :D
- tinglymintyfrsh 4y ago
  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).
johnklos 4y ago
The toolchains dropped support for the i80386, not the OSes directly. Intel, as they're known for doing, half-assed many things. Even though the 32 bit mode on the i80386 wouldn't be compatible with i8086 real mode and they could've made vast improvements, they decided to make just a mediocre 32 bit CPU, since they figured most people would just be running it as a super fast i8086. The m68020 in 1984, by comparison, was much more forward thinking. It had atomic operations, could exist in a multi-processor environment much more easily than an i80386, and it can still run a modern OS (NetBSD) in 2022.
- tedunangst 4y ago
  None of this actually relevant to openbsd dropping 386 support 15 years ago.
  - sidkshatriya 4y ago
    > None of this actually relevant to openbsd dropping 386 support 15 years ago. Well, I think the argument being made (implicitly) was: If Intel had made a decent and capable implementation of 386 with forward looking CPU instructions etc. 386 could have been alive and kicking today in many more operating systems and platforms.
    - tedunangst 4y ago
      It's more like the PC platform has continued to evolve in many ways, and 30 year old museum pieces aren't particularly interesting. Contrast with the mac68k platform, which is frozen in time. You don't see anybody trying to build one kernel that boots on every Mac ever made because the CPU has changed several times, but it wouldn't be pleasant even with continuity.
      - pseudostem 4y ago
        IIRC, the argument from the developers on OpenBSD misc mailing lists is that developing on 30 year museum pieces gives them perspective on the difference between right and wrong. It exposes them to more "stuff" than if it were the other way around.

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. )

xxpor 4y ago
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 4y ago
  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 4y ago
    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 4y ago
  https://devblogs.microsoft.com/oldnewthing/20190404-00/?p=102383 https://devblogs.microsoft.com/oldnewthing/20190404-00/?p=10...
  - xxpor 4y ago
    of COURSE there's a Raymond Chen blog post about this :D
tinglymintyfrsh 4y ago
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).

johnklos 4y ago

The toolchains dropped support for the i80386, not the OSes directly. Intel, as they're known for doing, half-assed many things. Even though the 32 bit mode on the i80386 wouldn't be compatible with i8086 real mode and they could've made vast improvements, they decided to make just a mediocre 32 bit CPU, since they figured most people would just be running it as a super fast i8086. The m68020 in 1984, by comparison, was much more forward thinking. It had atomic operations, could exist in a multi-processor environment much more easily than an i80386, and it can still run a modern OS (NetBSD) in 2022.

tedunangst 4y ago
None of this actually relevant to openbsd dropping 386 support 15 years ago.
- sidkshatriya 4y ago
  > None of this actually relevant to openbsd dropping 386 support 15 years ago. Well, I think the argument being made (implicitly) was: If Intel had made a decent and capable implementation of 386 with forward looking CPU instructions etc. 386 could have been alive and kicking today in many more operating systems and platforms.
  - tedunangst 4y ago
    It's more like the PC platform has continued to evolve in many ways, and 30 year old museum pieces aren't particularly interesting. Contrast with the mac68k platform, which is frozen in time. You don't see anybody trying to build one kernel that boots on every Mac ever made because the CPU has changed several times, but it wouldn't be pleasant even with continuity.
    - pseudostem 4y ago
      IIRC, the argument from the developers on OpenBSD misc mailing lists is that developing on 30 year museum pieces gives them perspective on the difference between right and wrong. It exposes them to more "stuff" than if it were the other way around.