sasrer@mozart.unx.sas.com (Rodney Radford) (08/09/90)
Does anyone know how to check if an overflow occurs with the MULT instruction? Since this check will possibly be done very often, it is desired that the method be as fast as possible. -- Rodney Radford DG/UX AViiON developer SAS Institute, Inc. sasrer@unx.sas.com (919) 677-8000 x7703 Box 8000, Cary, NC 27512
jkenton@pinocchio.encore.com (Jeff Kenton) (08/09/90)
From article <1990Aug08.182206.22187@unx.sas.com>, by sasrer@mozart.unx.sas.com (Rodney Radford): > Does anyone know how to check if an overflow occurs with the MULT instruction? > Since this check will possibly be done very often, it is desired that the > method be as fast as possible. The hardware doesn't provide any direct way (as you've noticed). Two choices come to mind: * use floating point (double precision for enough accuracy) and check the results. * use ff1 instructions to find the magnitude of both operands to see if overflow can occur. Both of these are clearly slower than "multiply and check a status bit", but those are your choices. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jeff kenton --- temporarily at jkenton@pinocchio.encore.com --- always at (617) 894-4508 --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
jcallen@Encore.COM (Jerry Callen) (08/09/90)
In article <1990Aug08.182206.22187@unx.sas.com> sasrer@mozart.unx.sas.com (Rodney Radford) writes: >Does anyone know how to check if an overflow occurs with the MULT instruction? Grrrrrrr..... There are several bits of brain damage in the 88k, but this one takes the cake. As Jeff Kenton points out, your choices are to just convert to floating point and do your multiplication that way or to manually check the magnitudes. Both suck. Has anyone seen specs for the 88110? Is a fix for this stupidity going to be available in the next generation of the 88k? -- Jerry Callen jcallen@encore.com
jkenton@pinocchio.encore.com (Jeff Kenton) (08/10/90)
From article <12425@encore.Encore.COM>, I wrote: > > The hardware doesn't provide any direct way (as you've noticed). Two choices > come to mind: > > * use floating point (double precision for enough accuracy) > and check the results. > > * use ff1 instructions to find the magnitude of both operands > to see if overflow can occur. > Two more things come to mind on this subject: * If you use "ff1" instructions to see how big your arguments are, you discover that there is an indeterminate case where the answer is at least 2^31 but might be > 2^32. You can't tell for sure without doing as much work as the multiply. * Depending on the details of your problem, there may be a way to condition your values so that overflow can't occur. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jeff kenton --- temporarily at jkenton@pinocchio.encore.com --- always at (617) 894-4508 --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
meissner@osf.org (Michael Meissner) (08/11/90)
In article <12439@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: | From article <12425@encore.Encore.COM>, I wrote: | > | > The hardware doesn't provide any direct way (as you've noticed). Two choices | > come to mind: | > | > * use floating point (double precision for enough accuracy) | > and check the results. | > | > * use ff1 instructions to find the magnitude of both operands | > to see if overflow can occur. | > | | Two more things come to mind on this subject: | | * If you use "ff1" instructions to see how big your arguments | are, you discover that there is an indeterminate case where | the answer is at least 2^31 but might be > 2^32. You can't | tell for sure without doing as much work as the multiply. | | * Depending on the details of your problem, there may be a | way to condition your values so that overflow can't occur. Another thing that comes to mind is that the multiply on the 88k is pipelined (unlike say the MIPS). This means you can actually have 4 mulitplies going on at the same time. Thus you could restructure the problem to do 4 16 bit multiplies, and recombine the results. It's been six months since I programmed on an 88k, but if you have x in r2, and y in r3, an unsigned dmul would look like: dmul: extu r4,r2,16<16> ; top half of r2 extu r5,r2,16<0> ; bottom half of r2 extu r6,r3,16<16> ; top half of r3 extu r7,r3,16<0> ; bottom half of r3 mul r8,r4,r7 ; calc middle bits#1 mul r9,r5,r6 ; calc middle bits#2 mul r3,r5,r7 ; calc bottom bits mul r2,r4,r6 ; calc top bits ; wait for 2nd mul add r10,r8,r9 ; combine middle bits extu r11,r10,16<16> ; bits to add to r2 mak r12,r10,16<16> ; bits to add to r3 addu.co r3,r3,r12 ; add middle bits to lower br.n r1 ; return to caller addu.ci r2,r2,r11 ; add middle bits to upper + carry Thus if r2 != 0, the result can't fit in an unsigned 32-bit int. I believe for signed dmul's the test would be extract bit 31 of r3 with an ext instruction, and it should match r2 (ie, either 0 or -1). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?