devine@vianet.UUCP (Bob Devine) (08/19/87)
In article <2163@xanth.UUCP>, kent@xanth.UUCP (Kent Paul Dolan) writes: > Is it just me, or has anyone else noticed how C is being warped, made > ugly and complex, because ONE microprocessor manufacturer [Intel] couldn't > see fit to provide a flat, linear address space? This argument boils down to "If 'C' was good enough for a PDP-11, it should be good enough for any machine!". There are changes for many different machine architectures, not just chips with 64K-itis. A Modern Story -------------- See Intel. See Intel chips. See person wearing 3-piece suit counting the millions of Intel chip computers in marketplace. See person wearing 3-piece suit hiring computer nerds. See computer nerds get paid big bucks to work with C on Intel chips. See C computer program. Run program run. See person wearing 3-piece suit getting big sales and now counting millions of bucks. Prologue: This story has been told at Microsoft, Lattice, Lotus, IBM... And may be coming to a theater near you.
ron@topaz.rutgers.edu (Ron Natalie) (08/20/87)
> > Is it just me, or has anyone else noticed how C is being warped, made > > ugly and complex, because ONE microprocessor manufacturer [Intel] couldn't > > see fit to provide a flat, linear address space? > This argument boils down to "If 'C' was good enough for a PDP-11, it > should be good enough for any machine!" PDP-11's can't provide a flat linear address space either. You are limited to 64K text and data (or 64K each if you have split I/D). Note that this is exactly the same as small model on the 80x86. The best we ever managed in a coherent fashion was text overlays (medium model). Note that the NULL problem is caused by not working is because you are not guaranteed to have a zero at physical location zero. On PDP-11's you had instructions there (remember seeing programs printing p&P6). People who assume NULL's were careless VAX programmers. We're still finding these traps in 4.2 BSD ported to 68000's and other UNIX boxes that are not VAXes. Acheiving portability is done by not designing unimplementable constructs into the language, not by stating that certain machines should not be allowed to exist. -Ron
mouse@mcgill-vision.UUCP (09/07/87)
>>> [H]as anyone else noticed how C is being warped, [...] because ONE >>> microprocessor manufacturer [Intel] couldn't see fit to provide a >>> flat, linear address space? >> This argument boils down to "If 'C' was good enough for a PDP-11, it >> should be good enough for any machine!" > PDP-11's can't provide a flat linear address space either. You are > limited to 64K text and data (or 64K each if you have split I/D). > Note that this is exactly the same as small model on the 80x86. The > best we ever managed in a coherent fashion was text overlays (medium > model). So, Ron, what *is* a "flat linear address space"? As far as I can see, a PDP-11 provides a lovely flat linear address space, it's just that it's restricted to 64k. Even the Intel chip we all love to hate provides such an address space: it's called a "segment" and is, like most machine's address spaces, limited in size. All current machines, as far as I know at least, restrict the size of the address space (some of them have a smaller limit than others, of course). Does this mean there are no machines out there with this magical "flat linear address space" you are talking about? Or is it only that machines whose address space is small enough to chafe don't get this title? der Mouse (mouse@mcgill-vision.uucp)
peter@sugar.UUCP (Peter da Silva) (09/22/87)
It's got nothing to do with the size of the address space. It just means that any addressible object should be adressed by an object that acts just like an integer: i.e., you can increment it up to the limit of the address space, or decrement it to 0, or have a single object as large as you can fit in your address space. The reason 64K doesn't seem so cramped on the PDP-11 is that (1) the PDP-11 instruction set is more powerful and allows denser coding than on the 80x86, and (2) PDP-11 UNIX is usually V7, which is very small and fast by comparison with later efforts. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today?
rwhite@nusdhub.UUCP (Robert C. White Jr.) (09/23/87)
In article <882@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes: > >>> [H]as anyone else noticed how C is being warped, [...] because ONE > >>> microprocessor manufacturer [Intel] couldn't see fit to provide a > >>> flat, linear address space? > > So, Ron, what *is* a "flat linear address space"? A "flat linear address space" is a particularly apt discription of exactly what INTEL does NOT provide. Because the Segmenting and segment registers used by the x86 family are the way they are, there are many valid segment-offset pairs which refer to the same actual mechanical place in memory. Consider this: The alignment types for a data in the x86 environment are : byte, word, dword, paragraph, and page. There is also a missing "seg" but we will get back to that later. Because of these alignments there is an intresting anomality in the INTEL structure. the very first byte of memory in an intel machine may only be reached by the segment/offset of 0/0, the 16th may be reached by 0/16 or 1/0 the 32nd may be reached by 0/32, 1/16, or 2/0. Until you are beyond the first 64k of memory each additional 16 bytes adds one the the number of POSSIBLE methods to reach that single byte. There is a platu of sorts after 64k that ends in the last 64k of memory with FFFFh/FFFFh being only reachable in that one form. The mathimatical model is in the form [in binary]: Segment 0000000000000000 Offset 0000000000000000 + ____________________ Address xxxxxxxxxxxxxxxxxxxx where would one consistantly apply a SINGLE zero (0) to this addition, so that a comparison of the result to zero is consistant? The problem is that the frame of refrence to to heaped with possible combinations for a single constant to do. Other systems [68000 for example, (or so I have been told)] do not have a bit overlap. There is one and only one way to get to a memory address because the segment and offsets align like follows: Segment: 0000000000000000 Offset: 0000000000000000 + ________________________________ Address xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx In this model there is an actual 32bit register which represents the address [the segment and offset are logical subparts of a whole register]. That one register may be set to a constant zero (0) and be true consistantly. The WHOLE address is a real quantity in this model, as opposed to the aggrate of two parts in the INTEL model. In this latter model the "segment portion" may be only a few bits long, instead of a full word, but the general idea remains the same. If you consider the "depth" to be the number of possible was of acheiving an address, the INTEL model is heaped prety deep in the middle while the other model is in fact "flat and linear" Rob ("so who asked you?") White.
johnl@ima.ISC.COM (John R. Levine) (09/29/87)
In article <104@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >In article <882@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes: >> So, Ron, what *is* a "flat linear address space"? > A "flat linear address space" is a particularly apt discription >of exactly what INTEL does NOT provide. Because the Segmenting and >segment registers used by the x86 family are the way they are, there >are many valid segment-offset pairs which refer to the same actual >mechanical place in memory. Well, yes and no. If you're on a 286 or 386 running in user mode, your address space is still segmented but the segments are usually disjoint, so there is only one address for any addressable location (disregarding the obnoxious fact that the low two bits of the segment number are mode bits which are ignored in user mode.) It may not be linear, but it's flat. But this misses the point. Too many of the postings here seems to suffer from a myopia that sees only two machine architectures, the Vax (and its cousins, the 32000 and 68000) and the 8086. There are a lot of other machines out there that do not have linear byte-addressable memory. For example, Unisys makes two mainframe lines, the ex-Burroughs line with 48 bit words, and the ex-Sperry Univac line with 36 bit words. Honeywell or their French sucessors also make a word addressed 36 bit line. CDC makes a sixty-bit line with character strangeness that put the "packed" keyword into Pascal. I hear there are even a few PDP-10s and DEC-20s still running. All of these machines have addressing hacks that let you address characters, but the way you address a word is invariably simpler than the way you address a character, and you can't turn a word pointer into a character pointer without fiddling a few bits. C has been running on most of these machines for quite a while, in the Honeywell case for a lot longer than it's been on a Vax. It's entirely possible to write reasonable portable C code that runs on any of them. But you can't assume that all pointers are interchangeable, nor that there is a word of zeros at location zero. It is a tribute to the elegance of dmr's design that the data model of C fits so well on all of these machines without adding a lot of crud to the language. The 8086 has nothing to do with it. (If I were in the mood for a cheap shot, I'd mention that C actually fits the 8086 quite badly, which is why 8086 C has extra keywords like near and far and cdecl to get around its peculiar segmentation, and I don't see near and far anywhere in the standard.) -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something The Iran-Contra affair: None of this would have happened if Ronald Reagan were still alive.
rwhite@nusdhub.UUCP (09/30/87)
In article <727@ima.ISC.COM>, johnl@ima.ISC.COM (John R. Levine) writes: > [ lots-o "Whare did that come from?" deleted ] > (If I were in the mood for a cheap shot, I'd mention that C actually fits the > 8086 quite badly, which is why 8086 C has extra keywords like near and far and > cdecl to get around its peculiar segmentation, and I don't see near and far > anywhere in the standard.) In your asside you finally got the point to the thread! I was not being "blind" to the existance of other machines. This thread [at leas as much of it as I've seen] dealt only with the fact that the x86 family IS BADLY DESIGNED FOR AN IMPLEMENTATION OF C!! You apparently see x86 and loose it compleetly in any rational argument on the subject. The logical proposition these postings are based on is: 1) There is usually, but not always, more than one way [and more often like 256 ways] to reach any particular byte of memory. 2) Point 1 is not consistantly true within it's own scope. 3) It is an understandable fact that this is the case, given the development of the x86 family. 4) There are LOTS of other arcitectures <sp?> out there without this basic problem. THEREFORE: IT IS NOT A GOOD THING TO TRY TO AMMEND THE C STANDARD BECAUSE OF ONE DAMAGED ADDRESSING SCHEME. I only used the 680xx family because I, and I felt enough others, would understand the refrence. If I knew enough about the other machines you mentioned, I might comment further on the subject. <FLAME!> IF YOU WOULD _READ_!!! THE POSTINGS BEFORE YOU GET ALL HOT AND BOTHERED ABOUT THEIR ALEGED CONTENT, YOU WOULD PROBABLY NOT BE BOTHERED QUITE SO MUCH BY USENET IN GENERAL. <no_flame> Rob ("Who asked you anyway?") White.