Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!necntc!linus!alliant!steckel
From: steckel@Alliant.COM (Geoff Steckel)
Newsgroups: comp.arch
Subject: Re: Is the Intel memory model safe from NO-ONE ?!?
Message-ID: <1735@alliant.Alliant.COM>
Date: 9 May 88 22:31:23 GMT
References: <1806@obiwan.mips.COM> <2904@omepd> <353@cf-cm.UUCP> <2411@louie.udel.EDU>
Reply-To: steckel@alliant.UUCP (Geoff Steckel)
Organization: Omnivore Technology, Newton, MA
Lines: 26
Keywords: 386 intel memory protection management model segmented
Summary: check the 386 again (ouch!)...

Segmentation (as a method for putting data structures in separate address
spaces) is a point on the vector towards capability machines, where the
descriptor also includes access control on a more subtle level than the
entire data structure.  While interesting and potentially useful, it seems
to be less useful than (say) a tagged architecture.  Note that tags and
capabilities are not mutually exclusive.

However, I assert that machines with segmented architectures which impose
limits on segment size or addressability smaller than the machine global
space will recieve flames comparable to the 16-bit maximum 808x series.
It is not the business of the machine designer to tell the programmer how
s/he must use the address space.  Programmers often must work at the far
end of a machine's capabilities - artificial addressing limits or kluged-on
address extensions cause either disastrous code or disastrous performance.

On the other hand, machines with implemented 30+ bit physical address
memory exist now, and more are being made daily.  Given the MIPS/megabyte
ratios, a 100+MIP machine could usefully use a physical and virtual space
greater than 32 bits.  This subject has arisen in the past year on this
newsgroup - my vote is for machines with 64 bit 'long's and 48+ bit pointers.

Yes, a whole lot of C code would break if INT and LONG aren't the same type.
However, if some of the compiler work devoted to rearranging the code to
run fast were devoted to a 'super lint' phase, it might not be so hard on
the poor programmer...

	geoff steckel (steckel@alliant.COM)