Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!iuvax!pur-ee!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu.UUCP Newsgroups: comp.arch Subject: Re: What should be in hardware but isn't Message-ID: <582@l.cc.purdue.edu> Date: Wed, 23-Sep-87 16:25:05 EDT Article-I.D.: l.582 Posted: Wed Sep 23 16:25:05 1987 Date-Received: Sat, 26-Sep-87 06:37:15 EDT References: <581@l.cc.purdue.edu> <18336@amdcad.AMD.COM> Organization: Purdue University Statistics Department Lines: 62 Summary: RISC cannot do it In article <18336@amdcad.AMD.COM>, tim@amdcad.AMD.COM (Tim Olson) writes: > In article <581@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > +----- > From the following examples, it sure appears as if you are arguing for > "letting the user decide" how certain functions are implemented. The > easiest (and probably best) way to do this is to provide a fast, fixed > set of primitive operations, and let users build what they need from > that set (i.e. RISC). > +----- > +----- > With the correct primatives, you can easily code these as procedures > which will run *as fast* as standard div, mod, rem. > +----- > -- Tim Olson > Advanced Micro Devices > (tim@amdcad.amd.com) Olson greatly underestimates the number of RISC instructions needed to do even a fair job. If the user is going to be able to do the things needed efficiently, the combining of instructions must be done at the "nanocode" level. Frankly, I think that having thousands of instructions, arranged so that decoding patterns can be used, is much easier. One of the reasons for the problem is that such things as arranging which way the quotient and remainder are formed depending on the signs of the arguments is extremely clumsy in software unless at least the adjustment procedure is hardware. I cannot think of any reasonable method even in "microcode" to do the trivial operations to achieve this for the four combinations of signs, especially if the choices change at run time. I have read on this net of hardware which enables the user to specify _sometimes_ that a particular branch should be assumed, with an exception otherwise; I have not seen such. I have not seen any remotely efficient bit-handling hardware on any machine. (BTW, I am interested in seeing what modifications I must make to my procedures base on the architecture of particular machines; if you know of one which is sufficiently different, I would be interested.) Of the machines I know, only the 680xx, 8086 and similar (although otherwise I consider its architecture horrible), and 16/320xx have (I believe) the right integer operations. To do unsigned multiplication with only signed multiplication available requires that 2 conditional additions must be done after the multiplication; as machines get faster conditional operations are bad except in nanocode. Unsigned division is so complicated that one introduces other inefficiencies instead. BTW, there is an address modification procedure which is missing on all machines I have seen except the UNIVAC's. That is to consider the register file as a memory block and allow indexing on it. Another missing procedure is to enable the register file to be treated as a block of memory so that bytes or short words can be addressed. These two operations can be combined on a byte-addressable machine. I am definitely not the person to run this, but maybe there should be a mailing list to communicate suggestions about the manifold instructions which would be profitable in hardware. Also, I know a little about microcode (enough to know that what I think should be done cannot be done that way) and very little about nanocode. I find it relatively easy to read the manuals describing the machine instructions. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet