4 ms·
You know, I've spent the past two weeks tinkering with a toy x86_64 bootloader/kernel, and I think that x86 as an ISA is okay. Not great, but okay. Yes, 16-bit
by Joker_vD 6y ago
You know, I've spent the past two weeks tinkering with a toy x86_64 bootloader/kernel, and I think that x86 as an ISA is okay. Not great, but okay. Yes, 16-bit addressing modes are restrictive, the encoding hack that enables addressing of r8-r15 in the long mode is probably against one of Geneva conventions, the constant proliferation of control registers is vexing, and CPUID will one day probably be able to dump a full 10-volume PDF of Software Developer's Manual into the provided memory... but still, it's kinda okay.
But what's absolutely terrible is the interface between the CPU and everything else attached to the mainboard (and with the mainboard itself, for that matter). The interrupt handling somehow gets worse when moving from PIC to APIC, ACPI is nauseating, I/O ports are insanely opaque, and the default memory-mapped devices are organized in such a way that there are irreparable wholes in the physical address space that you can't use anyway. Having physical RAM start, say, at address 0x800000000000 and everything below it be MMIO would be pretty convenient, but it can't be arranged for legacy reasons. The legacy boot sequence is appalling. UEFI is marginally better, but is itself an impressive bag of worms.
Holy fatcats. I hope RISC-V will have saner peripherals, but kinda afraid that it won't either.
- userbinator 6y agothe constant proliferation of control registers is vexing You may want to look at the AArch64 "system registers" space... or the instruction encoding, for that matter. I think 32-bit x86 made the most sense and was well thought-out, but the 64-bit version was definitely not extended very well.
- Joker_vD 6y agoYep. It's le bon ton to frown at the x86's baroqueness, but other ISAs had their share of bizarre ideas as well: e.g. MIPS had no interlocks until MIPS-II, so every instruction had a delay slot. I personally liked the SIB byte from x86-32, it's a neat way to repurpose an ACU into basically another ALU.
- bogomipz 6y ago>"the encoding hack that enables addressing of r8-r15 in the long mode is probably against one of Geneva conventions ..." Might you or anyone else have any links or literature on what this hack is or how it works? >"the constant proliferation of control registers is vexing ..." I'm guessing this isn't referring to control registers proliferating on different of generations of CPUs at the discussion is about the ISA. Could you elaborate on how exactly they've proliferated?
- Joker_vD 6y ago> Might you or anyone else have any links or literature on what this hack is or how it works? Intel 64 and IA-32 Architectures Software Developer's Manual, volume 2, chapter 2.2.1 "REX Prefixes". I understand that there was literally no place in either opcode or ModR/M byte to squeeze in another bit, but still. As for control registers: we now have 9 "control registers", CR0 through CR8, and 4 of them are still reserved which kinda makes this whole "reserved" business seem pointless. And then, of course, there are MSRs, loads and loads of MSRs. In fact, there are so many of them that we now have a whole separate volume 4 of Intel SDM that is dedicated exclusively to them and is about 300 pages long. No doubt it will be 400 pages in the near future. Honestly, writing about this stuff feels like quoting from the "See Figure 1" doc.
- messe 6y ago> RISC-V will have saner peripherals Spoiler: It probably won't. ARM-based systems are even more of a mess than x86 in this regard, as they haven't been standardized up until the last few years when UEFI/SBSA started to be adopted. x86, while shit, at least followed approximate standards and systems were broadly compatible. I wish the world had standardized on OpenFirmware, it might have at least let us avoid the mess that it ACPI.