cmt@myrias.UUCP (Chris Thomson) (04/03/89)
Are there any micros or chipsets out there that support an address space larger than 32 bits? The current trend in micros seems to be toward 64-bit data paths but only 32-bit address paths. In a large-scale parallel processor, this starts to feel a bit like a PDP-11. -- Chris Thomson, Myrias Research Corporation uunet!ncc!myrias!cmt 900 10611 98 Ave, Edmonton Alberta, Canada 403-428-1616
gupta@hpcuhb.HP.COM (Mayank Gupta) (04/03/89)
>Are there any micros or chipsets out there that support an address space >larger than 32 bits? The current trend in micros seems to be toward 64-bit >data paths but only 32-bit address paths. In a large-scale parallel >processor, this starts to feel a bit like a PDP-11. It was gonna come around sooner or later. HP saw this coming five years ago when we developed our HP-PA (Precision arcitecture "RISC"). This gives you: 32 bit virtual and 32 bit physical addressing : Level 0 compliance. 48 bit virtual and 32 bit physical addressing : Level 1 compliance. 64 bit virtual and 32 bit physical addressing : Level 2 compliance. with a very comprehensive memory management system, including levels (> 2) of protection. HP has been shipping 64 bit virtual address machines. All of the above are 32-bit integer and IEEE compliant floating point machines. Maybe you should contact a sales representative in your area. Mike Gupta gupta@hpesomg 408-447-0390
henry@utzoo.uucp (Henry Spencer) (04/03/89)
In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >Are there any micros or chipsets out there that support an address space >larger than 32 bits? ... And please, let us not hear solemn pronunciamentos about the supposed 40-bit address space of the RT -- it has a 32-bit address space, plus 8086ish bank-switching. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mdr@reed.UUCP (Mike Rutenberg) (04/04/89)
>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. 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. 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. Mike Total aside: Does the Myrias machine exist yet? How come nobody is willing to post a description of it? I've heard some really unusual stories, but have seen nothing at all solid. -- Mike Rutenberg Reed College, Portland Oregon (503)239-4434 (home) BITNET: mdr@reed.bitnet UUCP: uunet!tektronix!reed!mdr Note: The preceding remarks are intended to represent no known organization
mccalpin@loligo.uucp (John McCalpin) (04/04/89)
In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >Are there any micros or chipsets out there that support an address space >larger than 32 bits? ... Well, it's not exactly a chipset yet, but the ETA-10 line from CDC uses a 48-bit bit-addressed linear address space. I hear that their next-generation CPU boards are small enough to fit in a coat pocket, so it almost counts :-) ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu --------------------------------------------------------------------
donh@microsoft.UUCP (Don Hacherl) (04/04/89)
In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >Are there any micros or chipsets out there that support an address space >larger than 32 bits? The current trend in micros seems to be toward 64-bit >data paths but only 32-bit address paths. The Intel 386 supports a 46-bit virtual address space (32 bits of offset + 16 bits of selector - 2 bits of selector protection), although the linear and physical address spaces are only 32 bits. I know of no OS that supports this, though (does Intel have a 386 iRMX?). Flat 32-bit address spaces are very popular these days, and no one wants to buck the trend. don -- Don Hacherl "Sorry, no pithy quotes today" donh%microsof@beaver.washington.edu or {decvax,uunet,uw-beaver}!microsoft!donh Disclaimer: Little of what I say should be taken seriously, and none should be taken as the opinion of my employer.
mash@mips.COM (John Mashey) (04/04/89)
In article <3830004@hpcuhb.HP.COM> gupta@hpcuhb.HP.COM (Mayank Gupta) writes: > >>Are there any micros or chipsets out there that support an address space >>larger than 32 bits? The current trend in micros seems to be toward 64-bit >>data paths but only 32-bit address paths. In a large-scale parallel >>processor, this starts to feel a bit like a PDP-11. >It was gonna come around sooner or later. HP saw this coming five years ago >when we developed our HP-PA (Precision arcitecture "RISC"). This gives you: > >32 bit virtual and 32 bit physical addressing : Level 0 compliance. >48 bit virtual and 32 bit physical addressing : Level 1 compliance. >64 bit virtual and 32 bit physical addressing : Level 2 compliance. > >with a very comprehensive memory management system, including levels (> 2) of >protection. > >HP has been shipping 64 bit virtual address machines. All of the above are >32-bit integer and IEEE compliant floating point machines. 1) can you say more about what this "Level x compliance" means? (Does that mean that you can build HP PA machines with 32/32, and that's called Level 0? or does it mean something other than compliance with an HP-internal spec?) 2) I suspect that the original question was looking for machines more like some supercomputers, i.e., with 64-bit integers and addresses that are used directly as such (which I don't think HP PA does: correct me if I'm wrong, but aren't there segment registers that can be controlled by the compilers, rather than 64-bit flat addresses?) -- -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
philba@microsoft.UUCP (Phil Barrett) (04/05/89)
In article <1220@microsoft.UUCP> donh@microsoft.UUCP (Don Hacherl) writes: >In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >>Are there any micros or chipsets out there that support an address space >>larger than 32 bits? The current trend in micros seems to be toward 64-bit >>data paths but only 32-bit address paths. > >The Intel 386 supports a 46-bit virtual address space (32 bits of >offset + 16 bits of selector - 2 bits of selector protection), >although the linear and physical address spaces are only 32 bits. I >know of no OS that supports this, though (does Intel have a 386 iRMX?). >Flat 32-bit address spaces are very popular these days, and no one >wants to buck the trend. > Intel does have an RMX 386 but last I looked, it doesn't support > 4Gb address space. I've spent some time looking at how one would go about taking advantage of this feature of the 386 and it's pretty messy. Demand paging under demand segmentation isn't that hard but the big problem is that there is only one active page directory and it only (gee, what a limitation) addresses 4Gb. You would need to virtualize the page table/dir to get beyond 4Gb instantaneous addressability for a single process. Its possible to do but I think the performance wouldn't be that good. Consider a string move between 2 virtual 4 Gb segments. I think the 64TeraByte virtual address space of the 386 is more smoke than anything else.
jps@wucs1.wustl.edu (James Sterbenz) (04/05/89)
In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >Are there any micros or chipsets out there that support an address space >larger than 32 bits? Well, not exactly a micro, but the IBM system/38 (and I guess AS/400, I have to check) have a 48 bit address space. It's possible that some of the other >32 bit word machines have matching addresses, but these aren't micros either (Unisys 1100 + A-series, etc.) -- James Sterbenz Computer and Communications Research Center Washington University in St. Louis 314-726-4203 INTERNET: jps@wucs1.wustl.edu UUCP: wucs1!jps@uunet.uu.net
gupta@hpcuhb.HP.COM (Mayank Gupta) (04/05/89)
> 1) can you say more about what this "Level x compliance" means? > (Does that mean that you can build HP PA machines with 32/32, and that's > called Level 0? or does it mean something other than compliance with > an HP-internal spec?) This is just a flexibility provided to the implementer of the CPU to choose from. Yes somebody could make a 32 bit Virtual and 32 bit physical address (Level 0) CPU and still be called a HP-PA. To this date, (to my knowledge) no HP-PA Level 0 has been made. This option leaves the door open for someone to make a CPU for a embedded controller type application or something like intel's N-10. Virtual space is segmented as 2^0 spaces of 2^32 bytes for Level 0. 2^16 spaces of 2^32 bytes for Level 1. 2^32 spaces of 2^32 bytes for Level 2. > 2) I suspect that the original question was looking for machines more like > some supercomputers, i.e., with 64-bit integers and addresses that are > used directly as such (which I don't think HP PA does: correct me if I'm > wrong, but aren't there segment registers that can be controlled by the > compilers, rather than 64-bit flat addresses?) Sorry, If I mis-interpreted the question. HP-PA is a 32 bit integer and 64 bit floating point architecture. There are 0, 16 or 32 bit (depending on Level) space registers in hardware TLBs. Software PDIR is maintained with 64 bit virtual address in mind. Mike Gupta gupta@hpesomg 408-447-0390
wunder@hp-ses.SDE.HP.COM (Walter Underwood) (04/05/89)
Somebody had Motorola build a 68012 at one point, which was a 32 bit address bus 68010. In the 68010, all 32 bits of address were brought out to pads on the silicon. The 64-pin DIP package only had room for 24 address lines. The pin-grid package had 68 pins, but still only 24 address lines. HP asked Motorola to make up a few specials with four more address lines brought out (making 28 bits of address). Later Motorola stuck the number 68012 on that configuration. I'm not sure why HP asked for it, though it may have been in conjunction with some LISP work that could use *lots* of VM. The boot ROM on the s200 boxes did some fancy work to distinguish between a 68010 and a 68012. And yes, the HP Precision Architecture (called "Spectrum" in development, not "Prism") has segmented memory with 32 bit segment offsets and 0, 16, or 32 bits of segment number. The HP9000/840 had 16 bit segment numbers. I think that the current machines have 32 bits. wunder
shankar@hpclscu.HP.COM (Shankar Unni) (04/05/89)
> >HP has been shipping 64 bit virtual address machines. All of the above are > >32-bit integer and IEEE compliant floating point machines. > 1) can you say more about what this "Level x compliance" means? > (Does that mean that you can build HP PA machines with 32/32, and that's called Level 0? or does it mean something other than compliance with > an HP-internal spec?) It means "compliance with the Architecture Control Document". The idea is to allow a range of implementations from the single-board microcontroller type (which probably doesn't need the full 64-bit address range) through the midrange to the high end (which allows a full 64-bit address). > 2) I suspect that the original question was looking for machines more like > some supercomputers, i.e., with 64-bit integers and addresses that are > used directly as such (which I don't think HP PA does: correct me if I'm > wrong, but aren't there segment registers that can be controlled by the > compilers, rather than 64-bit flat addresses?) 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). So you're right, there's no flat 64-bit address space, but it's possible to have an awfully large data area in disjoint pieces. I know that the original poster was enquiring about 64-bit flat spaces, and that this machine does not quite fit that description. I'm just clearing a side question. --- Shankar Unni.
frank@zen.co.uk (Frank Wales) (04/05/89)
In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >Are there any micros or chipsets out there that support an address space >larger than 32 bits? In article <3830004@hpcuhb.HP.COM> gupta@hpcuhb.HP.COM (Mayank Gupta) replies: #HP saw this coming five years ago when we developed our HP-PA (Precision #arcitecture "RISC"). This gives you: # #32 bit virtual and 32 bit physical addressing : Level 0 compliance. #48 bit virtual and 32 bit physical addressing : Level 1 compliance. #64 bit virtual and 32 bit physical addressing : Level 2 compliance. # #with a very comprehensive memory management system, including levels (> 2) of #protection. True, but the problem with HP-PA is that you can only get whole machines built from it, rather than just a PA micro or chip set (according to Joel Birnbaum, it existed in CMOS years ago). Sun clearly think there is mileage in licensing their SPARC architecture to others, as do MIPS, and I am fearful for the long-term success of PA while it remains an HP-only product. So, at least in that sense, HP-PA doesn't qualify as an answer to Chris's question, since he said "micros or chipsets," not "whole machines." [Yes, I do like HP-PA -- this was written on it.] -- Frank Wales, Systems Manager, [frank@zen.co.uk<->mcvax!zen.co.uk!frank] Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217
lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (04/06/89)
There are two important issues.
Issue number one, is the short-pointer problem.
Issue number two, is the mapped file problem.
Short pointers are simply an economy measure. Reducing the number of
bits used may make programs smaller, reduce processor cycles, compress
data structures, and so on. In the case of 32 bit machines with >32
bit virtual addresses, it's "obvious" that programs will deal in 32-bit
short addresses.
The problem is that there are now two "pointer" data types, not one,
and the programmer has to know that
<small> := <big>
doesn't work. Or, alternatively, the compiler can have a "large
model/small model" switch. The programmer is off the hook, but now you
need two copies of every library .. and every application .. and the
"big" versions may be unnecessarily slow.
"Segment register" schemes don't really help, because now pointers are
only meaningful when the context is as it was when they were created.
A pointer is no longer standalone, and you can't have "magic cookies"
("opaque types"). So, any generalized routine that is passed a
pointer, must also be passed segment info, and we're back around to
short/long. Also, it may be impossible to build big objects out of
successive segments, in such a way that the "next address" operation is
just "increment". (I suppose a trap is perferable to inline overflow
checking.)
Issue number two, mapped files, is simply that there may be a strong
advantage to having Really Big Objects. Database people would like to
map an entire external device into the address space. Since 5 GB disk
drives already exist, 32 bit addresses already don't cut it.
Stonebraker argued that data base systems would like a flat view of a
disk, because otherwise they are imposing structure on top of the OS's
structures, and both layers do e.g. indexing that would be more
efficient if done by only one layer. The Mach operating system has a
nice feature for this. Mach allows an application developer to write
his own page fault handler, which gets executed in the same space as
his application. (In theory, the other threads of the application
don't need to block unless they also need the same page.)
This data-base argument seems to me like a strong argument for
supporting big addresses. I don't see any really acceptable way to
compress big addresses, except perhaps in application-dependant ways.
For example, the DB's fault handler could use N high-order address bits
in some "take a ticket"/"tag bit" style. This only really extends the
address space if the application knows how to do things like ticket
reclamation. (These things are difficult in general, but easy if the
application can be specifically designed for it.)
--
Don D.C.Lindsay Carnegie Mellon School of Computer Science
-- seanf@sco.COM (Sean Fagan) (04/06/89)
In article <1989Apr3.164538.277@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >>Are there any micros or chipsets out there that support an address space >>larger than 32 bits? ... >And please, let us not hear solemn pronunciamentos about the supposed >40-bit address space of the RT -- it has a 32-bit address space, plus >8086ish bank-switching. The 8086 doesn't bank-switch. The Apple //e bank switches. The 8086 uses segments, which are similar, but, IMHO, better (ye gods, I'm starting to advocate intel!!!!). The 8086 and '286 messed up by having only 64kbyte segments. People were getting along fine, years ago, on Multics machines, which used segments. People are getting along fine on a Cyber 180, which has 44-bit addressing (32-bit segments, and then a 12-bit segment number). Forgive me, but people are even using *Primes* which use segments. If the new RT/PC can have 256 segments (with appropriate changes to the instruction set), then it shouldn't be too unbearable. Now, if it uses *real* bank-switching, then we should all meet at the factory and blow it up 8-). -- Sean Eric Fagan | "An acid is like a woman: a good one will eat seanf@sco.UUCP | through your pants." -- Mel Gibson, Saturday Night Live (408) 458-1422 | Any opinions expressed are my own, not my employers'.
slackey@bbn.com (Stan Lackey) (04/06/89)
In article <2516@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >In article <1989Apr3.164538.277@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >>>Are there any micros or chipsets out there that support an address space >>>larger than 32 bits? ... >>And please, let us not hear solemn pronunciamentos about the supposed >>40-bit address space of the RT -- it has a 32-bit address space, plus >>8086ish bank-switching. >The 8086 doesn't bank-switch. The Apple //e bank switches. The 8086 uses The original request was for a greater-than-32 bit address space, not some hack segmentation. Apparently, the requester wanted to spend his time programming, not hacking around compile and runtime errors re-partitioning his data. Anybody can put a map RAM on a micro to [apparently] extend its addressing. Hopefully, one or more of the suppliers will take a leadership role by providing a true larger addressing feature. (Hopefully 64 bits.) And auto-inc addressing and unaligned data! Oops sorry. :-) Stan
aglew@mcdurb.Urbana.Gould.COM (04/07/89)
>>Are there any micros or chipsets out there that support an address space >>larger than 32 bits? The current trend in micros seems to be toward 64-bit >>data paths but only 32-bit address paths. In a large-scale parallel >>processor, this starts to feel a bit like a PDP-11. > >It was gonna come around sooner or later. HP saw this coming five years ago >when we developed our HP-PA (Precision arcitecture "RISC"). This gives you: > >32 bit virtual and 32 bit physical addressing : Level 0 compliance. >48 bit virtual and 32 bit physical addressing : Level 1 compliance. >64 bit virtual and 32 bit physical addressing : Level 2 compliance. Ummh, correct me please, but I thought that HP's machine provided segments, with 32 bits of maximum segment size, and the extra bits basically accessible by segment base registers. (I thought of the HP3000 when I read about it).
henry@utzoo.uucp (Henry Spencer) (04/08/89)
In article <2516@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >>And please, let us not hear solemn pronunciamentos about the supposed >>40-bit address space of the RT -- it has a 32-bit address space, plus >>8086ish bank-switching. > >The 8086 doesn't bank-switch. The Apple //e bank switches. The 8086 uses >segments, which are similar, but, IMHO, better... How so? As far as the programmer is concerned, it really doesn't make much difference. Either way, a complete address is larger than the "natural" pointer size, and you can't use it directly -- you have to feed the segment/bank part into the machinery separately, and *then* use the rest of the address. (Sometimes the compiler can do this for you, but the efficiency penalty remains.) Which gets us back to abominations like "near" and "far" pointers and all the rest of the 8086 sludge. *Real* segments, as on the Multics machines, are part of the normal pointer format, and to access something in a segment, you just indirect through the pointer. One can argue about the merits of breaking the linear address space up into segments, but the point is that normal pointer manipulation is not penalized in either efficiency or simplicity. The real problem with >32 bit addresses is that avoiding the dreaded Intel Pointer Syndrome requires a 64-bit word. Which costs more than a lot of people want to pay just now. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mash@mips.COM (John Mashey) (04/10/89)
In article <650010@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >> >HP has been shipping 64 bit virtual address machines.... >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> 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
seanf@sco.COM (Sean Fagan) (04/11/89)
In article <1989Apr7.194933.4861@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2516@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >>The 8086 doesn't bank-switch. The Apple //e bank switches. The 8086 uses >>segments, which are similar, but, IMHO, better... >Either way, a complete address is larger than the >"natural" pointer size, and you can't use it directly -- you have to >feed the segment/bank part into the machinery separately, and *then* >use the rest of the address. >*Real* segments, as on the Multics machines, are part of the normal >pointer format, and to access something in a segment, you just indirect >through the pointer. I do admit that Intel segments are, um, unpleasant (at least, on the 8086). On the '286 and '386, they are better, and, in fact, on the '386, they're quite pleasant (as segments go...). I've never played with Multics, but I have played on a Cyber 180-state machine, which seems to have been modeled after a Multics machine. The segments there are *very* similar to the way the '386 does it, except that you can use more registers for segment registers on the Cyber (and, I presume, Multics). >One can argue about the merits of breaking the >linear address space up into segments, but the point is that normal >pointer manipulation is not penalized in either efficiency or simplicity. Neither is it on the '386. >The real problem with >32 bit addresses is that avoiding the dreaded >Intel Pointer Syndrome requires a 64-bit word. Which costs more than >a lot of people want to pay just now. I still maintain that segments are possible a Good Thing, although I don't like some implementations. -- Sean Eric Fagan | "An acid is like a woman: a good one will eat seanf@sco.UUCP | through your pants." -- Mel Gibson, Saturday Night Live (408) 458-1422 | Any opinions expressed are my own, not my employers'.
barmar@think.COM (Barry Margolin) (04/11/89)
In article <2534@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: > The segments [on the Cyber-180] are *very* similar to the way >the '386 does it, except that you can use more registers for segment >registers on the Cyber (and, I presume, Multics). Multics hasn't had dedicated segment registers for a long time (about fifteen years). The Multics processor had separate segment registers (called base registers) and offset registers (called pointer registers), which were grouped in pairs that could be used as full address registers. In the early 70's the followon processors (the 6000 series) replaced each segment and offset register with a full pointer register. It isn't necessary to use separate instructions to load the segment and offset portions of a pointer register (unless you want to, of course, when the situation is appropriate). Programs, even those written in assembly language, that don't care about the fact that memory is segmented generally don't notice (the only time they might notice is if they try to allocate an array that doesn't fit in a segment, i.e. larger than about 1MB). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
henry@utzoo.uucp (Henry Spencer) (04/12/89)
In article <2534@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >>One can argue about the merits of breaking the >>linear address space up into segments, but the point is that normal >>pointer manipulation is not penalized in either efficiency or simplicity. > >Neither is it on the '386. It will be when you start wanting more than 32 bits of address... which is what started this whole line of discussion. The 386 looks okay right now because its segments (unlike those of the smaller Intel flakes, er excuse me chips) are big enough that you can ignore the ability to have more than one of them. >>The real problem with >32 bit addresses is that avoiding the dreaded >>Intel Pointer Syndrome requires a 64-bit word. Which costs more than >>a lot of people want to pay just now. > >I still maintain that segments are possible a Good Thing, although I don't >like some implementations. I agree that segments are possibly a good thing -- but the segment number has to be part of a normal, ordinary pointer, not a tacked-on extra. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
aglew@mcdurb.Urbana.Gould.COM (04/12/89)
In a recent CACM article on volume rendering a good, real example of the type of application that will need >32 bits of address is presented: The smallest data set being massaged was 10x10x30, and the largest was 10,000x10,000x4,000 voxels. True, these'll be sparse, but even sparsely such a picture will occupy a lot of space. Especially when you add properties to each voxel. A while back a computer company I used to work for was talking about architecting a machine for a flat 64 bit address space, implementing only 40 at first. That was a good few years ago. I'd guess that you'd have to start at 48 now, if you wanted that to be a sales distinction. (PS. that particular project never got off the ground)