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)