Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ptsfa!ihnp4!inuxc!pur-ee!uiucdcs!convex!trsvax!uhclem
From: uhclem@trsvax.UUCP
Newsgroups: comp.sys.m68k
Subject: Re: Recent Motorola ad seen in Byte
Message-ID: <193100003@trsvax>
Date: Fri, 17-Apr-87 16:38:00 EST
Article-I.D.: trsvax.193100003
Posted: Fri Apr 17 16:38:00 1987
Date-Received: Tue, 21-Apr-87 01:25:02 EST
References: <362@sbcs.UUCP>
Lines: 33
Nf-ID: #R:sbcs.UUCP:362:trsvax:193100003:000:1250
Nf-From: trsvax.UUCP!uhclem    Apr 17 15:38:00 1987


"Not another one."

All of this benchmarking-for-comparison may be pointless, particulary if you
happen to own a B0 or B1 386 (B1==current production, or so we are told
by our sales rep).

Check your benchmarks, and if they are doing any 32-bit multiplication,
all bets are off.  There is a problem with some 386 chips and it causes
the 32-bit multiply to yield incorrect results.  Why didn't you guys at
Intel say anything about this in your responses?

What good is a timing benchmark when the program does not yield valid results?
Perhaps the benchmark should be weighted by accuracy too.  :-)

However, you may be lucky and have a 386 that does not goof up, or
your benchmark might not use that instruction. 

Intel's public statement states that they will not discuss the yields on the
386, with regard to this problem.  The statement also said a new mask will be
in production in 2-3 months.

As for me, it's tough to program MMU's or paging systems, when you can't
trust the numbers the system generates.   You tend to trap a lot.

<The above is sort of my own opinion.>

						"Thank you, Uh Clem."
						Frank Durda IV
						@ <trsvax!uhclem>

"Now, don't have too many bits turned on in your numbers or the barrel-
 shifter might get hot."