[lkml]   [2000]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: large memory support for x86
On Fri, 13 Oct 2000, Chris Swiedler wrote:
> Why is it that a user process can't intentionally switch segments?
> Dereferencing a 32-bit address causes the address to be calculated using the
> "current" segment descriptor, right? It seems to me that a process could set
> a new segment selector, in which case a dereference would operate on a whole
> new segment. Is there a reason why processes are limited to a single
> segment?
> chris

You can (although not in user-mode). The problem is; "What RAM do you
reference?". You have 32-bits worth of addressing available in some
machine that has 32-bits worth of addressible RAM.

What can be done is to set one page to be 'not present'. Then, when
you page-fault, the page-fault handler can set some bit(s) in a
hardware page-register to map in another bank of RAM that isn't in
use yet. In principle, this would allow access to (2^16/8 -1) * (2^32 -1)
unique areas of RAM (segment descriptors are 16 bits, but they are
numbered in increments of 8.

So, you now want to copy from a segment addressed by DS, back to your
original DS, you have to rewrite the 'C' runtime library to use
'full pointers', i.e., DS:ESI, ES:EDI, etc., with ES and ES being
different. You have to dereference the full pointer on avery access!

Caching has to be turned off when RAM values that may be in the cache
reference RAM that is not back-switch in. You would have a slow mess.

However, in principle it could work.

Dick Johnson

Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.090 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site