mash@mips.COM (John Mashey) (04/05/89)
In article <12289@reed.UUCP> mdr@reed.UUCP (Mike Rutenberg) writes: >>Are there any micros or chipsets out there that support an address space >>larger than 32 bits? >I assume you are asking about physical address space. Physical address space is, in some sense, the easier one to extend, in that it need not be visible to ordinary user programs. Also, 4GB will last a little while, although the end is in sight, of course. >Lots of processors, like the 386, 486, HP Prisim, and others support >virtual addresses of several terabytes, usually through the use of >multiple 32bit segments. Segments seem like an obvious way of doing >large address spaces while keeping the current technology chips fast. MVS/ESA does some sort-of-similar segment mapping to get equivalent effects, I think. >I don't know of any >32bit physical address space microprocessors. If >you have the money, I would suppose you could convince a manufacturer >like Intel to make a custom version of a chip for you. Somebody had >Motorola build a 68012 at one point, which was a 32 bit address bus 68010. The real issue is address-space extension versus software & implementation technology. 1) Segments are the obvious way to do the extension, but they have their drawbacks for general use, compared with flat-address-space models. In particular, everybody's idea of segmentation seems different, and so portable code seems nontrivial. 2) Flat 64-bit addressing has been, and will be for a lonnng time, too costly for most micros. One interesting issue, for some ways out, is what the 64-bit model ought to be be: maybe some of the mini-super and supercomputer folks can give us some hints here: What's the C programming model for machines with 64-bit pointers? how do you say 8-, 16-, 32, and 64-bit ints? (char and short are fine. Now, are 64s long-longs, or just longs? are 32s longs? which one is int? how much code breaks under these various cases? user code operating system code networking code Is there any chance of standardization? The other interesting input that people might be able to give is what they really do on the earlier-mentioned machines that have segments. Can anybody say how the two HP OS's use them? Can people talk about how RT PC's use them? Do any 386 UNIXes use them? How do they work in practice? Anyway, it would be nice to get real experience and data. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
faustus@dogwood.Berkeley.EDU (Wayne A. Christopher) (04/05/89)
In article <16568@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: > In article <12289@reed.UUCP> mdr@reed.UUCP (Mike Rutenberg) writes: > >>Are there any micros or chipsets out there that support an address space > >>larger than 32 bits? > > 2) Flat 64-bit addressing has been, and will be for a lonnng time, > too costly for most micros. Take a look at this month's Spectrum -- there's an article about the Intel i680 chip, which seems to have a flat 64-bit address space. We'll have to see how quickly this chip catches on -- it looks really hot (it benchmarks at twice the Dhrystones of the MIPS chip), but for manufacturers who don't want to double the size of their external bus it may be a bit too much. Wayne
tim@crackle.amd.com (Tim Olson) (04/05/89)
In article <11968@pasteur.Berkeley.EDU> faustus@dogwood.Berkeley.EDU (Wayne A. Christopher) writes: | In article <16568@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: | > In article <12289@reed.UUCP> mdr@reed.UUCP (Mike Rutenberg) writes: | > >>Are there any micros or chipsets out there that support an address space | > >>larger than 32 bits? | > | > 2) Flat 64-bit addressing has been, and will be for a lonnng time, | > too costly for most micros. | | Take a look at this month's Spectrum -- there's an article about the | Intel i680 chip, which seems to have a flat 64-bit address space. | We'll have to see how quickly this chip catches on -- it looks really | hot (it benchmarks at twice the Dhrystones of the MIPS chip), but for | manufacturers who don't want to double the size of their external bus | it may be a bit too much. Quoting from the i860 "64-bit microprocessor" manual, Chapter 4 (Addressing): "Memory is addressed in byte units with a paged virtual-address space of 2^32 bytes. ... Address arithmetic is performed using 32-bit input values and produces 32-bit results." The i860 really is a 32-bit machine -- the 64-bit label seems to come from the 64-bit external bus, which is used to fetch two instructions/data words at a time for cache reload. Well, there is some support for 64-bit integers in the graphics unit (addition and subtraction), but not in general. -- Tim Olson Advanced Micro Devices (tim@amd.com)
w-colinp@microsoft.UUCP (Colin Plumb) (04/06/89)
faustus@dogwood.Berkeley.EDU (Wayne A. Christopher) wrote: > Take a look at this month's Spectrum -- there's an article about the > Intel i680 chip, which seems to have a flat 64-bit address space. No, it has a 32-bit flat address space. I think its external data bus and fp unit give it the right to call itself a 64-bit microprocessor, but the integer unit is pretty vanilla 32-bit. -- -Colin (uunet!microsoft!w-colinp) "Don't listen to me. I never do." - The Doctor
dave@lethe.UUCP (David Collier-Brown) (04/06/89)
In article <12289@reed.UUCP> mdr@reed.UUCP (Mike Rutenberg) writes: | Are there any micros or chipsets out there that support an address space | larger than 32 bits? From article <16568@winchester.mips.COM>, by mash@mips.COM (John Mashey): | The real issue is address-space extension versus software & implementation | technology. | 1) Segments are the obvious way to do the extension, but they | have their drawbacks for general use, compared with flat-address-space | models. In particular, everybody's idea of segmentation seems | different, and so portable code seems nontrivial. Well, I'm not sure **everyone's** is different, but there's certainly lots of (possibly sillly) variations. Reminds you of the early Christian Church, perchance? Portability is another matter: the model I'll discuss is portable to anything that can run c++ or Ada[tm]. | 2) Flat 64-bit addressing has been, and will be for a lonnng time, | too costly for most micros. I suspect for many mainframe manufacturers, too. | One interesting issue, for some ways out, is what the 64-bit model ought | to be be: maybe some of the mini-super and supercomputer folks can give us | some hints here: | What's the C programming model for machines with 64-bit pointers? | how do you say 8-, 16-, 32, and 64-bit ints? | (char and short are fine. Now, are 64s long-longs, | or just longs? are 32s longs? which one is int? | how much code breaks under these various cases? | user code | operating system code | networking code | Is there any chance of standardization? The C model seems to work well with a simple progression. Much user-mode code works on a 36-bit machine (with 72 bit longs) but dies due to enbedded ordering/size-relationship assumptions on machines with 16 bit ints and 64 bit longs. Source: experience with honeybuns (36) and rumor (16:64). | | The other interesting input that people might be able to give is what they | really do on the earlier-mentioned machines that have segments. [...] | Anyway, it would be nice to get real experience and data. Well, Mutlicks had to add two-level names to the programmer's view of the world, but little else. They used a different notation for two-level names in code as opposed to data, but the concepts seemed very very similar to the "." notation of concurrent pascal, C and Ada: io_module.element_size is a datum within some enclosing construct, possibly as large as a segment. (C, Ada, Conc. Pascal) io_module_$element_size is the PL/1 equivalent: some sort of natural maximum size that is specific to the io module... io_module.read(stuff) is a procedure call in language x io_module_$read(stuff) is one in Multics PL/1 In general, a segment in this view is just a top-level named thing, code or data, which is visible to the programmer and has substructure. You use it for grouping related things or things "used with" others. The problems with Multics segments were: They had size limitations which the programmers could see[boo!]. A segment was also a file[yay!], which caused the birth of the multi-segment file[duh]. (This was predicted, but people didn't believe they would suffer from the limitations as soon as they did). There were lots of them. The system did a good job dealing with them, but people soon learned to "bind" executables together into segments-as-packages for simple efficiency. (Packages were part of the design of the OS: I'm talking about mere applications programmers like me learning to use "binder"). The advantage was a natural means of referencing multi-level things, including "classes" and "packages", ideas which have now come to the fore. --dave (This is a **bit** different from intel segments) c-b
prc@maxim.ERBE.SE (Robert Claeson) (04/06/89)
In article <11968@pasteur.Berkeley.EDU>, faustus@dogwood.Berkeley.EDU (Wayne A. Christopher) writes: > Take a look at this month's Spectrum -- there's an article about the > Intel i680 chip, which seems to have a flat 64-bit address space. > We'll have to see how quickly this chip catches on -- it looks really > hot (it benchmarks at twice the Dhrystones of the MIPS chip), but for > manufacturers who don't want to double the size of their external bus > it may be a bit too much. Yes, and how often can you really take advantage of its ability to perform simultaneous integer and floating point operations? -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE
rw@beatnix.UUCP (Russell Williams) (04/07/89)
In article <16568@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >One interesting issue, for some ways out, is what the 64-bit model ought >to be be: maybe some of the mini-super and supercomputer folks can give us >some hints here: > how do you say 8-, 16-, 32, and 64-bit ints? > (char and short are fine. Now, are 64s long-longs, > or just longs? are 32s longs? which one is int? > how much code breaks under these various cases? > user code > operating system code > networking code Elxsi has 32 bit pointers but 64-bit registers. We originally made ints 32 and longs 64, and did manage to port sys V, but it was a real pain. Customers screamed, and we changed to 32 bit longs and 64 bit long longs. Networking code -- both ATT & third party -- is full of the 16/32/32 short/int/long assumption. HP had a pre-Spectrum project called Beta which had 64 bit registers and 64-bit pointers, with 16 bits of segment and 48 bits of offset. The idea was that even the largest databases could be made directly byte addressable. I don't know how they were going to deal with it in C. Russell Williams ..uunet!elxsi!rw ..ucbvax!sun!elxsi!rw