Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!rochester!PT!b.gp.cs.cmu.edu!ralf From: ralf@b.gp.cs.cmu.edu (Ralf Brown) Newsgroups: comp.sys.intel,comp.lsi,comp.arch Subject: Re: 80386 Multiply: quote from Intel Message-ID: <87@b.gp.cs.cmu.edu> Date: Tue, 25-Aug-87 19:11:40 EDT Article-I.D.: b.87 Posted: Tue Aug 25 19:11:40 1987 Date-Received: Sat, 29-Aug-87 09:05:50 EDT References: <576@obiwan.UUCP> <7939@sci.UUCP> Organization: Carnegie-Mellon University, CS/RI Lines: 52 Xref: mnetor comp.sys.intel:333 comp.lsi:211 comp.arch:1974 In article <7939@sci.UUCP> ken@sci.UUCP (Ken Karakotsios) writes: >In article <576@obiwan.UUCP>, mark@mips.UUCP (Mark G. Johnson) writes: >> >> Another interesting facet of the problem hasn't been mentioned >> yet --- the 80386 doesn't have a multiplier (!!). The 386 uses >> its general-purpose ALU, plus a shift-and-add microcode routine, >> to perform multiplication operations. Similarly, divide operations >> use the ALU plus a shift-and-subtract microcode routine. >> >> The confusing thing is, why do multiplys fail but divides and >> adds (apparently) work?? Isn't it possible to supply the >> appropriate "bad" ALU operands for a regular add, or to create >> them during some step of a divide? > > This is just speculation, since I know nothing about the 386 design. >If they are using a shift and add for multiplication, then they may have a >special shift-by-two-bits latch. [..."modified Booth algorithm"...] The 386 need not use a shift-by-two-bits latch. One thing that needs to be taken into account is that during normal instruction execution, time is needed to decode the instruction and fetch the operands (even in a pipelined machine). A microcode routine, on the other hand, needs no time to fetch and decode instructions, so the ALU can be run full-tilt. While I don't know the internals of the 286, the instruction timings for MUL and IMUL (and the following experience) lead me to believe that it uses a simple shift-and-add routine in microcode, with one shift and one add per clock cycle. My AT had an 8MHz 80286 being run at 9.83 :-) MHz, which went slightly flaky after about 6.5 months (I started seeing one line in the Turbo Pascal and Turbo C editors at the wrong place on the screen). I tracked this down to an 8-bit MUL instruction which lost one or two carry bits when the high bit of AL was set and the other operand had sufficient 1 bits to cause a cascade of carries on adding the last term (corresponding to the high bit) to the result. The CPU has since been replaced [under warrantee, this system was sold as a 10 MHz system]. BTW, the specific operands that caused the problems in the Turbo editors were 0A0h in AL and 0Fh as the other operand. (line 15 on the screen--wound up in the middle of line 4 when the MUL yielded 160h instead of 960h) And yes, the problem was temperature-dependent, at least initially--cranking up the air conditioner made it go away. Later it got to the point where, after the first six or seven minutes while the CPU was warming up, even cranking up the air conditioner or opening up the system didn't help. -- -=-=-=-=-=-=-=-= {harvard,seismo,ucbvax}!b.gp.cs.cmu.edu!ralf =-=-=-=-=-=-=-=- ARPAnet: RALF@B.GP.CS.CMU.EDU BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA AT&Tnet: (412) 268-3053 (school) FIDOnet: Ralf Brown at 129/31 DISCLAIMER? Who ever said I claimed anything? "I do not fear computers. I fear the lack of them..." -- Isaac Asimov