9 ms·

> The only reasonable thing would be having exotic architectures around to ensure the kernel is as portable as possible and doesn't make any weird assumptions.

by cesarb 3y ago

> The only reasonable thing would be having exotic architectures around to ensure the kernel is as portable as possible and doesn't make any weird assumptions. Some of these "weird assumptions" are necessary or useful for either performance or maintainability reasons. Having special cases for exotic architectures makes the kernel harder to change, and makes it harder to refactor it to user better code and data structures. That's, for instance, the reason support for the original Intel 386 was removed. Yes, this makes the kernel less portable, but that's a tradeoff.

chasil 3y ago
SPARC is big-endian, and is likely the greatest correction to coders who maintain "all the world's a VAX!" Much gdb has been spilt on these shores. Both the VAX and x86(-64) are little-endian. The Itanium could run either, but was little-endian by default (HP-UX would toggle to big-endian).
- yjftsjthsd-h 3y ago
  Fascinatingly, ARM (aarch64) can also do either; while the only operating system I know about that uses this fact is NetBSD, I have actually run that in big endian mode on a Raspberry Pi (3b) and it does actually work.
  - chasil 3y ago
    That is a really interesting fact.
    - yjftsjthsd-h 3y ago
      Right? I honestly don't yet understand why ARM designed BE mode into their shiny new architecture, but it's sweet that we have easily-available hardware that supports it.
- sillywalk 3y ago
  Interestingly (for some) "Through compiler and OS support [HPE NonStop OS] runs in Big Endian from the user’s perspective [ on x86-64 Xeon]" [0] Big Endian, how does it work? The x86 is little endian, right? • The compilers byte swap data items before placing them into memory for program variables • Does not apply to non-program variables such as return addresses pushed onto the memory stack • The OS along with the debuggers make the view complete • But if you just scroll through memory you can see a mix of Big and Little endian datums • Allows for binary data to be exchanged between Itanium and x86 systems without any special handling • In particular, messages sent via Expand between a NonStop x86 based system and a NonStop Itanium system require no extra handling. [0] https://dan-lewis-fns9.squarespace.com/s/NonStop-X-Overview-V3.pdf https://dan-lewis-fns9.squarespace.com/s/NonStop-X-Overview-...
iforgotpassword 3y ago
That's not entirely correct, the 386 simply lacked features and required cumbersome workarounds. I was more thinking of things like weaker memory models which can uncover concurrency issues.

by cesarb 3y ago

chasil 3y ago

SPARC is big-endian, and is likely the greatest correction to coders who maintain "all the world's a VAX!" Much gdb has been spilt on these shores. Both the VAX and x86(-64) are little-endian. The Itanium could run either, but was little-endian by default (HP-UX would toggle to big-endian).

yjftsjthsd-h 3y ago
Fascinatingly, ARM (aarch64) can also do either; while the only operating system I know about that uses this fact is NetBSD, I have actually run that in big endian mode on a Raspberry Pi (3b) and it does actually work.
- chasil 3y ago
  That is a really interesting fact.
  - yjftsjthsd-h 3y ago
    Right? I honestly don't yet understand why ARM designed BE mode into their shiny new architecture, but it's sweet that we have easily-available hardware that supports it.
sillywalk 3y ago
Interestingly (for some) "Through compiler and OS support [HPE NonStop OS] runs in Big Endian from the user’s perspective [ on x86-64 Xeon]" [0] Big Endian, how does it work? The x86 is little endian, right? • The compilers byte swap data items before placing them into memory for program variables • Does not apply to non-program variables such as return addresses pushed onto the memory stack • The OS along with the debuggers make the view complete • But if you just scroll through memory you can see a mix of Big and Little endian datums • Allows for binary data to be exchanged between Itanium and x86 systems without any special handling • In particular, messages sent via Expand between a NonStop x86 based system and a NonStop Itanium system require no extra handling. [0] https://dan-lewis-fns9.squarespace.com/s/NonStop-X-Overview-V3.pdf https://dan-lewis-fns9.squarespace.com/s/NonStop-X-Overview-...

iforgotpassword 3y ago

That's not entirely correct, the 386 simply lacked features and required cumbersome workarounds. I was more thinking of things like weaker memory models which can uncover concurrency issues.