OSDev.org

Correct me if I'm wrong. 64-bit addressing is due to the fact that there was not enough memory pointer length. Why aren't programs shared modularly and not addressed like this? I believe that 4 rings are more than enough for this, if used correctly. However, in the x86-64 architecture this has changed as well.

Please elaborate.

alexfru wrote:Please elaborate.

My guess is that you can divide the program into composite, dependent modules at different levels and organize communication between them. With this, perhaps 32 bit addressing will be more than sufficient.
If I'm not mistaken, there is no programming language for such purposes. But I have not seen similar concepts among OS hobbies. Everyone uses only 1 and 4 rings.

What have rings got to do with address size?

Of course 64-bit addressing is not necessary; but it makes life a lot easier, so why not?

iansjack wrote:What have rings got to do with address size?

I don’t know English well, so I didn’t accurately state my thoughts. I apologize.
I meant why large programs that do not fit into 32-bit addressing are not divided into parts?
For example, these modules can be held on different rings. As I imagine it. There is a program with various modules: graphics, computing and others. The main part is placed, for example, in ring 3, modules in ring 4. A special API provides interaction between them.
This way they are safe from each other and use less memory space.

I can see how you can make life more difficult by using a smaller address space. But I can't understand why you would want to. It only makes the programs more complicated and less efficient.

grenders22 wrote:My guess is that you can divide the program into composite, dependent modules at different levels and organize communication between them. With this, perhaps 32 bit addressing will be more than sufficient.

If you don't run into fragmentation and leaks, sure.

grenders22 wrote:If I'm not mistaken, there is no programming language for such purposes.

Probably there isn't one. Do we really need it?

grenders22 wrote:But I have not seen similar concepts among OS hobbies. Everyone uses only 1 and 4 rings.

The x86 protection/privilege levels/rings do not extend address ranges. The 2 least significant bits of a segment selector are not used as part of an index into the GDT or LDT. They're only used for privilege checks.

There are, however, Page Address Extension (PAE) and Page Size Extension (PSE-36) that can turn 32-bit virtual addresses into longer physical addresses.

grenders22 wrote:But I have not seen similar concepts among OS hobbies. Everyone uses only 1 and 4 rings.

As others have already pointed out, protection rings have nothing to do with address space size.

The reason why everybody (hobby and mainstream OSes alike) is using only 2 of the rings, because not all architectures provide more. Most CPUs can only handle 2 levels (user and supervisor). For example on ARM, you have EL0 (equivalent of ring 3) for the user processes, and EL1 (equivalent of ring 0) for the kernel, and that's it. There's no equivalent for ring 1 and 2. (There are upper levels like EL2 and EL3, but those are for providing virtualization, more similar to SMM and VM86 mode). Any code that requires more than 2 levels would be tied to the x86, and wouldn't be portable by design.

Cheers,
bzt

I don't think a 64-bit address space is needed unless we are talking about really complex stuff. When it is needed, it's mostly because data is huge. You can bank data in 32-bit mode with PAE paging, and this means you can access all of your physical memory regardless of how much you have. I've done this myself on a machine with 100 GB of physical memory, and 2/3 of it filled with ADC sample data. I first allocate 2MB physical pages and fill them with ADC data through PCI express from an FPGA and then I map them at the page directory level to a 2MB large virtual page. I need a few thousand calls to remap, but the time to do this is much smaller than the actual time to analyze the data. If multiple pages are needed at the same time, it's possible to allocate several 2MB virtual pages. The performance problem in that project had nothing to do with 64-bit address spaces, rather with how to use the 12 cores of the CPU effectively so the calculations could run parallel.

Another way to do it is to run multiple applications at the same time, or use fork() to create multiple address spaces so part of the address space can be shared while part of it is private.

I feel people only need 64-bit address spaces because they are lazy.

Besides, the address space of long mode is only 48-bits, and not 64. And when you setup long mode, the paging hardware will require twice as many reads as with PAE paging since it uses four paging levels, which will result in twice as much overhead for TLB misses.

I have a hunch that the reference to "four rings" had nothing to do with protection rings and was about the four data segment registers on the x86/x64 CPUs. The statement "However, in the x86-64 architecture this has changed as well" would be referencing the fact that 64-bit mode uses a flat address space and DS/ES values are ignored.

I think what was suggested is that if you can juggle multiple 4GB segments by updating segment pointers, you don't need 64-bit addressing to access a reasonable amount of memory.

The problem with this is it can't last for long. Remember that everyone used to think that 1 MB was enough on the 8086. And the last thing anyone wants is different versions of applications and OSes where "this one works as long as you only have 4/8/16GB of data and if not you need the other one".

To answer the subject from my point of view: No, 64-bit addressing is not necessary for any task, but it eases development; it's one less challenge when dealing with data sets greater than 2-4GiB. What about code? If someone can explain to me why anything ever needs >4GiB code in a way I can't answer with "Forth programs typically have 10x smaller code size," I will be very interested! (Disclaimer: I don't remember the actual figure, but I'm sure it's more than 4x. It's relative to C.) I'm told Plain English Programming has even more compact code.

sj95126 wrote:I have a hunch that the reference to "four rings" had nothing to do with protection rings and was about the four data segment registers on the x86/x64 CPUs. The statement "However, in the x86-64 architecture this has changed as well" would be referencing the fact that 64-bit mode uses a flat address space and DS/ES values are ignored.

I think what was suggested is that if you can juggle multiple 4GB segments by updating segment pointers, you don't need 64-bit addressing to access a reasonable amount of memory.

None of that obviously work since all selectors are based on 32-bit bases and if base+offset gets larger than 4G it will wrap around. The rings are just selectors with another RPL field.

It would have been different if segment descriptors had been extended to 64-bits, bit instead segmentation was disabled in long mode.

sj95126 wrote: The problem with this is it can't last for long. Remember that everyone used to think that 1 MB was enough on the 8086. And the last thing anyone wants is different versions of applications and OSes where "this one works as long as you only have 4/8/16GB of data and if not you need the other one".

Banking works fine and has no limit for how much of physical memory that can be accessed.

eekee wrote: If someone can explain to me why anything ever needs >4GiB code in a way I can't answer with "Forth programs typically have 10x smaller code size," I will be very interested! (Disclaimer: I don't remember the actual figure, but I'm sure it's more than 4x. It's relative to C.)

Large data. Have you looked at download sizes of recent AAA video games? It's like they don't even know the word "restraint" any more. And I'm pretty sure those things aren't written in C.

That makes sense. Seeing how binary size bloated up over a decade ago made me wonder how far the bloat had gone, and initial discussion in this thread seemed to be about code size.

There is also the case of algorithms which sacrifice memory footprint deliberately to save time. Caching, precomputed value, that sort of thing. Memory bloat doesn't necessarily mean the program is less efficiently designed, just that design priorities have changed.

Obviously you don't need 64-bit addresses, but you very much need a >4GB working set these days. I think 64bit addressing is simply the most efficient way to do that with todays technology.