The point is not that this scheme is a good idea, or at all useful,
except possibly from a marketing viewpoint. The usual exchange isn't
about usefulness:
Person A: Recent Intel x86s can address 64GB transparently to userspace
by using segments.
Person B: No they can't, read the manuals.
Given what A probably had in mind, B's response is good enough, so
that it has become a knee-jerk reaction for many people. However,
pedantically speaking, an OS *could* be implemented for which A's
claim is true. Would Albert or anyone else volunteer to write this
(based on Linux or any other kernel)? I doubt it. But that doesn't
make it impossible.
(As for Albert's bragging rights, I claim precedence: See
<URL:http://www.dejanews.com/getdoc.xp?AN=415355834>)
Albert D. Cahalan then wrote:
> Usefulness requires a CPU that can handle segment issues quickly.
> The Pentium Pro is hopeless, but the Pentium II might be OK enough.
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.
These are in addition to the segment load costs. A 2x slow down will
probably be a *best-case* scenario for typical C programs.
Dave Wragg
-
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/