Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple
Subject: Re: ROM 04 GS and resolution
Message-ID: <12173@smoke.BRL.MIL>
Date: 18 Feb 90 02:54:21 GMT
References: <16747.apple.net@pro-sol> <2228@ultb.isc.rit.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <2228@ultb.isc.rit.edu> lmb7421@ultb.isc.rit.edu (Les Barstow: Phoenix) writes:
>I don't think we're being fair here - C compilers for the 68000 series
>are very well developed and ironed out for optimization.  However, the
>GS C compilers have not yet been written for speed - I seem to remember
>a comparison done back when the GS came out, all code written in
>Assembly for both machines, and the GS did rather well...

It doesn't much matter what is achievable in assembly language when one
writes his applications in higher-level languages, as is generally
recommended practice.

ORCA/C does perform numerous optimizations if you ask it to (by default
it doesn't perform any).  The problem with the 65816 is that it doesn't
have enough general-purpose registers to permit the degree of optimization
that for instance the 68000 does.  Its addressing modes are also not very
orthogonal to the instruction set, which also reduces opportunity for
optimization.  Finally, it has very weak support for large programs due
to the page-oriented architecture; this too forces inefficiencies.

>Remember, the average 65816 cycles/instruction is ~5, ...

And RISC architectures generally achieve more in a single cycle or two.