Need 286 "C" benchmark

Ron McDaniels ron at celerity.UUCP
Wed May 29 09:28:49 AEST 1985

In article <588 at intelca.UUCP> kds at intelca.UUCP (Ken Shoemaker) writes:
>Hmmm, once again Dave has submitted a benchmark that requires more than 64K
>of data.  This continued harping on the issue seems to indicate to me that
>maybe Dave realizes that for programs that require less than 64K of data
>that a 12MHz 286 actually keeps pace with the 16.67 MHz 68020.  Of course,
>he might not be saying this at all, and far be it for ME to try to read
>between his lines of code.....I would like to see the 680{00,10,20} 
>performance numbers and system configurations for these benchmarks, though,
>just for internal curiousity.
>It looks so easy, but looks sometimes deceive...
>Ken Shoemaker, Intel, Santa Clara, Ca.
>---the above views are personal.  They may not represent those of Intel.

I just can't let this go by (Lord knows, I should)!

If 64k segments aren't a problem and the "large system model" is so
blasted good (if you like to go into interpretive mode when you
execute), why does the 386 have a 32-bit segment length? 64k segments
are architecturally stinko. I realize you still have to sell chips so
that you can pay the bills, but stop making silly comparisons. The 8086
family are great for controllers and the like but I wouldn't want my
sister to marry one!  The 68000 and the 320xx are *much* better
machines in general applications simply because you *can* have data
objects (should I mention code segments?) larger than 64k bytes.

You know, I can remember having the same kind of "discussions"
re: 8080 -vs- 6502. Great fun!!!!

R. L. (Ron) McDaniels
9692 Via Excelencia Way
San Diego, California 92126
(619) 271-9940
{decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron

"The above views represent ALL right thinking individuals and anyone disagreeing
with them is obviously not playing with a full deck". 

(a smiley face for all you humorousless nurds out there that have to have 
even the most obvious attempts at humor spelled out to them in painstaking
detail   ;>)

More information about the Comp.lang.c mailing list