Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!psuvax1!psuvm!dxb132
From: DXB132@psuvm.psu.edu
Newsgroups: comp.arch
Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)
Message-ID: <91090.131157DXB132@psuvm.psu.edu>
Date: 31 Mar 91 18:11:57 GMT
References: <1991Mar27.172325.10800@sj.nec.com> <7920@uceng.UC.EDU>
Organization: Penn State University
Lines: 22

In article <7920@uceng.UC.EDU>, dmocsny@minerva.che.uc.edu (Daniel Mocsny) says:

>Almost everybody probably can agree that segments do lousy
>things to the programmer. (Even though I do my best to hide behind

What segmentation scheme are you talking about?

Let me expound a little on a segmentation scheme mentioned earlier. You
have 64 bit addresses, with 32 bits of offset and 32 bits of segment
number. There are no programmer-visible segment registers, no "memory
models" or such crap. This kind of scheme solves some sticky problems.
For example, it offers a solution to memory fragmentation. Each allocated
memory region is assigned a unique number (the segment number), and the
application manipulates only the offset. The OS can move memory regions
around in physical memory to eliminate fragmentation. Also, we can make
these segments an exact length, not neccessary always a multiple of
4K like paging schemes. That may sound a little inefficient compared
with paging, but your Unix system crashing after a few weeks due to
memory fragmentation has to be inefficient too.
What do you think; am I too idealistic? :-)

-- Dan Babcock