Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!agate!e260-1g!c60a-3hu
From: c60a-3hu@e260-1g.berkeley.edu (Phil Escamilla)
Newsgroups: comp.sys.apple
Subject: Re: HyperC stuff
Message-ID: <1990Feb19.095053.16139@agate.berkeley.edu>
Date: 19 Feb 90 09:50:53 GMT
References: <13874@phoenix.Princeton.EDU>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: c60a-3hu@e260-1g (Phil Escamilla)
Organization: University of California, Berkeley
Lines: 45

>Has anyone looked at the code HyperC produces--is it really good?  Or
>does it do 16-bit adds with a subroutine call (which is *REALLY* bad)?
>
>Which brings me to benchmarks: there are no really good compilers for
>the Apple //.  Besides, all useable Apple // programs are written in
>assembly anyways, so it doesn't matter.  Also, the //gs doesn't have
>mutliply or divide instructions, which makes 'standard' benchmarks run
>EXTRA slow on an Apple // (Dhrystones/sec on a //gs is like 300....I'm
>almost embarrassed to report numbers that low.....)

The Sieve benchmark doesn't require floating point nor mul/div instructions.
The 65816's architecture is such that it's difficult to write a compiler for
it but most of today's applications are done with compilers and not assemblers
The assembler link is simply becoz a lot of APple II programmers come from
an environment where compilers are lacking (mainly on the IIe) and the
programs are small enuff to not absolutely need compilers. Now this is 
absolutely nothing to be proud of.

>
>I've been wanting to write my own mult and divide routines using tables
>(128K for mult, 64K for div) and see how fast I can get it to work...
>but to make accurate comparisons, I need 68000 timings which I won't
>have a list of until this weekend...I remember calculating that the
>Apple // is twice as fast as a 68000 due to inefficiencies the 68000 has
>in accessing memory...

The believe is that if u have to kludge your programs badly and come out
with all these "ingenious" tricks u wouldnt have time for much else. It also
doesn't make the code portable easily. While u comparing the Apple // to a
2Mhz 68000? As I said the 68000 takes 4 cycles to access a 16-bit word and
the 65816 takes 3 (the 65C02 would take 4 in 2 instructions).
Of course this is notwithstanding the fact that u don't get bogged down by the
aweful paging scheme (I thot the 8086 was dumb). Anotherr reason why it's
absolutely hard to produce good compilers.


>
>The 68000 an orthogonal machine? -- HAH!  Not only are data and address
>registers isolated, but many instructions have severe restrictions on
>what addressing modes are valid (ABCD is a really good example of bad
>addressing mode availability..why can't it just add two 32-bit BCD
>numbers in data registers?)

Yep... the 68000 is far from perfect... take a look at the NS 32032 or the
RISC chips. But relative to the 65816 is definitely a hell lot better.