Re: using more than 2 GB as a ram disk
Alain Williams (addw@phcomp.co.uk)
Thu, 4 Feb 1999 19:16:44 +0000
On Wed, Feb 03, 1999 at 10:32:10PM -0500, David Wragg wrote:
> Actually, I think that big as the segment overhead is, it wouldn't be
> the biggest overhead. Undisguised segmented pointers are sufficient to
> implement plain ISO C, but if you wanted to port real applications
> (and libraries, OS kernels, etc) to such a system, it would need to
> present a flat memory space. There are at least three significant
> costs to this:
>
> 1) Pointer arithmetic. Imagine offsetting a segmented pointer, so that
> it crosses a segment boundary. Expensive normalisation would be
> required. By overlapping neighbouring segments by a hefty margin (e.g.
> 1MB), and lots of cleverness in the compiler, it may be possible to
> avoid most of the normalizations, but some will remain.
>
> 2) Long would have to be 64-bits, to allow pointer->long and
> long->pointer casts to work as most C programs expect.
>
> 3) Most C programs also expect things like:
>
> (T*)((long)pointerToT + sizeof(T)) == pointerToT + 1
>
> So in order to make the pointers cast to long look like a flat 64-bit
> address space, pointer->long and long->pointer casts have to involve
> shifting bits around.
It reminds me of the old days using Xenix on '286, and the 5 different
memory models that you got with C on MSDOS:
int 16 bits
long 32 bits
There were compiler switches to control pointer size:
code * 16 or 32 bits )
data * 16 or 32 bits ) gives 4 different combinations
The 5th was HUDGE, but can't recall what
was special about it.
You also needed 4 versions of libraries.
It all worked, but was vile, I hated it. It was done because that was
the only way of doing it on an 8086/80286 -- unless you were sensible
enough to move to a motorola 68k.
OK, so do this vile hack, I will hate it. If I really need to go > 2Gb I
will be sensible & move to an alpha (or something).
Cheers
--
Alain Williams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/