Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!darkstar!kithrup!sef From: sef@kithrup.COM (Sean Eric Fagan) Newsgroups: comp.arch Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers) Message-ID: <1991Apr06.030330.1533@kithrup.COM> Date: 6 Apr 91 03:03:30 GMT References: <1991Apr04.023845.3501@kithrup.COM> <1991Apr04.230953.15294@kithrup.COM> Organization: Kithrup Enterprises, Ltd. Lines: 109 In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991Apr04.230953.15294@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes: >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. Why is everybody harping on this 48 bits wide? I actually never said anything about how wide the address space, except that I implied that it was at least 32 bits. In fact, given the machine I proposed, it would still work quite well with only a 32-bit address space. And that's the difference between the flast and the segmented: using the segmented version (which, as I pointed out two articles ago, can imitate, if slowly, a flat-address-space machine), I can hide the fact that I only have 32-address bits, virtual or otherwise. >> Now, please show me a correct program that will fail. >Any program that operates on an object larger than 4 GB. Please read that agin, peter. You assumed, incorrectly, that I had more than 32-bit for addressing. You assumed that, if I cannot allocate a 5Gbyte object, things are broken. Guess what: they're not. >Is there a statement in it that the system must provide for an object >greater than 64KB? Nope, and it's not broken in that respect. (I believe ansi c has a requirement that an implementation must support a single object of at least 32k characters.) >Now, here's the important question: why is the 64K object size limitation >in the IBM-PC a problem? Peter: not all people who run into memory problems need more than 4Gbytes for a single object. Some people do; that's why I organized things in my machine the way I did. For people who don't (i.e., people who just keep doing malloc's to get more memory dynamically), they will never know that the machine can access more than 4Gbytes, assuming, of course, it can. Since I purposefully kept int's and long's at 32 bits, there is no way to specify the size of an object larger than 4Gbytes. How are you going to know about it? >After all, you cannot write a correct program >that will fail on it. You cannot legally determine that the maximum >object size is >64K. Actually, for ANSI C, yes, you can. You can use size_t for that purpose. And it's all perfectly legal. >Ah, you say, that's different. Nobody would ever need a single object >larger than 4GB. No, I never said that at all. I know for a fact that there are people who want to be able to have single objects larger than 4Gbytes. They are by far in the majority, however, largely because no system most of them are using today allows them to. I admit freely that 32-bits is a limit. But my question stands still: please show me a Correct (by K&R II, ANSI, or POSIX standards) C program that will fail on the system described by: struct pointer { unsigned long segment; unsigned long offset; }; typedef unsigned long size_t; typedef long ptrdiff_t; ASSERT (sizeof(void*) == 8); ASSERT (sizeof(__longlong) == 8); ASSERT (sizeof(long) == 4); You cannot even *write* a C program that tries to declare a single object with more than 4Gbytes (except by trying to pass something of type __longlong into malloc, which will then only look at half of it or fail, as the system wishes). Since size_t is a 32-bit number, that precludes trying to do double foo[50000][50000]; Now, once again: please show me a Correct C program (defined above) that will fail on the system as I have defined it. Please note that, although a pointer is 64-bits, I have said nothing about how large the address space is. I refuse to, as, since the way I've organized the machine, IT DOESN'T MATTER. (For example: a 68k has 32-bit pointers, but it's address space is only 16Mbytes. I guess peter and company consider that a broken machine, huh? Because it's not possible to use up all of the address space implied by the size of the pointers, that is?) For people who want to have objects larger than 4Gbytes, if they pay me enough money, I will give them a special compiler and library that will allow it. (As I said, that requires a little bit of work.) >Right, but then why bother with the extra address space? Actually, I want it because having every object in its own segment is an incredibly useful thing. I've made compilers and runtime libraries do that under xenix for the '286, and it has made debugging broken programs easier. (Found routines that ran off the end of areas they malloc'd, for example, because I got a SIGSEGV as soon as it happened.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.