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: 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 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?"