Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: MIPS, Compaq and Microsoft in bed - NYT story Message-ID: <3195@crdos1.crd.ge.COM> Date: 13 Feb 91 16:05:16 GMT References: <29920@usc> <45758@mips.mips.COM> <3188@crdos1.crd.ge.COM> <39184@cup.portal.com> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 33 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