Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!hacgate!gryphon!scarter From: scarter@gryphon.COM (Scott Carter) Newsgroups: comp.arch Subject: Re: MIPS Assembler Procedure Message-ID: <17164@gryphon.COM> Date: 27 Jun 89 21:28:36 GMT References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp> <22218@winchester.mips.COM> Reply-To: scarter@gryphon.COM (Scott Carter) Organization: McDonnell Douglas Electronic Systems, Huntington Beach, CA Lines: 48 In article <22218@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >In article <1989Jun24.230056.27774@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>In article <57125@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes: >>>This, in my opinion is one of the major faults of RISC processors. They >>When the list of "basic" arithmetic instructions is pages long, one starts >>to wonder how many of them are really "basic". The instruction you ask >>for -- divide double length by single length yielding single-length result -- >>is not exactly frequently needed. Just how much silicon is it worth to make >>it run faster than an implementation as a subroutine? Given the SRT divide algorithm we used (in the MD484 GaAs micro) the extra silicon is rather trivial. I don't have exact figures, but I would guess <100-200 devices, probably much less. Guy who designed that part of the CPU is not available at the moment or I would give more precise numbers. Performance difference, IF you need the operation frequently (see below) is enormous, i.e 35 cycles vs hundreds. >6) When we were doing this, we couldn't think of any languages whose >natural implementation on a 32-bit machine would expect generation >of a 64 by 32 bit divide as the expected operation. Does anybody >know of any such, or is thsi strictly something one would use in >handcoded routines? 64 divide by 32 giving 32 bit result occurs rather frequently when you are using fixed point numbers whose "engineering unit" representation is not a binary radix. This can be expressed directly in Ada by type foo is delta 0.001 range 0.0 .. 100.0; for foo'SMALL use 0.001; (There was a way to do this in JOVIAL too but I forget what it was) This sort of thing shows up in e.g. missile guidance (not a very high- volume application :) ) a great deal. Some signal processing functions use it too (don't ask me - I don't have the compartment to know). Also, if your integer multiply is significantly faster than your floating multiply (integer multiply giving 64-bit product, that is), there can be some nice performance advantage to using (binary radix!!) fixed point rather than floating point. When this is the case we see enough fixed- point divides to make the extra silicon worth it. Scott Carter McDonnell Douglas Electronics Systems Co. (714)-896-3097 using CTS until our Usenet connection arrives