Re: [cc65] Benchmarks

Hi!

On Sat, Oct 17, 2009 at 11:40:43PM +0200, Oliver Schmidt wrote:
> Now that 2.13.0 is released - and seems to generate significantly
> faster code than 2.12. - it seems a good time to revive this thread,
> doesn't it?

Actually, I've spent some time trying to benchmark one other compiler but
failed miserably. I've downloaded Aztec C for the C64 (version 1.05h) and
tried to compile the dhrystone benchmark, because it's rather old and already
K&R style.

After stumbling two hours from problem to problem, I finally decided not to
spend more time with it, simply because it's not worth it and I have better
things to do. This compiler has probably been a great piece of work 25 years
ago, but measured at todays standard it's a nightmare from the stone age. Here
is an incomplete list of problems I've encountered and (partially) solved:

  * DOS binaries. This means you have to compile in dosbox and if the compiler
    goes berserk (something I experienced quite often) you have to kick off
    the complete DOS box including your command history and start over with a
    fresh one. This does also mean that the usual DOS limitations apply, for
    example filenames and low memory. The following is a shortened text from
    one of the header files:

   /* Note: You probably shouldn't use headers as includes in your C64
    * programs unless absolutely required.
    * Consider using them for information only unless building library 
    * functions and even then use them sparingly.
    * Isolate the values you need and
    * put either the defines or their constants directly into your programs.
    * The issue here is that the compiler runs out of memory if too many
    * defines are used, because it needs to store a list of substitutions
    * and the string literals take up memory quite quickly. 
    */

  * None of the tools outputs a command line help. You have to dig through the
    docs.

  * The sources need a Ctrl-Z at the end. If the compiler doesn't find one, it
    starts over and over generating a multi-megabyte assembler file. You
    cannot stop the compiler in this state, when it is called from within
    make, so you have to terminate the DOS box. I had to use a hex editor on
    the sources to fix them.

  * The compiler doesn't know "void". When translating existing code, you need
    something like

        #define void int

    in your sources.

  * The compiler doesn't support the "unsigned long" data type. If you have
    newer sources, this can be a problem.

  * Error messages are sparse. This is the error message you get, when trying
    to use "unsigned long":

        test.c:line 3:error 18, ''

    Fortunately, the source line is also output, so you can often guess what
    the compiler is complaining about.

  * Almost no standard functions. There's no memcpy or such. I've tried to
    write a clock() function using inline assembler, but cannot tell if it
    worked.

  * Structs can be assigned but not in an initializer list.

  * The linker needs to be told where to place code and data segments. There's
    nothing wrong with that, but I couldn't find a setting that worked. I've
    used the makefile from one of the examples, but the given values were much
    too small for the dhrystone benchmark. When trying several different
    setups, I had the same problem as with the assembler: One of the tools,
    either the linker or the mkbasic program runs forever and generates a
    multi-megabyte output file before it gets stopped (by terminating the DOS
    box).

Some of the problems seem to be related to using the tools from within make.
If I run the compiler for itself, it can be aborted by Ctrl-C, but when run
from within make, I had to close dosbox. Others are related to dosbox. It
doesn't detect new files in a directory once it runs, so I have to close and
reopen it when creating new files from the outside. This may be better under
Windows. I've also heard that the apple version of Aztec C is newer, but I'm
more a Commodore guy and wouldn't even know which emulator to use :-)

So as said above, there won't be any benchmark results for Aztec C from me.
There seems to be a 6502 port of the lcc compiler floating in the net, maybe I
have more luck with this one. But as far as I've found out until now, it does
only generate code for the Oric, and the source of the compiler does only
compile for windows (which - if true - is an accomplishment by itself, since
the original lcc sources compile fine for other platforms). Let's see ...

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.