Path: utzoo!utgpu!watmath!watdragon!watsol!tbray
From: tbray@watsol.waterloo.edu (Tim Bray)
Newsgroups: comp.arch
Subject: Re: unconventional architectures
Message-ID: <13688@watdragon.waterloo.edu>
Date: 9 May 89 20:49:44 GMT
References: <112@centaure.UUCP> <422@unicads.UUCP> <11579@cgl.ucsf.EDU> <89May6.165030edt.10782@ephemeral.ai.toronto.edu> <1989May6.234007.23517@utzoo.uucp> <89May7.001514edt.39763@neat.ai.toronto.edu> <40284@think.UUCP>
Sender: daemon@watdragon.waterloo.edu
Reply-To: tbray@watsol.waterloo.edu (Tim Bray)
Organization: U. of Waterloo, Ontario
Lines: 20

In article <40284@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
> Multics and Burroughs segments, however, don't get in the way in that
> manner, unless you want to have a single object that doesn't fit in a
> segment (in the case of Multics, the max size is 1MB). ...
> Unless a program cares about segments, it can ignore them.

Hear ye!  Segments are evil.  If my usable address space is N, it is a priori 
*wrong* to assume that I won't mind dealing with segments of any size < N.

A trivial example: In processing the OED, it is often desired to take a couple
thousand matches to some search pattern, and group them, for example, by 
containing entry, of which there are 290 thousand.  If you have the memory
(we do, this is a 32M machine), the simplest and best way to do this is
to represent the entries by an array of 290K pointers and do a Hwang&Lin
type merge through them.  Now assuming that my pointers are about 32 bits in 
size, I've just blown the totally artificial 1-Mb restriction.

32 bits is barely liveable as it is; if an application wants to segment
its memory, that's hunky-dory, but let me use my 32 bits the way I want.
Cheers, Tim Bray, New OED Project, U of Waterloo, Ontario