Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #723 > unrolled thread

DHRYSTONE for Aztec C 3.2b

Back to article view | Back to comp.sys.apple2.programmer

Contents

  DHRYSTONE for Aztec C 3.2b "Bill Buckels" <bbuckels@mts.net> - 2013-05-26 23:15 -0500
    Re: DHRYSTONE for Aztec C 3.2b Egan Ford <datajerk@gmail.com> - 2013-05-27 08:26 -0600
      Re: DHRYSTONE for Aztec C 3.2b Michael J. Mahon <mjmahon@aol.com> - 2013-05-27 09:44 -0500
        Re: DHRYSTONE for Aztec C 3.2b "Bill Buckels" <bbuckels@mts.net> - 2013-05-27 22:45 -0500
      Re: DHRYSTONE for Aztec C 3.2b "Bill Buckels" <bbuckels@mts.net> - 2013-05-27 22:37 -0500
        Re: DHRYSTONE for Aztec C 3.2b Egan Ford <datajerk@gmail.com> - 2013-05-28 08:15 -0600

#723 — DHRYSTONE for Aztec C 3.2b

1. The results for DHRYSTONE that I have found for Aztec C are based on the 
CII version from circa 1983 and not the ProDOS 8 3.2b offering from 1986 
through 1990.

I am in the process of compiling a DHRYSTONE for the newer compiler. I will 
post the results when I am done.

2. I have also seen bizarre comments from advocates of another 
cross-compiler for the Apple II and Commodore 64 which are dismissive of the 
Commmodore 64 Aztec CII cross-compiler version which offers a rich 
environment for that platform, and which DHRYSTONE I will be providing in 
the days ahead as well, without much anticipated problem.

3. On the Apple II side, version 3.2b of the Aztec C cross-compiler provides 
full support for building Stand-Alone applications for both DOS 3.3 and 
ProDOS 8 which include file I/O for both targets, and also supports a ProDOS 
8 Unix-like Shell as an additonal target for building command-line utilities 
etc.

A paralell native-mode version of Aztec C 3.2b is also available for the 
Apple II.

These I will DHRY as well.

4. Aztec C also provides Z80 native mode mode and cross-compilers for Apple 
II's and Commodore 64's for CP/M 80. I will do my best to provide some real 
performance results for these as well.

5. I will not be providing comparable results for compilers other than Aztec 
C for the Apple II or Commodore  64. The users of those can respond to my 
results without being dismissive if they so desire.

More to follow later. For now let's just say that all the Aztec C compilers 
that are available form the website are not only workable and usable, but 
come with too many working examples to dismiss. Where did all the programs I 
have provided that were compiled under Aztec C come from and why do they all 
work for me?  One wonders...

Bill 

[toc] | [next] | [standalone]

#724

On 5/26/13 10:15 PM, Bill Buckels wrote:
> 2. I have also seen bizarre comments from advocates of another
> cross-compiler for the Apple II and Commodore 64 which are dismissive of the
> Commmodore 64 Aztec CII cross-compiler version which offers a rich
> environment for that platform, and which DHRYSTONE I will be providing in
> the days ahead as well, without much anticipated problem.

What bizarre comments?  What cross-compilers are they comparing to?

Given that DHRYSTONE is integer computation only, I expect that cc65 
will produce much faster results with smaller binaries.  That has been 
my experience with integer centric benchmarks.

You may also want to give WHETSTONE a shot as well since it is 
floating-point based.  cc65 will have to report a big N/A since cc65 has 
no support for floating-point math.

[toc] | [prev] | [next] | [standalone]

#725

Egan Ford <datajerk@gmail.com> wrote:
> On 5/26/13 10:15 PM, Bill Buckels wrote:
>> 2. I have also seen bizarre comments from advocates of another
>> cross-compiler for the Apple II and Commodore 64 which are dismissive of the
>> Commmodore 64 Aztec CII cross-compiler version which offers a rich
>> environment for that platform, and which DHRYSTONE I will be providing in
>> the days ahead as well, without much anticipated problem.
> 
> What bizarre comments?  What cross-compilers are they comparing to?
> 
> Given that DHRYSTONE is integer computation only, I expect that cc65 will
> produce much faster results with smaller binaries.  That has been my
> experience with integer centric benchmarks.
> 
> You may also want to give WHETSTONE a shot as well since it is
> floating-point based.  cc65 will have to report a big N/A since cc65 has
> no support for floating-point math.

And, barring pathologies, the compiler should be a "don't care", since
virtually all the execution time will be in FP subroutines (though if those
are part of the runtime library, then maybe that's your point). 

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[toc] | [prev] | [next] | [standalone]

#727

"Michael J. Mahon" <mjmahon@aol.com> wrote:

> And, barring pathologies, the compiler should be a "don't care"

It has been my experience that it is not only pathological compilers that 
don't care... :)

[toc] | [prev] | [next] | [standalone]

#726

"Egan Ford" <datajerk@gmail.com> wrote:
> I expect that cc65 will produce much faster results

Not much faster. Aztec C65 3.2b on an Apple IIe runs DHRYSTONE at about 
75-80% of the speed of CC65 on a Commodore 64 as near as I can tell thus far 
(but like you at one time, I now need finer granularity than the time 
function in Aztec C time function provides to produce DHRY results that are 
repeatable and verifiable so I am currently deciding the best way to do this 
and still maintain DHRY's integrity). I have no stats for CC65 DHRY on an 
Apple II.

The Aztec CII Commodore 64 version that I have put together comes with a TOD 
sample program which provides sufficient granularity to accurately calculate 
DHRY. I suspect that I will achieve a similar difference in DHRY between 
cc65 and Aztec CII on a C64 since the libraries are almost identical and the 
compiler is identical.

Any of this may constitute a small and unimportant hit in hit in performance 
for the application programmer who may want some of the other options that 
Aztec C or my extensions to Aztec C can provide. Like file I/O in DOS 3.3 or 
easily building SYS programs or programs with Overlays from the comfort of a 
Windows Machine.

> with smaller binaries.

Smaller binaries have their place as does assembly language. PCODE also has 
its place. Feature-rich applications are sometimes larger than hello world 
programs. Both have their place.

> What bizarre comments?

Comments of the nature that it is too difficult and time consuming to use an 
old but functional K&R compiler. That is certainly not my perspective 
(Obviously:)

> You may also want to give WHETSTONE a shot as well since it is 
> floating-point based.  cc65 will have to report a big N/A since cc65 has 
> no support for floating-point math.

I could give you a much longer list of features that are exclusive to the 
Aztec C environment.

I could also give you and even longer list of run-time libraries, programs 
and tools that I have provided with Aztec C that still make it highly usable 
even after being around for 30 years.

I should also mention that I've had good success in porting the old Aztec 
CII libraries from RubyWand's old version to that CII cross-compiler from my 
early efforts. I used several different approaches than you did when you did 
so years back, and also have become quite intimate with the transitional 
differences, and in how console output differs between the CII Shell and the 
SA libraries, Zero Page Use etc.

But I want to get this DHRYSTONE stuff out of the way before telling those 
other stories which of course will be accompanied with many working examples 
and some rather large documents.

Bill 

[toc] | [prev] | [next] | [standalone]

#728

On 5/27/13 9:37 PM, Bill Buckels wrote:
> "Egan Ford" <datajerk@gmail.com> wrote:
>> I expect that cc65 will produce much faster results
>
> Not much faster. Aztec C65 3.2b on an Apple IIe runs DHRYSTONE at about
> 75-80% of the speed of CC65 ...

You are correct.  I measured 70% & 80% (cc65 2.13 and 2.12 
respectively).  However a 30% reduction in time is still significant (or 
'much faster' IMHO) if performance is your only metric.  That is the 
problem with benchmarks.  They try to distill the value of a 
system/compiler to a single number.

>> What bizarre comments?
>
> Comments of the nature that it is too difficult and time consuming to use an
> old but functional K&R compiler. That is certainly not my perspective
> (Obviously:)

Now that is bizarre given that the systems they code for are "old but 
functional".

I must admit I had forgotten the nuances of K&R when I started my 
exploration of Aztec C.  And, unfortunately, I quickly dumped my 1st Ed. 
K&R C book when the 2nd ed. ANSI version was released in the late '80s. 
  Fortunately, I was able to pick up a used copy from Amazon dirt cheap. 
  I would encourage others to do the same.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web