Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!cello!renglish
From: renglish@cello.hpl.hp.com (Bob English)
Newsgroups: comp.arch
Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)
Message-ID: <1991Mar27.193512.12417@cello.hpl.hp.com>
Date: 27 Mar 91 19:35:12 GMT
References: <23189@as0c.sei.cmu.edu>
Organization: Hewlett Packard Labs
Lines: 79

I suppose that I will get religion someday, but until then...

firth@sei.cmu.edu (Robert Firth) writes:
> No.  The major difficulty with a segmented architecture is that it's
> wrong, and the von-Neumann model is right.  This is not a language
> issue.  One of the most fundamental, and most pervasive, idioms in
> practical computing is the mapping function whose domain is a
> subset of the natural numbers, in other words
> 	array (0..max) of Object

If by this you mean that the image presented to the programmer should
allow large objects, I'd have to agree with you.  I differ, however,
with the equation of the data space a programmer perceives (that which
the compiler provides) and the native architecture of the memory system.
The two need not be the same.

"What about performance?" you scream in disgust (I can hear such screams
from around the country even as I type).

"What about performance?" I ask rhetorically, with a bemused look.

The segment sizes this forum has rejected out of hand address 4GB of
memory.  For all objects less than that segment size, a load of a
segment register to access the object should take exactly one cycle per
access to the object.  Less if the compiler/architecture team is wily
enough to know how to avoid such things.  In programs with less than 4GB
of data (and there are a few of them available in the world), this
segment register has to be loaded once per context switch, hardly
significant in these days of large CPU contexts.

"But there are objects greater than 4GB," you cry and move your fingers
to the 'n' key, unable to bear this stupidity any longer.

"Of course there are," I answer.

I would characterize such objects as belonging to three general types.

The first is a large object accessed in a regular way, a large array or
matrix, for example.  Segment loading and unloading in such an object
will be rare, because the compiler will know the segment boundaries and
be able to optimize them out of the code.

The second is a large object accessed unpredictably with no locality. 
While the compiler will not be able to predict the segmentation register
in such cases, neither will the cache be able to hold the working set,
so that miss penalties dominate the additional segment register loads.

The third is a large object accessed unpredictably, but with a high
degree of locality.  In such cases, loads and stores take up to one
additional instruction.  Only in this case do segments make any
difference in the performance of the machine, and even in this case the
difference is small.  I don't claim to be an expert in such matters, but
I suspect the number of applications fitting this last category is small.

All of this analysis assumes, of course, that a multi-op implementation
of a segmented architecture wouldn't have the ability to parallelize
segment loads.  Without that assumption, it's very difficult to char-
acterize the types of applications where segmentation presents perfor-
mance problems.

As far as I can see, the only time that a move to a non-segmented
architecture is justified from a performance and functionality
perspective is when the size of the segments is comparable to the size
of the system's cache memory.  With 4GB segments, that won't happen in
the next few years.

There are other justifications, however.  First, it could just be cheap
to make segments larger (excuse me, eliminate them entirely).  Second,
it could be cheaper to eliminate segments than to fix the compiler to
handler them correctly.  Third, it could be that the current cost is not
too high, and projections over the life of the architecture lead the
designers to believe that 4GB caches will become important before the
next architecture revision.  Fourth, address/register size could be seen
as a differentiator in the marketplace, leading designers to match the
current "standard" in order to keep the customers listening.

--bob--
renglish@hplabs.hp.com
Not an official position of the Hewlett-Packard Company.