🚀 go-pugleaf

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