Newsgroups: comp.arch
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)
Message-ID: <VFIA832@xds13.ferranti.com>
Organization: Xenix Support, FICC
References: <3310@crdos1.crd.ge.COM> <1991Apr04.023845.3501@kithrup.COM> <1991Apr04.230953.15294@kithrup.COM>
Date: Fri, 5 Apr 91 19:27:34 GMT

In article <1991Apr04.230953.15294@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
> In article <CIHATJ7@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> >If wrapping around the end of the segment isn't a problem, I can't. If it
> >is, I'll just operate on a >4 GB object.

> No, you missed the point.  I set things up such that no single object can be
> larger than 4Gbytes.

No, I didn't miss the point. If I have a 48 bit wide VM address and can't
operate on any object larger than a 32 bit wide pointer can address, then
it's a problem.

> On an 8086, the natural limit for the size of any given object is 64K.  On
> the hardware I described, it would be 4G.

OK.

> Now, please show me a correct program that will fail.

Any program that operates on an object larger than 4 GB.

> Answer: you can't, because The Standard (ANSI, in
> this case, since I'm more concerned about C) has enough limits in it that
> you can't get around it without being non-conformant.

I see. I'm talking quality of implementation, and you're talking language
legalese. In a minute, I'm going to ask an important question... in the
meantime, I'll play your game... ignoring for the moment every other
programming language in existence.

> Please read ANSI, and if you can find a statement in there that says that
> the system must provide for an object >4GB, then I will send you a case of
> beer.

Is there a statement in it that the system must provide for an object
greater than 64KB? Not that I can see... for the very good reason that
it would otherwise be extremely difficult to implement an ANSI C compiler
on the most common commodity personal computer in existence.

Now, here's the important question: why is the 64K object size limitation
in the IBM-PC a problem? After all, you cannot write a correct program
that will fail on it. You cannot legally determine that the maximum
object size is >64K.

Ah, you say, that's different. Nobody would ever need a single object
larger than 4GB. After all, there are hardly any computers that let you
address more than that, and they're all mainframes and supers. Of course
the same arguments were given about the 64KB limitation in the 8088 back
in the late '70s when *it* was under design.

(and no, it's not 20-20 hindsight: I was appalled at the choice of the 8088
in the IBM-PC when it first came out... and that was before they screwed
up the 80286 segment registers when they had a chance at fixing things)

> It *is* a segmented machine; you cannot wrap around segments, because the
> largest size of any single object is 4Gbytes.  Now, if you wanted to provide
> for a pseudo-64-bit address space, you have the system a) allocate segments
> sequentially, and b) when a segment-overrun trap occurs, increment the
> segment tag index appropriately, and continue.  But it's still a segmented
> machine.

If it quacks like a duck...

> And, again, note that *you* never see the segments.  It's possible to set up
> the machine such that it looks like a normal 32-bit-address machine;

Right, but then why bother with the extra address space?

> >Nah, just make int=32 bits, long=64 bits.

> That would be inefficient; too many people use 'long' when they don't need
> to,

Too many people use "short" when they don't need to, also. Correctly written
programs (correct in terms of being intentionally written portably, not by
some legalistic measure) don't have that problem. ANSI C has to cater to too
much old, broken code. I choose not to.
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"
