Bregalad wrote:I never programmed any 8086 compatible machine in assembly, so I have absolutely no idea what you're talking about.
- 16-bit: real mode
- 32-bit: protected mode
- 64-bit: long mode
Real mode gave you 1MB of address space, split in 64KB segments (each segment being 16 bytes apart - yeah there was overlap, what it did was basically segment * 16 + offset). Opcodes were less orthogonal as well (e.g. you couldn't do LEA arbitrarily). There were four segment registers: CS (code), DS (data), ES (extra) and SS (stack). The ES segment was mostly to help with operations working across two segments
(e.g. copying data)
Protected mode, besides making instructions more orthogonal and making the default register size 32-bit, gives you access to up to 32GB (though Windows likes to see only 4GB unless you mess with a registry entry) and provides a MMU with paging (which means a virtual address range can be mapped onto arbitrary non-consecutive physical ranges). A given segment may be up to 4GB long, and there are four rings (0, 1, 2, 3) each given different execution privileges. Segments could be code or data, and could be 16-bit or 32-bit (regarding executing code). Accessing an invalid address triggers General Page Fault aka what we call segfault. As you can imagine all this complexity means segments aren't addresses anymore, instead they're indices into a look-up table with all the segment properties, and it also meant that changing a segment register costs a very large amount of cycles (not to mention cache flushing). There were also two more segment registers (FS and GS).
...and most of that went ignored as usually only two rings would be used (for kernel and user space) and programs would normally just have three segments (code, data, stack) simulating a "flat" address space within each process and the segment registers only ever being touched by the kernel. Go figure.
Long mode gets rid of all that segment mess and just enforces a flat address space (aside from keeping FS and GS because Windows uses them to hold thread-specific data >_>). It also doubles the amount of registers (all
, not just the integer ones) and extends the integer ones to 64-bit, and gets rid of some rarely used opcodes. Essentially it's a much lean version of protected mode that happens to also support 64-bit operations =P
Going forward, free software should be recompiled for x86-64, and proprietary software should be packaged in a "snap" container
Er, pretty sure you misunderstood both. Snaps are meant for all
binaries (64-bit ones too), and they won't magically make 32-bit programs work out of nowhere if the kernel doesn't support it, which is the real problem from what I gather (hence the VM idea - it's literally about emulating those old programs). Only way snaps would work is if they actually included the full blown VM themselves and wrapped the program in it.
Also that won't help with stuff like DOSBox that still doesn't have a dynamic recompiler for 64-bit (so a 64-bit build is stuck with the slow interpreter), and I'm not sure how feasible is that. (on that note: somebody work on that please =P)