From: lindblad@cc.helsinki.fi
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: 040 and 486_ (bunch O' Kaka anyway)
Date: 17 Apr 92 15:28:43 GMT
Organization: University of Helsinki

In article <1992Apr16.144345.10264@ctr.columbia.edu>, jerry@connection.prospect.com (Jerry Shekhel) writes:
> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:

> Look, Mike, it's obvious that no compiler will generate optimal code for any
> CISC processor.  You can stop throwing tantrums trying to make that point;

And why do you say 'for any CISC processor'? The current top CISC chips (68040
& 486) need (well, at least 040 needs :) very careful instruction ordering like
the RISC chips - also on 68040 compiler should understand that 040 has copyback
mode on data cache and therefor optimize programs so that they would use it
well.


Can anyone tell me what pipeline stages do 486 have as I do not know?
 

> it's well known.  However, if most software is written in high-level
> languages, what's the point of doing an assembly-language benchmark?  I do

Because we did not want to see which compiler generates the best code or which
code generator on GCC is better but to see which CPU is faster - however it's
my opinion, that you can not test the speed of different CPUs of different
families with benchmarks or applications. All testing _must_ be done in theory.

> know that GCC won't produce optimal 680x0 code, nor will it produce optimal
> 80486 code.  However, the quality of its code will be indicative of (if not

What if 68040 needs very much optimizing and 486 only a little and GCC
optimizes as much on each CPU or vice versa.

> better than) the code quality of most of the applications.  That's why I
> believe it would make for a fair test.

Nope. It may tell you how well GCC optimizes for 486 and 040 if you know how
fast the chips would perform the same operations with fully optimized code.

> That's stupid, Mike.  We could play these games for hours.  "Well, on the x86
> you don't have to do any looping in order to copy or fill a block of memory."

Well, the speed in which 68040 copies blocks is however quite good as there is
new move16-instruction on it (it uses burst reads and burst writes to copy 16
bytes) (well, of course the is a small performace hit becuse we need one or two
instructions more to copy large areas, but still copying is very fast). Does
486 have burst writes?

> 
>>
>>Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)
>>
> --
> +-------------------+-----------------------+--------------------------------+
> | Jerry J. Shekhel  | Molecular Simulations | Time just fades the pages      |
> | Drummers do it... | Inc.  Waltham, MA USA | in my book of memories.        |
> |    ... In rhythm! |     (617) 890-2888    |              -- Guns N' Roses  |
> +-------------------+-----------------------+--------------------------------+
> |           ...! [ princeton mit-eddie bu sunne ] !polygen!jerry             |
> |                            jerry@polygen.com                               |
> +----------------------------------------------------------------------------+


--
Jarkko Lindblad
lindblad@cc.helsinki.fi
Newsgroups: comp.sys.amiga.advocacy