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
chris@softway.oz (Chris Maltby) (04/10/89)
In article <16568@winchester.mips.COM> mash@mips.COM (John Mashey) writes: > 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 Elxsi has 64 bit registers but 32 bit addressing. When porting PCC it seemed clean at first to make char, short, int and long be 8, 16, 32 and 64 respectively. We learn't the error of our ways very early. There is just so much code which assumes: sizeof (int) == sizeof(long) or possibly (sizeof short) sizeof (void *) == sizeof(long) or sizeof(short) It was relatively easy to make the kernel understand this assignment. But although this arrangement is perfectly legal according to K&R it isn't according to most suppliers of commercial UNIX software. I agree with John's hopes. Before 64 bit machines become common, we'd better have worked out a standard representation for the basic types so that we have some hope of getting the writhing mass of ugly software working again. Being realistic - I don't think we have a chance... Still - it might send some "Dodgy-Brothers" software houses to the wall! -- Chris Maltby - Softway Pty Ltd (chris@softway.oz) PHONE: +61-2-698-2322 UUCP: uunet!softway.oz!chris FAX: +61-2-699-9174 INTERNET: chris@softway.oz.au
jed4885@ultb.UUCP (J.E. Dyer) (04/15/89)
In article <1326@softway.oz> chris@softway.oz (Chris Maltby) writes: >In article <16568@winchester.mips.COM> mash@mips.COM (John Mashey) writes: > [Stuff about C data types, and why it's a bad idea to make long ints] > [64 bits deleted to save bandwidth.] I was thinking about this today, and wondered why not change C slightly so that the size of an enumerated object (ints, chars, longs, etc) was explicitly defined. Perhaps int1, int2, int4, int8 etc would be a good way of doing it (i.e. the number of bytes would be explicityly stated in the definition). I think this would help make C more portable, as I've seen perfectly good (well not perfect...) C code break on various machines because ints were 16 bits on one machine and 32 on another. Of course you could do this with #define statements, but it shouldn't be too hard to write a compiler that deals with arbitrary sized ints (i.e. things like int16 etc.) in a fairly optimal way (are there any machines out there that won't let you do multi word arithmetic? I know the 680x0 series has an X bit or some such that makes this possible...). -Jason -sig-of-the-day- Disclaimer: "I'm just an undergrad." Bitnet: JED4885@RITVAX UUCP: Your guess is as good as mine. "I'm anti-war, but not necessarily anti-violence, ya know?" -John
peter@ficc.uu.net (Peter da Silva) (04/16/89)
In article <684@ultb.UUCP>, jed4885@ultb.UUCP (J.E. Dyer) writes: > I was thinking about this today, and wondered why not change C > slightly so that the size of an enumerated object (ints, chars, > longs, etc) was explicitly defined. Perhaps int1, int2, int4, > int8 etc would be a good way of doing it... I've suggested this before. I think syntax like: int:32 x, y; int:36 z; /* Unisys 1100 compatibility :-> */ int a:8, b:9, c:6; Ideally sizeof(char) should be 8 :->. I know, takenm to the extreme this'd break too much code. But expanding bit-feild syntax would help solvce some problems here... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
jwatts@hpihoah.HP.COM (Jon Watts) (04/18/89)
One problem with making integer sizes explicitly specified is that this would result in gross inefficiency when the specified size does not fit nicely into the word size of the machine it's running on. Or, stated another way, would require the programmer to know the 'natural' sizes on the machine he (she) is running on in order to write efficient code. I've given this some thought before and have not been able to think of any general way to specify the integer sizes that will not cause problems for quite a few programs. The best idea I've come up with is to have the programmer specify the required range for the integer (similar to enumerated types in pascal) and then have the compiler choose the smallest convient type which is large enough to accomodate the specified range. Note that it would be the programmers responsibility to insure that he does not exceed the range he specifies and he must not make any assumptions as to what the number will due if he does.
andrew@frip.wv.tek.com (Andrew Klossner) (04/18/89)
[]
"Perhaps int1, int2, int4, int8 etc would be a good way of
doing it (i.e. the number of bytes would be explicityly stated
in the definition)."
This would impose an eight-bit byte, binary, twos-complement model on
the computer's arithmetic, and would render the language unsuitable for
machines like the PDP-10 (36 bits) and older CDC machines
(ones-complement). Is the world ready for the constraints of this
model?
-=- Andrew Klossner (uunet!tektronix!orca!frip!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]jas@ernie.Berkeley.EDU (Jim Shankland) (04/18/89)
In article <11300@tekecs.GWD.TEK.COM> andrew@frip.wv.tek.com (Andrew Klossner) writes: >[Having types int1, int2, int4, ... in C] would impose an eight-bit >byte, binary, twos-complement model on the computer's arithmetic .... >Is the world ready for the constraints of this model? Probably yes, as a matter of practice. But if int1 were defined as an integer type having a range of *at least* -128 .. 127, int2 the same with a range of *at least* -32768 .. 32767, and so on, the constraints aren't quite as ... constraining. You can go ahead and use that 36-bit word as an int4. Jim Shankland jas@ernie.berkeley.edu "Blame it on the lies that killed us, blame it on the truth that ran us down"
paul@moncam.co.uk (Paul Hudson) (04/19/89)
Then they can be used in casts (say, in assigning values to bitfields). Then I can write compilers that give warnings for shortening assignments, without spurious warnings. Or even better, I can extend gcc to do so. Paul Hudson Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul Science Park, paul@moncam.co.uk Milton Road, "Sun Microsysytems: Cambridge, The Company is Arrogant (TM)" CB4 4FQ
viggy@hpcuhb.HP.COM (Viggy Mokkarala) (04/21/89)
I will attempt to answer some of the questions that were raised about HPPA during the course of discussion on this topic. In article <16568@winchester.mips.COM> (John Mashey) writes: (Discussion about address-space extension, and 64-bit address models removed.) >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> First a little about addressing in the Hewlett Packard Precision Architecture and the way short and long pointers are specified. Virtual memory is structured as a set of address spaces specified by the concatenation of a space identifier (which can be 16, 24, or 32 bits long) and an offset within the space. The space identifier portion of the virtual address comes from one of the eight space registers. During the virtual address computation, the offset portion does NOT overflow into the space identifier portion to form the effective virtual address. In that sense, addressing in HPPA resembles a segmentation style of addressing. Within a space however, standard paging techniques are applied. One of the two operating systems that are available on HPPA machies is the HP proprietary OS called MPE-XL. The other, of course, is HP-UX - HP's version of the Unix operating system. The HP-UX kernel uses long pointers, but user processes currently use only short pointers. The MPE-XL operating system uses long pointers extensively and user programs may access mapped files directly through long pointers. Long pointers (48-, 56-, or 64-bit) and short pointers (32-bit) in HPPA can be specified as follows: There is a two-bit field in the load and store instructions labeled the "s" field. If this field is a zero, then short pointers are specified. If the "s" field contains a non-zero value, long pointers are specified and the space register corresponding to the value of the "s" field specifies a space register. Short Pointers: The high-order two bits of a base register select one of four space registers (SRs 4 through 7, calculated as 4 plus the value contained in the most-significant two bits of the base register) which contains the space ID of the addressed virtual space. The contents of the base register are added to a signed dispacement or an index register to specify one of four quadrants (the virtual byte offset address) of the addressed space as follows: _______________________________________ |SS| Virtual Byte Address |-------------+ _______________________________________ | | | | | v | _____________________________________________________ | | | | | | v v v v | SR 4 SR 5 SR 6 SR 7 | _______ _______ _______ _______ | |SID a| |SID b| |SID c| |SID d| | _______ _______ _______ _______ | | | | | | | | | | | v v v v | _______ _______ _______ _______ 0 | | | |/////| |/////| |/////| | _______ _______ _______ _______ 1 |Gbyte |/////| | | |/////| |/////| | _______ _______ _______ _______ 2 |Gbytes |/////| |/////| | | |/////|<--+ _______ _______ _______ _______ 3 Gbytes |/////| |/////| |/////| | | _______ _______ _______ _______ 4 Gbytes Long Pointers: Long pointers specify a space register (SR 1 if the "s" field of the instruction contain a 1 and so on) plus 32 bits of virtual byte offset address within the space specified. This virtual byte offset is the whole base register plus a signed displacement or an index register, giving you the entire 4 Gbytes of offset within any space that is selected. MPE XL Usage of the 64 Bit Virtual Address Space: One of the fundamental benefits of MPE XL is the high file system performance gained by the use of mapped files. This is accomplished by assigning each file an entire space (a unique value for the high-order 32 bits of the virtual address). The base of the file then has an offset of zero. This provides a very high-performance way of managing cached file data, because it allows the file system cache to consume all unused memory and contend with other users of memory on an equal basis. The other obvious benefit of mapped files is that a buffer translation/search mechanism is not needed, since this is provided by the TLB. MPE-XL Use of Short Pointers: MPE-XL uses the short pointer virtual space as follows: ------------------------------------------------- | SR4 | SR5 | SR6 | SR7 | ------------------------------------------------- |Code |Process |OS Global |OS Global | |Program or |Data |Data |Data | |Library | | | | ------------------------------------------------- On the 800/900 series, SR4 contains the current executable code (supported by the common compilers and linker). SR5 is changed for every context switch to point to the process data (stack, global variables, heap, tables, etc.). SR6 and SR7 remain constant for the life of the OS. Each process is also assigned its own space and the 2nd quadrant (SR5) is used for all process data structures. MPE-XL Summary: Overall the main advantage of the 64 bit virtual address is the fact that all virtual addresses are globally accessible and there is no need for address aliasing or dynamically changing the translation structures depending on which process is running (as in the VAX or IBM 370). This allows a simple implementation of mapped files, as well as a convenient means of inspecting process-local data of the process not currently executing. HPUX Usage of the 64 Bit Virtual Address Space: Currently in HPUX, it is the operating system that knows about and uses long pointer address space. The user process model in Unix knows nothing about long pointers and sees only the 32 bit short pointer address space currently mapped by space registers 4 - 7. Future systems might allow the use of a larger address space when manipulating mapped files (see MPE-XL note above). Some HP languages do support long pointers, but HPUX applications do not take advantage of these features. Several HP supplied pascal libraries shared between the MPE-XL and HPUX products do use long pointers, however when running under HPUX these long pointers resolve to an address in short pointer space. The HPUX operating system places each user process in a separate space (long virtual address). Because of this we do not have to flush the cache or TLB on a context switch. Shared objects are mapped in via their long address directly into the users' 32 bit space. Long pointers allow us to share text or data directly between users without having to resort to aliasing techniques which are not easily supported on the HPPA architecture (because the architecture allows virtually indexed caches). Protection IDs (page access keys) are used to control users' access to shared objects. One challenge for the unix community is to determine how to support large user mapped files (objects) whose cumulative size is greater than the short pointer space available to the user process (typically 32 bits). One approach could be to access mapped data through a <object, offset> pair, or <object, segment, offset> 3-tuple similar to the file system <fd, offset> tuple. A user level library could be supplied which would determine the actual location of the object in memory, and copy the data. On a machine with a smaller address space, this might require the library to remap a portion of its address space to the <object, offset> being requested. On machines like HPPA, this may be a simple table look up, and space register insert. The goal is to determine an interface which will work effectively on machines with smaller address spaces, but yet allow machines with large address spaces to exploit their architecture. In article <16932@winchester.mips.COM> (John Mashey) writes: Quoting Shankar Unni (unni@hpda.hp.com) >>Well, it's true that declaring a pointer the usual way yields a 32-bit >>pointer (a short pointer), but it's possible to declare full 64-bit >>pointers and manipulate them as such. Yes, the address space is segmented >>into 4GB segments, so no single object can be larger than 4GB (32 bits). >Can you say what the C declaration is, that yields a 64-bit pointer? >-- >-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> The way to declare a 64 bit pointer is to say: int ^i; instead of int *i; ____________________________________________________________________________ Viggy Mokkarala, Hewlett Packard Company, Cupertino, CA viggy@hpda.hp.com
bla@hpcupt1.HP.COM (Brad Ahlf) (04/21/89)
Viggy Mokkarala writes (an EXCELLENT HP-PA summary): >I will attempt to answer some of the questions that were raised about HPPA >during the course of discussion on this topic. I am very interested in hearing equivalent answers to those same questions on some other RISC architectures. Which are similiar to HP-PA (MIPS?), which are very different? Do they have more/less capabilities? How do their compilers and operating systems take advantage of their architectures? Ok, maybe not all of that -- but how about answering the same questions which Viggy did for a quick comparison? I know it's a tough act to follow, but how about MIPS, SPARC, PRISM, 88K, ... Any takers?