Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: looking for >32-bit address space
Message-ID: <1989Apr7.194933.4861@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1032@myrias.UUCP> <1989Apr3.164538.277@utzoo.uucp> <2516@scolex.sco.COM>
Date: Fri, 7 Apr 89 19:49:33 GMT

In article <2516@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes:
>>And please, let us not hear solemn pronunciamentos about the supposed
>>40-bit address space of the RT -- it has a 32-bit address space, plus
>>8086ish bank-switching.
>
>The 8086 doesn't bank-switch.  The Apple //e bank switches.  The 8086 uses
>segments, which are similar, but, IMHO, better...

How so?  As far as the programmer is concerned, it really doesn't make
much difference.  Either way, a complete address is larger than the
"natural" pointer size, and you can't use it directly -- you have to
feed the segment/bank part into the machinery separately, and *then*
use the rest of the address.  (Sometimes the compiler can do this for
you, but the efficiency penalty remains.)  Which gets us back to
abominations like "near" and "far" pointers and all the rest of the
8086 sludge.

*Real* segments, as on the Multics machines, are part of the normal
pointer format, and to access something in a segment, you just indirect
through the pointer.  One can argue about the merits of breaking the
linear address space up into segments, but the point is that normal
pointer manipulation is not penalized in either efficiency or simplicity.

The real problem with >32 bit addresses is that avoiding the dreaded
Intel Pointer Syndrome requires a 64-bit word.  Which costs more than
a lot of people want to pay just now.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu