Using the task register to switch between tasks

[rdos]

I think hardware task-switching was usable (and efficient) back when CPUs only had a single core. I don't think Intel originally thought about the problems their hardware task-switching would cause in multicore systems. I only dropped hardware task-switching when I moved to multicore.

I question a bit the need for long mode today. I had an application that uses up to 100GB of physical memory, but I also found out that by creating a smart algorithm that analyzed only part of the data at a time, then mapping this large physical area into 2M windows in 3G linear memory really isn't a problem.

I think long mode is mostly a need for applications that are poorly designed. My 32-bit OS certainly didn't stop me from analyzing 100GB of data I streamed over PCI.

After all, PAE paging can map just as much physical memory as long mode can.

A big address space also makes things simpler. Think something like having a memory mapped file representing your database. Sure, you can have windows into that file in a 32-bit address space, but with 64-bits to play with, you can reasonable map the entire database file into memory and simply use pointers to navigate. Simpler code often means fewer bugs, and lower maintenance costs.

Plus, it sounds like your algorithm could analyze your stream in self contained chunks. What if you can't do that, and you need random access to your data (such as the database example above.)

It's not just about address space, though. Long mode opened up other opportunities, such as adding extra registers, and the jump from 8 to 16 GPR probably had a big positive effect on performance.

The inability to use 64-bit registers in 32-bit code is mostly a design flaw by AMD. When Intel moved from 16 bits to 32 bits, they also created overrides that made it possible to use 32-bit registers & addressing in 16-bit code.

Too simplistic code often creates slow code. When code uses random access the cache is poorly utilized with many cache misses. The cost of cache misses is also doubled in long mode since long mode use four paging levels to handle 48-bit addresses. So, I wouldn't exactly say that using random access in long mode is always a good solution for good performance. It might be if random access is inevitable, but if accesses can be more localized, fewer cache misses will be the result and the code would run much faster.

[sj95126]

The inability to use 64-bit registers in 32-bit code is mostly a design flaw by AMD. When Intel moved from 16 bits to 32 bits, they also created overrides that made it possible to use 32-bit registers & addressing in 16-bit code.

The two situations aren't quite the same. In order to use 64-bit registers, you often need REX prefixes, and those opcodes were taken in 32-bit mode. A number of instructions were discontinued and their opcodes reused in long mode. Override prefixes would have been messy.

Intel's big mistake (besides keeping x86 going for 40+ years) was to waste so many single-byte opcodes in the original design, as evident by the fact that virtually everything added in the 286 and later required 0Fh prefixes. I doubt anyone expected the original design to last this long. I think if you went back to 1978 and told Gordon Moore about today's CPUs, he'd fire everyone there.

[thewrongchristian]

The inability to use 64-bit registers in 32-bit code is mostly a design flaw by AMD. When Intel moved from 16 bits to 32 bits, they also created overrides that made it possible to use 32-bit registers & addressing in 16-bit code.

I think if you went back to 1978 and told Gordon Moore about today's CPUs, he'd fire everyone there.

Nope, he'd buy all their stock options back off them

[rdos]

The inability to use 64-bit registers in 32-bit code is mostly a design flaw by AMD. When Intel moved from 16 bits to 32 bits, they also created overrides that made it possible to use 32-bit registers & addressing in 16-bit code.

The two situations aren't quite the same. In order to use 64-bit registers, you often need REX prefixes, and those opcodes were taken in 32-bit mode. A number of instructions were discontinued and their opcodes reused in long mode. Override prefixes would have been messy.

These instructions could have been discontinued in the new 32-bit compatibility mode too, and allowed the use of 64-bit registers.

The worst thing about the whole design is that 32-bit loads in compatibility mode will destroy the upper 32-bit of the 64-bit registers, making it extremely complicated to use 32-bit handlers in long mode.

Intel's big mistake (besides keeping x86 going for 40+ years) was to waste so many single-byte opcodes in the original design, as evident by the fact that virtually everything added in the 286 and later required 0Fh prefixes. I doubt anyone expected the original design to last this long. I think if you went back to 1978 and told Gordon Moore about today's CPUs, he'd fire everyone there.

No, the fact that it has been around for so long means it was a superior design. It's only a pity that compilers never could handle segmentation properly, and that the switch to 64-bit turned off segmentation instead of fixing the problems with 16-bit selectors.

[Octocontrabass]

These instructions could have been discontinued in the new 32-bit compatibility mode too, and allowed the use of 64-bit registers.

But if you did that, it wouldn't be compatible.

The worst thing about the whole design is that 32-bit loads in compatibility mode will destroy the upper 32-bit of the 64-bit registers, making it extremely complicated to use 32-bit handlers in long mode.

Modern x86 CPUs are actually a custom architecture with an x86 translator on top. This feature would require the custom architecture to implement two sets of 32-bit operations: one set that clears the upper 32 bits to break dependency chains, and one set that preserves the upper 32 bits. It would only be useful in this specific circumstance.

The added expense of implementing this feature is far greater than the added expense of a temporary 64-bit wrapper to call your 32-bit handler while you work on a 64-bit version.

No, the fact that it has been around for so long means it was a superior design.

68k was the superior design. The only reason we're not all using 68k-based PCs right now is because the 68000 wasn't ready in time for IBM to put it in their PC.

It's only a pity that compilers never could handle segmentation properly, and that the switch to 64-bit turned off segmentation instead of fixing the problems with 16-bit selectors.

I disagree, but this thread isn't a good place for another argument about segmentation.

[rdos]

The added expense of implementing this feature is far greater than the added expense of a temporary 64-bit wrapper to call your 32-bit handler while you work on a 64-bit version.

I so no reason why I would work on a 64-bit version. The bulk of the drivers are 32-bit segmented and I have absolutely no intention to rewrite them for 64-bit as that would have no benefits, rather would reintroduce the nightmare of a completely unprotected address space. Instead, I find the possibility to run some 64-bit applications on top of my 32-bit segmented OS by switching that particular process to long mode and then let the normal drivers handle IO in compatibility mode. Part of this worked fine when I worked on it a couple of years ago, but the bug with the upper halves of the registers is annoying.

[nexos]

For me, the biggest advantage of 64 bit mode is the fact that you get 8 more general purpose registers, which greatly speeds up the kernel.