ajayshah@alhena.usc.edu (Ajay Shah) (02/10/91)
The business section of NYT yesterday had a story on MIPS;
if not anything else, a early product announcement gets you
publicity!
The article mentioned plans of going up to 50 mips using the new
technology. Isn't 50 mips pretty attainable using incremental
growth of implementation on top of SPARC/MIPS architectures?
Surely announcing a new architecture needs more justification
than performance like 50mips?
Is 64 bits important? IEEE doubles are 80 bits anyway; what
kinds of instructions will run a lot better with 64 bits? A lot
of integer-performance kind of work is manipulating small objects
(<= 32 bits) anyway, a wider bus wouldn't change anything. Or
would it?
How is MIPS faring? Does someone have hard data for market share?
The NYT article mentioned the SPARC installed base as being
1.18e5 machines; that bullshit - this is more like one years
sales for Sun alone.
Today's NYT has an article on how Microsoft will do a portable
OS/2 on the R4000 and Compaq will take the lead in producing the
machine. This is truly truly vaporware! A hypothetical CPU in a
hypothetical machine running a hypothetical OS. Frankly, given
the timescales involved in getting all the ingredients debugged
and shipping in volume, I wouldn't give this much attention. Two
years in this business is a long long time!
The only ghost-of-a-chance derives from Windows applications --
if Microsoft is smart enough they could setup a 100% portability
on the new machine. You just copy your files over and say "make"
(i.e., if OS/2 has a make).
But can you imagine nice machines (I have nothing against MIPS
and Compaq) running Windows!! (AckUgh) What a waste -- no shell
windows you can fire etc.
--
_______________________________________________________________________________
Ajay Shah, (213)734-3930, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/12/91)
In article <45758@mips.mips.COM> cprice@mips.COM (Charlie Price) writes: | The important aspect of a 64-bit machine is that the user | program virtual address space can be larger than 32 bits. | If you want a nice flat big linear space to play with as you | like, then you have to have big addresses. | If you have big addresses, presumably you want to be able to | manipulate them easily and that means same-sized registers | and integer operations. What you are saying is that there are lots of poorly written non-portable programs around which do bizarre non-portable things with addresses, on the theory that because the {vax,sun,32k} has a linear address space starting with zero, that "all that ANSI crap about pointers doesn't mean much." (quote from one of my C students). Since all you can portable do in C is add or subtract ints and pointers, or subtract pointers, you don't need the rest of the arithmetic, except to do vastly unportable things. Portable programs don't AND or XOR stuff into pointers, nor assume that their high or low bits are available for flags. And honestly, other languages which have pointers are not usually used to perform these atrocities. Other languages seem to be able to convince programmers that a pointer is not an int. I really can't accept your idea that the size of an int must be the same as the size of an address. I seem to remember a DG machine in which the pointers were 48 bits, and several machines where the pointers are not in the format of ordinal values of consecutively numbered bytes. These machines exist and run, C and all the other usual languages. There is no particular technical reason not to have, say, 48 bit addressing, with 32 bit ints. There may be marketing reasons, but that's another issue completely. I agree that 64 bit ints are useful in solving certain problems, I just don't buy the argument that useful work can't be done if the size of int isn't the size of a pointer. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
mash@mips.COM (John Mashey) (02/12/91)
In article <29920@usc> ajayshah@alhena.usc.edu (Ajay Shah) writes: > >The business section of NYT yesterday had a story on MIPS; >if not anything else, a early product announcement gets you >publicity! > >The article mentioned plans of going up to 50 mips using the new >technology. Isn't 50 mips pretty attainable using incremental >growth of implementation on top of SPARC/MIPS architectures? >Surely announcing a new architecture needs more justification >than performance like 50mips? > >Is 64 bits important? IEEE doubles are 80 bits anyway; what >kinds of instructions will run a lot better with 64 bits? A lot >of integer-performance kind of work is manipulating small objects >(<= 32 bits) anyway, a wider bus wouldn't change anything. Or >would it? > >How is MIPS faring? Does someone have hard data for market share? >The NYT article mentioned the SPARC installed base as being >1.18e5 machines; that bullshit - this is more like one years >sales for Sun alone. > >Today's NYT has an article on how Microsoft will do a portable >OS/2 on the R4000 and Compaq will take the lead in producing the >machine. This is truly truly vaporware! A hypothetical CPU in a >hypothetical machine running a hypothetical OS. Frankly, given >the timescales involved in getting all the ingredients debugged >and shipping in volume, I wouldn't give this much attention. Two >years in this business is a long long time! > >The only ghost-of-a-chance derives from Windows applications -- >if Microsoft is smart enough they could setup a 100% portability >on the new machine. You just copy your files over and say "make" >(i.e., if OS/2 has a make). > >But can you imagine nice machines (I have nothing against MIPS >and Compaq) running Windows!! (AckUgh) What a waste -- no shell >windows you can fire etc. > >-- >_______________________________________________________________________________ >Ajay Shah, (213)734-3930, ajayshah@usc.edu > The more things change, the more they stay insane. >_______________________________________________________________________________ -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
frazier@oahu.cs.ucla.edu (Greg Frazier) (02/12/91)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: +In article <45758@mips.mips.COM> cprice@mips.COM (Charlie Price) writes: +| If you have big addresses, presumably you want to be able to +| manipulate them easily and that means same-sized registers +| and integer operations. [stuff deleted] + And honestly, other languages which have pointers are not usually used +to perform these atrocities. Other languages seem to be able to convince +programmers that a pointer is not an int. + I really can't accept your idea that the size of an int must be the +same as the size of an address. I seem to remember a DG machine in which +the pointers were 48 bits, and several machines where the pointers are +not in the format of ordinal values of consecutively numbered bytes. +These machines exist and run, C and all the other usual languages. Umm, I think you missed the point. Whether or not you allow the user to manipulate pointers as integers, you will still have to be able to perform integer arithmetic on addresses. Unless there is some other way to calculate the address of a[i], that is. -- Greg Frazier frazier@CS.UCLA.EDU !{ucbvax,rutgers}!ucla-cs!frazier
mash@mips.COM (John Mashey) (02/12/91)
(sorry for previous repetition of posting; slip of the fingers). There have been all kinds of mis-apprehensions posted around here, so I'm not picking on this one, but will try to answer various things that accumulated over the weekend. First, let me address the mostly nontechnical issues that have been raised. 1. "The deal": READ MY MIPS No deal has been "announced" by Microsoft, COMPAQ, MIPS, SCO, DEC, or any combination thereof. Please do not refer to any of what's been published so far as an announcement. 2. "The R4000": READ MY MIPS AGAIN: It was announced, when it was announced, for the following reasons: a) Unlike systems (i.e., 360/95), chips take a while to design in, and so people want to know about them a lot earlier than is needed for systems products. (Although systems products also have varying lead times, i.e., everybody announces bigger systems further in advance than smaller ones, given the longer planning/budgeting lead times required.) b) Specifications, under NDA, have been available to key customers for quite a while; in fact, the R4000 has many features derived from customer input. c) For various reasons, when you talk about ANYTHING, it sooner or later leaks to your competitors, and if you don't talk about it, they do, and then you start seeing articles in the press about your own forthcoming products, but only filtered thru competitors, what you read is "interesting". (the one thing that appeared not to have leaked was the 64-bittedness issue, simply because we didn't really tell people about it....:-) d) If you hear the whole pitch, one of the things covered in detail is the 64-bit story, whose thesis is: 1) 32-bitness is going to become increasingly awkward for certain (important) application areas of micros over the next few years. 2) Software people are going to have to start NOW to consider the implications of bigger addressing, if they haven't already, or we'll be in the same silly state we were in with 4MB PDP-11/70s.... where each process could only address 128KB. After we looked at the inevitable sequence of how long things take, and the fact that most people expected 64-bit only in the 1993-1994 round of designs, we figured we'd better start getting the word out SOON. e) And finally, we're close enough on the design to be reasonably sure of the features that will be in the chip (i.e., read: it's laid out, it's being simulated like crazy (current count of CPU power used for verification == 1000-vax-mips), etc. (of course there is still uncertainty: if they find bugs from the last rounds of simulations and verifications, they'll fix them, and then have to run the verifications again.) (NOTE: it is hysterically funny to see a concern that little ol' MIPS might be overhanging the market with vapor and should be sued. Let's recall any of the following: Sun ECL SPARC announced in 1987, and decribed in technical papers in 1989, used as evidence of superior scalability "50MHz 486" ballyhooed to be delivered 4Q90, and widely-given Intel charts with 586, 686, etc.... Public 68040 presentations in mid-1988, 88110 presentations in 1990. IBM "technology" presentations early 4Q90, well before product availability. BTW: I'm not criticizing any of these at all by listing them here; but people should keep a sense of proportion :-) f) We were very careful to characterize this as a technology briefing, not a product announcement. Slater has already posted that of course the reality remains to be seen, but that we did provide substantial detail, i.e., not just a couple foils. You're likely to see much more detailed articles over time. g) There was one posting that this was desperation move, or some such. That's silly: we grew from $100M to $152M, in a rather tough year for computer companies, while fighting an all-out architecture war with companies much bigger than us, which is good for long-term success, but costs money in the short term. I.e., the R4000 was announced when it was because we're close, because we had to fix the misinformation, and because people need to start thinking about the surprises. In article <29920@usc> ajayshah@alhena.usc.edu (Ajay Shah) writes: >The article mentioned plans of going up to 50 mips using the new >technology. Isn't 50 mips pretty attainable using incremental >growth of implementation on top of SPARC/MIPS architectures? >Surely announcing a new architecture needs more justification >than performance like 50mips? Actually, all of the presentations have charts where it STARTS in that vicinity (and I'm vague on purpose; we won't know until we can give exact clock rates). REcall that R2000 -> R3000A started with 8MHz and went to 40MHz (sampling) with most of the design unchanged. REcall also that MIPS has always been willing to sacrifice optimal performance in the first round in order to get a design that shrinks and adapts well to coming process technologies. > >Is 64 bits important? IEEE doubles are 80 bits anyway; what >kinds of instructions will run a lot better with 64 bits? A lot >of integer-performance kind of work is manipulating small objects >(<= 32 bits) anyway, a wider bus wouldn't change anything. Or >would it? Look, the R4000 has a wider bus, but that's NOT what makes it a 64-bit chip. It's that because it has 64-bit integer registers and address generation. Recall that IBM S/370 and VAXen are 32-bit architectures, and have had varying size busses, including 64-bit, for years, without somebody claiming they were 64-bitters. Most of this confusion comes from calling the i860 64-bits. I'll post a separate 64-bit discussion later, with some more data. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (02/12/91)
In article <UbhCgwu00VpcACYYMo@andrew.cmu.edu>, mh2f+@andrew.cmu.edu (Mark Hahn) writes: >Microsoft's risc effort, and plentiful mention of the r4000. >In other words, none of it is hypothetical, though all of it >is probably unfinished. Microsoft, for instance, had their stuff >running on r3000 hardware over a year ago. >what's interesting is the prominence >of Compaq rather than IBM in this matter. Weelll, yes and no. Compaq has, in some cases, been a standards-setter in the (Intel) PC-based world; only recently has IBM been swinging back in technology. I find it MORE interesting that Compaq has, along with Sony, chosen to use MIPS chips, while Toshiba and CompuAdd have thrown in their hands with SPARC. Doug Mohney, Operations Manager, CAD Lab/ME, Univ. of Maryland College Park * Ray Kaplan for DECUS president * SYSMGR@CADLAB.ENG.UMD.EDU
baum@Apple.COM (Allen J. Baum) (02/12/91)
[] >In article <45758@mips.mips.COM> cprice@mips.COM (Charlie Price) writes: >By the way, even if someone implements 80-bit FP (we don't), >nobody I know of *stores* 80 bits in memory or on disk. Apple does. Its SANE numeric package is 80-bits throughout. The numbers probably get stored as 96 bits, but I don't think that was the thrust of you observation. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
jsweedle@mipos2.intel.com (Jonathan Sweedler) (02/12/91)
In article <45758@mips.mips.COM>, cprice@mips (Charlie Price) writes: >By the way, even if someone implements 80-bit FP (we don't), >nobody I know of *stores* 80 bits in memory or on disk. The x87 architecture implements 80-bit arithmetic. It also allows the storing and loading of 80-bit FP numbers. =============================================================================== |Jonathan Sweedler Microprocessor Design Intel Corp.| | {decwrl,hplabs,oliveb}!intelca!mipos3!mipos2!jsweedle | | jsweedle%mipos2.intel.com@relay.cs.net |
my@berlioz.nsc.com (Michael Yip) (02/12/91)
In article <0094412A.15FE5B40@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: >Weelll, yes and no. Compaq has, in some cases, been a standards-setter in >the (Intel) PC-based world; only recently has IBM been swinging back in >technology. I find it MORE interesting that Compaq has, along with Sony, >chosen to use MIPS chips, while Toshiba and CompuAdd have thrown in their hands >with SPARC. > I think that Compaq is really looking around for the "next generation" of processors. In addition to the MIPS/MS/Compaq story from NY Times, Compaq is also investing in NexGen Inc. NexGen is currently working on the i386 chip clone [and their schudele is delayed a lot]. -- Mike
ts@cup.portal.com (Tim W Smith) (02/12/91)
I can think offhand of two good reasons for more than 32 bits right now. 1. It would not be unreasonable for someone to want to have more than 4GB of *physical* memory in their machine. 2. Wouldn't arbitrary precision arithmetic routines run quite a bit faster if they could work 64 bits at a time rather than 32 bits at a time? This becomes important to people who want to use public key cryptography. 3. Many problems that need floating point will now be able to be done in fixed point and still have adequate precision. I know I said I had two reasons - pick whichever two you like the best from the above three. Tim Smith
richard@aiai.ed.ac.uk (Richard Tobin) (02/12/91)
In article <3188@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > What you are saying is that there are lots of poorly written >non-portable programs around which do bizarre non-portable things with >addresses, on the theory that because the {vax,sun,32k} has a linear >address space starting with zero, that "all that ANSI crap about pointers >doesn't mean much." (quote from one of my C students). Non-portable, certainly. But not necessarily badly-written. Most programs have no need to treat pointers in this way, but a very important class do: those which implement other languages. It's extremely common for Lisp systems, for example, to represent objects as a tagged word, consisting of a few bits (often 2, but sometimes as many as 8) describing the type (integer, symbol, cons etc) and the rest containing the address. This involves treating addresses as integers. For many of us, the fact that it's hard to port such a system to an 8086 or other segmented architecture merely inclines us to reject such processors. We've weighed up the advantages of portability against the disadvantage of having to use more cumbersome and probably less efficient implementation techniques, and you'll find us using vaxes, suns, mipses and sometimes 386s. It's also worth noting that such languages are often used for the implementation of programs requiring a huge address space. I'm delighted to see that MIPS is going straight to 64 bits for both pointers and integers, and hope that other manufacturers do the same. > And honestly, other languages which have pointers are not usually used >to perform these atrocities. Other languages seem to be able to convince >programmers that a pointer is not an int. And that's one reason why you'll usually find Lisp and Prolog implemented in C, not pascal. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (02/12/91)
In article <1991Feb11.221951.4758@berlioz.nsc.com>, my@berlioz.nsc.com (Michael Yip) writes: >>..... I find it MORE interesting that Compaq has, along with Sony, >>chosen to use MIPS chips, while Toshiba and CompuAdd have thrown in their hands >>with SPARC. > >I think that Compaq is really looking around for the "next generation" of >processors. In addition to the MIPS/MS/Compaq story from NY Times, Compaq >is also investing in NexGen Inc. NexGen is currently working on the i386 >chip clone [and their schudele is delayed a lot]. Compaq invested in NexGen because they did not want to be enslaved to Intel on PC/DOS boxes. THeir choice of getting into the UNIX/RISC workstation market was MIPS. Does this make MIPS the heart of all PCs down to the $1000 Amiga-replacements?:-) Uhh, I think that's stretching it. Is there a market for a "hobbyiest's RISC?" Is anyone building a "Hobbyiest RISC?" Dunno. Is there room for UNIX/RISC workstations in the business world? Maybe, if you get some "killer" applications ported to the proper platforms. What are the "killer" business applications? Optical character recognition, some sort of "agent" task to sort through tons of data, and faster, stronger databases & spreadsheets, using <buzzword alert> multimedia techniques where appropriate. Doug Mohney, Operations Manager, CAD Lab/ME, Univ. of Maryland College Park * Ray Kaplan for DECUS president * SYSMGR@CADLAB.ENG.UMD.EDU
torbenm@diku.dk (Torben [gidius Mogensen) (02/13/91)
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: >Is there a market for a "hobbyiest's RISC?" >Is anyone building a "Hobbyiest RISC?" Dunno. Acorn Computers build hobbyist machines using their ARM RISC processor. The smallest model costs around 600 pounds in England. It is a one-box machine with a 3.5" floppy similar in design to an Amiga 500, but having 1MB of RAM plus .5MB of ROM. As for the market, Acorn has passed the 100.000 machines sold mark, probably making the ARM the second-most sold RISC processor (after SPARC). Torben Mogensen (torbenm@diku.dk)
dseal@armltd.uucp (David Seal) (02/13/91)
In article <29920@usc> ajayshah@alhena.usc.edu (Ajay Shah) writes: >Is 64 bits important? IEEE doubles are 80 bits anyway; what >kinds of instructions will run a lot better with 64 bits? IEEE doubles are 64 bits! The 80 bit IEEE format is double extended (or rather, the usual version of IEEE double extended is 80 bits wide: the IEEE standard does not specify extended formats fully, but implies that double extended must be at least 79 bits wide). David Seal dseal@acorn.co.uk Standard disclaimers apply.
kers@hplb.hpl.hp.com (Chris Dollin) (02/13/91)
Torben [gidius Mogensen writes:
....
As for the market, Acorn has passed the 100.000 machines sold mark,
probably making the ARM the second-most sold RISC processor (after
SPARC).
Acording to Acorn [Ray Pinchard, Acorn rep, January meeting of Avon Archimides
User Group], Acorn have a little *more* than half of the RISC processor market;
remember that ARM chips appear in video records (I used to know which make) and
- I think - Olivetti laser printers.
Wandering sideways to a different thread, the ARM memory controller gives you
pages of 32 (yes, thirty-two) Kbytes. It pigged the performance of the first
ARM Unix engine. [The page size isn't any smaller on the more recent ARM3
machines, but the available physical memory is bigger, and I *hope* Acorn are
building a revised memory controller with a more, hm, acceptable pagesize.]
--
Regards, Kers. | "You're better off not dreaming of the things to come;
Caravan: | Dreams are always ending far too soon."davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/14/91)
In article <39184@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: | 1. It would not be unreasonable for someone to want to | have more than 4GB of *physical* memory in their | machine. This is more an argument for more address bits. | 2. Wouldn't arbitrary precision arithmetic routines | run quite a bit faster if they could work 64 bits at | a time rather than 32 bits at a time? This becomes | important to people who want to use public key | cryptography. Maybe. Assuming that the operations were equally fast for 64 bits, probably. However, this assumes some changes in the ALU to make a 64 bit multiply or divide as fast as a 32. | 3. Many problems that need floating point will now be | able to be done in fixed point and still have adequate | precision. Maybe. Currently there is not a lot of convenient fixed point support in languages, and the vector f.p. is down to 1 result per clock for large problems. My first thought is that fixed point is probably not a win for most problems. It's best for machines which have slow f.p. or problems which don't vectorize, but may not be a win in other cases. You would need more hardware and software support to make it useful in most cases, I believe. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
mash@mips.COM (John Mashey) (02/14/91)
In article <3188@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
various reasons defenidng 48-bit addressing, poitners that are not
integers and so forth.
Let me try a rather different argument, which is not as directly technical,
but is orders of magnitude more relevant.
Let me first recall a story. Once upon a time, there was a RISC that
used word-addressing, and certain folks wanted to continue that into a
product of a company I was about to join. Th reasonign was
simplicity, speed, and fact that most operations were integer.
My comment: yes, but would you like to have software?
A: really, there's no problem, people will ahve to be careful, and
rework a few things, but it wil lbe OK.
me again: one more time: would you like to have 3rd-party software?
A: well, yes.
me: good. the R2000 has byte addressing, then.
Anyway, the issue will be: regarless of hte possibility of making
thigns work, the real bottom line is whether it is trivial to move
existing software and take advantage of it, and then really
take advantage of >32-bit addressing ... or not.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash
DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086jackk@shasta.Stanford.EDU (jackk) (02/14/91)
John Mashey writes.... > (NOTE: it is hysterically funny to see a concern that little ol' > MIPS might be overhanging the market with vapor and should be > sued. I didn't mean to suggest that I think they "should" be sued, or that there is any basis to do so. There is *more* than enough legal manuevering in the computer industry these days. > Let's recall any of the following: > Sun ECL SPARC announced in 1987, and decribed in technical > papers in 1989, used as evidence of superior scalability > "50MHz 486" ballyhooed to be delivered 4Q90, and > widely-given Intel charts with 586, 686, etc.... > Public 68040 presentations in mid-1988, 88110 presentations > in 1990. > IBM "technology" presentations early 4Q90, well before > product availability. > BTW: I'm not criticizing any of these at all by listing them here; > but people should keep a sense of proportion :-) I guess my comment was more directed at the different ways the trade press treats such announcements coming from IBM and from smaller companies. Malice seems to be assumed more often in the case or larger companies. I would also add that I think that voice of the technical professionals from MIPS (esp. John Mashey et. al.) have been some of some of the most informed and rational on the net. His efforts to help clean up and standardize benchmarking practices are especially notable. This is in part why I was so surprised to see the R4000 info prior to say, an ISSCC paper. The argument that software suppliers need time to plan is a good one, and perhaps it is the press that has made this look more splashy than it is.
graeme@labtam.labtam.oz (Graeme Gill) (02/14/91)
In article <3188@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > > Since all you can portable do in C is add or subtract ints and > pointers, or subtract pointers, you don't need the rest of the > arithmetic, except to do vastly unportable things. Portable programs > don't AND or XOR stuff into pointers, nor assume that their high or low > bits are available for flags. > Just a small point, but a lot of these machines have memory alignment restrictions. How do you ensure address alignment if you can't do an AND on an address ? Isn't being able to do integer arithmetic on addresses the more general solution to testing alignment and calculating structure/array addresses ? (I am refering here to machine level rather than language level facilities). Graeme Gill Labtam Australia
dik@cwi.nl (Dik T. Winter) (02/14/91)
In article <5974@labtam.labtam.oz> graeme@labtam.labtam.oz (Graeme Gill) writes: > In article <3188@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > > > > Since all you can portable do in C is add or subtract ints and etc. > Just a small point, but a lot of these machines have memory alignment > restrictions. How do you ensure address alignment if you can't do an > AND on an address ? The talk was about portable. To get address alignment for an int on a Cray for instance you do: a = (int *)((int)a & 0x1fffffffffffffff); is that portable? To see some real hacks about attempts to get address alignment, look at the code for the Bourne Shell, and be amazed that it works on so very many machines. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/14/91)
In article <5974@labtam.labtam.oz> graeme@labtam.labtam.oz (Graeme Gill) writes: | Just a small point, but a lot of these machines have memory alignment | restrictions. How do you ensure address alignment if you can't do an | AND on an address ? Isn't being able to do integer arithmetic on addresses | the more general solution to testing alignment and calculating structure/array | addresses ? (I am refering here to machine level rather than language level | facilities). I think you're correct in saying that something in the hardware must be able to generate an alligned address. I don't think that requires moving addresses into ints and ANDing them, as long as there is a way to do it. There are certainly portable ways to get alligned addresses, from things like the C malloc() or the Pascal new. This moves the problem from the portable part (the high level source) to the machine dependent part of the library. It is a good point, though, that the hardware must provide allignment, even if it can handle unalligned addresses. Note that Convex does this by trapping the access, faking it in software, and generating a nastygram for the user to encourage fixing the code. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
cprice@mips.COM (Charlie Price) (02/15/91)
In article <3188@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <45758@mips.mips.COM> cprice@mips.COM (Charlie Price) writes: > >| The important aspect of a 64-bit machine is that the user >| program virtual address space can be larger than 32 bits. >| If you want a nice flat big linear space to play with as you >| like, then you have to have big addresses. >| If you have big addresses, presumably you want to be able to >| manipulate them easily and that means same-sized registers >| and integer operations. > > I agree that 64 bit ints are useful in solving certain problems, I >just don't buy the argument that useful work can't be done if the size >of int isn't the size of a pointer. Others have already followed up pointing this out, but let me emphasize that I said that manipulating big addresses easily (by which I meant effortlessly) means having same-sized registers and (same-sized) integer operations. I did not mean to imply that an "int" type in C for example, would need to be 64 bits. The width used for scalar types in higher-level programming languages is a separate issue. I'm sorry if I wasn't clear enough about that. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA 94086-23650
graeme@labtam.labtam.oz (Graeme Gill) (02/18/91)
In article <3199@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: . . > It is a good point, though, that the hardware must provide allignment, > even if it can handle unalligned addresses. Note that Convex does this > by trapping the access, faking it in software, and generating a > nastygram for the user to encourage fixing the code. Ah yes, but the point is, how does the trap software fake it without doing logical operations on the fault address ? :-) Graeme Gill
ingoldsb@ctycal.UUCP (Terry Ingoldsby) (02/21/91)
In article <29920@usc>, ajayshah@alhena.usc.edu (Ajay Shah) writes: > > How is MIPS faring? Does someone have hard data for market share? > The NYT article mentioned the SPARC installed base as being > 1.18e5 machines; that bullshit - this is more like one years > sales for Sun alone. This seems a little low; according to figures I read in a magazine (can't remember which one) in 1990 Sun held 38% of the marketshare (but 27% of the revenue) with 141,800 units. Since most of Sun's SPARC sales probably occurred in 1990 the installed base is probably still under 200,000 units. Quite respectable, but not *that* much greater than the figure you quote. The article I read didn't mention MIPS, but the top 4 (Sun, HP DEC (which is sort of MIPS) and IBM) took almost 80% of the market share in 1990. -- Terry Ingoldsby ingoldsb%ctycal@cpsc.ucalgary.ca Land Information Services or The City of Calgary ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb