Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!cmcl2!husc6!cfa!ward
From: ward@cfa.harvard.EDU (Steve Ward)
Newsgroups: comp.misc
Subject: Re: R.I.P. BYTE:  Open Letter to The Editor
Summary: other reasons for slow 68K (really MAC) Smallc benchies
Keywords: BYTE, subscription, letter, fed up, Small C, Benchmarks
Message-ID: <1070@cfa.cfa.harvard.EDU>
Date: 3 Aug 88 00:02:15 GMT
References: <6646@well.UUCP> <5479@ecsvax.uncecs.edu> <717@mcrware.UUCP> <429@accelerator.eng.ohio-state.edu>
Organization: Harvard-Smithsonian Ctr. for Astrophysics
Lines: 48

In article <429@accelerator.eng.ohio-state.edu>, mills@baloo.eng.ohio-state.edu (Christopher Mills) writes:
> In article <717@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes:
> >
> > ... I am driven to the conclusion that their 68K Small C compiler has to
> >be truly horrible.  What is the reason for this?  I don't know, but the al-
> >ternatives that come to mind don't speak well for BYTE.
> >
> >		James Jones
> >
> 
> 	Well, Small C is not horrible, as long as you run it on an 8085.
> 
> 	I would imagine that all they did is change the code generation
> sections.  This is a real drag for the 680x0, because the Small C compiler
> assumes two general-purpose registers (HL and DE on the 8085).
> The 680x0 has 16 registers, 8 address and 8 data, so I imagine there is a
> lot of unneccessarry stack movement and register motion going on.  The
> 680x0 is at its best only when you keep lots of operands in registers.
> Not to mention all the neet 680x0 addressing modes that aren't being used.
> They also used int == 32 bits, which roughly doubles the time on the 68000

I believe Rick Grehan (of Byte benchies fame) stated that no
optimizations were done for any of the code generation.  His various
Smallc adaptations were also done from an 8085 version (2.1 or earlier)
rather than the new 8086 version.  The lack of peephole optimizing to
eliminate register data motion on the 68K no doubt contributes to the
poor MAC benchmark showing.  The conversion from int=16 bits to in=32
bits should not cause any slowdowns but is a possible source of
inefficiency if "hacked" into place.

Note that the MAC itself is likely to be a major source of slowness.
As I recall, the MAC (other than the MAC II) uses a 7.mumble MHZ
(almost 8 MHZ) 68000.  The 68k cpu is used for about everything:
it is time-sliced into four major function blocks. One is DRAM
refresh, two is mass storage (floppy) I/O controller, three is
bitmap display controller, and four is general purpose compute
engine.  This slicing is done in hardware.  Each 1/4 of the cpu
(implemented as four consecutive timing slots) is dedicated to
that function; the timing slot is dedicated to that function
whether there is something to do or not.  This means that the
MAC operating system AND user program only run in 1/4 of the
available cpu clock space, using only 1/4 of a approx. 8 MHZ
68000.  For this reason don't expect any computational benchmarks
to be sizzling on the original MAC product line.  I don't know if
the MAC SE follows this scheme, but I suspect it does.  The MAC II
definitely does not.  Disclaimer:  I got this information from
MAC users and we know how users can be! :-)

0