Hacker News Reader

Hacker News

Comment by ThinkBeat | Hacker News Reader

Full thread

ThinkBeat

All to me entirely unnecessary steps required to get the CPU into the correct mode is astounding.

They all seem to be steps needed for backwards compatibility.

Could Intel just provide a flag, command, to start in the right mode from the beginning.

Or just remove all the backwards compatibility.

I think I remember doing some research and ARM64 has some of the same issues.

Are there any CPUs that are designed from scratch as 64 bit it will not have any need for backwards compatibility and would enter the required state by default?

I guess sthat was the goal / design of Itanium?

are made to start in the desired 64 bit state from th

View on HN

This is what Intel's proposed X86S [0] is designed for.

> X86S is a legacy-reduced-OS ISA that removes outdated execution modes and operating system ISA.

> The presence of the X86S ISA is enumerated by a single, main CPUID feature LEGACY_REDUCED_ISA in CPUID 7.1.ECX[2] which implies all the ISA removals described in this document. A new, 64-bit “start-up” interprocessor interrupt (SIPI) has a separate CPUID feature flag.

[0] https://cdrdv2.intel.com/v1/dl/getContent/776648 [pdf warning]

Intel tried that with the 80376 and it did not go well: https://en.wikipedia.org/wiki/Intel_80376

Neither did the Itanium (Itanic).

Backwards compatibility is the whole reason for choosing x86 over ARM, MIPS, RISC-V, etc. Sadly it seems some people at Intel and AMD don't realise this.

Backwards compatibility is good and necessary. But I don't think backwards compatibility going all the way back to the 8086 is. If someone has software written for the 8086 at this point, they would be far better served by running it in dosbox or something than on bare metal.

UEFI exists. You just put a Windows-like binary in a folder on a partition and it runs in a hosted environment in 64-bit mode. And of course there's countless bootloaders that can take care of all this for you too.

And then you're free from dealing with the somewhat convoluted processor init stuff, but instead depend on the Windows PE format, FAT filesystem, and an overcomplicated API.

Seems like a bad tradeoff, and part of a slippery slope towards a completely locked down system, where writing your own code and getting it to run on the 'bare metal' is flat out impossible.

What's wrong with depending on the Windows PE format, FAT filesystem and UEFI? You're always going to have some dependencies. FAT32 is better than having the first sector load some magic reserved sectors. Windows PE is better than a fixed memory address.

It's adding pointless complexity, and baking assumptions about how an OS should work into the firmware. Loading a sector at a fixed memory address and jumping to it (with some function provided so that your code can go on to load other sectors) is both easier to understand, and doesn't require you to use some multi-megabyte toolchain.

Wouldn't it be better to use a header to specify to load multiple sectors at multiple memory addresses?

Yes, and considering that your boot sector is actually a boot cluster... You need not use compression. You could even steal the entire first cylinder. (Now that is old school)...

Unless you need to load anything else other than what's in that sector, because you can't fit enough I/O drivers into one sector to load the rest of the OS.

Unless you're targeting S/360, but even there XA and newer made it a bit more complex.

> instead depend on the Windows PE format, FAT filesystem, and an overcomplicated API.

Sometimes I wonder: if UEFI instead used ELF format, ext2 filesystem, and somewhat less complicated API (let's be honest: UEFI API is pretty straightforward if tedious), would people still complain about such dependencies? Or would it be deemed to be "fine" since it's not Microsoft technology even though it still would require one to use a multi-megabyte toolchain?

Yes, also probably if you used FDT instead of ACPI despite all the problems that are fixed by ACPI but present with FDT, because "ACPI is evil" :V

Its not the fact that its from Microsoft, its the fact that both FAT and PE are full of legacy cruft that is no less painful than going through real mode in the first place.

FAT originally only can do 8.3 filenames, but take a look at this to see what they hacked on top: https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#...

This is all the legacy shit you now have to implement when you want a so-called "legacy-free" boot. Infuriating.

Meanwhile ext family, even in ext4, requires that you handle optimizations decisions made for Fujitsu Eagle and its contemporaries.

I could easily read NTFS with hexeditor, calculator and pen&paper. Trivial even (most annoying part was the run length packing in 4-bit nibbles).

I gave up trying to read ext's cylinder-oriented mappings.

And FWIW, everyone has a read/write driver for FAT with LFN (and UEFI generally avoids names outside 8.3 just in case), using a different filesystem would lead to issues with OS support.

PE itself isn't really that much of legacy cruft, especially as far as it is used in UEFI (sure, you have the "program not for MS-DOS header", but that's useful for the rare case someone tries to open it under FreeDOS).

This is fine if you're only running on a single core, however if you're a multiprocessor OS you still need to deal with legacy when bringing up the other cores. Intel and AMD should consider a mode that disables that and brings up the other cores using a 64bit SIPI. While I applaud Intel on the X86S idea... I think there is room for bits of that without throwing out all the backwards compat. An X86SC which drops real mode and only supports 16bit 'real mode' in virtualization.

Yes, I see the argument that if you go to that point you might as well just use emulation. However running mixed 32bit/16bit code (Windows 98/95) becomes problematic just because of performance reasons. DosBox does well, but good luck supporting games for the Pentium 3 era that still used 16bit libraries because of course they did. (16bit Installshield was so common going into 64bit that MS just has code to replace it so 32bit applications can still be installed despite having a 16bit installer)

I vaguely recall there being some multicore stuff in UEFI, but it's been years since I looked at it.

Intel did a prototype of a multiprocessor UEFI application that would start up cores and UEFI itself does support synchronization on the assumption that applications/bootloaders will start other cores before calling ExitBootServices. However, there are no protocols as of 2.10 (the current spec[1]) that I can find that would bring up another processor. That said searching it can be a bit arcane.

[1] https://uefi.org/specs/UEFI/2.10/index.html

It's part of the PI spec rather than the base spec: https://uefi.org/specs/PI/1.8A/V2_DXE_Boot_Services_Protocol...

Interesting, very interesting. Curious that the PI spec doesn't include update dates on the versions. The MP spec was introduced in 1.5 and I have no idea when that was released.

What’s wrong with arm64?

Reply on news.ycombinator.com