Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!spool.mu.edu!munnari.oz.au!metro!cluster!rex
From: rex@cs.su.oz (Rex Di Bona)
Newsgroups: comp.arch
Subject: Re: Adding fire to the segmentation flamefest...
Keywords: segments: do they really suck?
Message-ID: <2275@cluster.cs.su.oz.au>
Date: 8 Apr 91 10:16:58 GMT
References: <9234@lkbreth.foretune.co.jp> <45180@super.ORG> <9244@lkbreth.foretune.co.jp>
Sender: news@cluster.cs.su.oz.au
Reply-To: rex@cluster.cs.su.oz (Rex Di Bona)
Distribution: comp
Organization: Basser Dept of Computer Science, University of Sydney, Australia
Lines: 24

In article <9244@lkbreth.foretune.co.jp> trebor@lkbreth.foretune.co.jp (Robert J Woodhead) writes:
> For example, consider the proposal that was made in a recent message on this
> topic, for a 32 bit segment and 32 bit address.  If that was implemented in
> the memory system (so that the cpu goes "duhh, here is a 64 bit address,
> gimme my memory, dude!") then you get the best of both worlds; you can treat
> your memory as a 64 bit address space, or you can have up to 2**32 segments
> 2**32 bytes long, or you can have segments >2**32 bytes long that just happen
> to be set up as 2 or more contiguous segments by the OS.

The only problem is what happens when you move your pointer from
0x0000 0000 ffff ffff (spaces for clarity) up by a character? Does it go
to 0x0000 0000 0000 0000 or does it go to 0x0000 0001 0000 0000 It is
the difference in these two answers that differentiate a 'real' 64 bit
flat address space from a truly segmented address space. If I wanted
objects greater than 2^32 bytes I would prefer the former. If I was
satisfied with smaller objects, but better ways? of handling them I
would stay with the latter.

I don't know, I still can't see anything (besides backward
compatability :-) that segments provide that cannot be provided with
flat addressing, and a smarter? virtual to physical translation.
--------
Rex di Bona (rex@cs.su.oz.au)
Penguin Lust is NOT immoral