[comp.lang.c] looking for >32-bit address space and how will C handle it

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