Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!bbn.com!mips2!granite!kittlitz
From: kittlitz@granite.ma30.bull.com (Edward N. Kittlitz)
Newsgroups: comp.arch
Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)
Message-ID: <1991Apr1.154918.8342@granite.ma30.bull.com>
Date: 1 Apr 91 15:49:18 GMT
References: <1991Mar27.172325.10800@sj.nec.com> <00670208556@elgamy.RAIDERNET.COM> <1991Apr1.045051.3220@grebyn.com>
Organization: Bull HN Information Systems Inc.
Lines: 21

In article <1991Apr1.045051.3220@grebyn.com> ckp@grebyn.com (Checkpoint Technologies) writes:
>Suppose you took a machine with a very large pointer; 32 bits will do
>for arguments' sake, but you could imagine this with 48 or 64 if you
>like.  Then let's say the operating system permits an application to
>have a sparse virtual address space.  Then applications could choose
>some number of upper address bits and designate those as "segment
>numbers", and the rest of the bits as "offset".
>
>Now, what significant differences exist between this and a "real"
>segmented machine?  I can't think of any offhand...

Segments give you access control. The 386 will
let you put multiple segments within one page, each with differing
differing access rights. I believe that such an architecture may
provide a convenient way for implementing protected object-oriented systems.
It would be better if they had a TLB instead of the one per segment-register
'shadow registers'/descriptor cache. (I must admit I don't know if
there is a TLB in the 486.)
----------
E. N. Kittlitz	kittlitz@world.std.com / kittlitz@granite.ma30.bull.com
Contracting at Bull, but not alleging any representation of their philosophy.