Thanks. No trace of WDC's compiler there... I think that the fact that it hasn't been got to work leaves it out of the comparison.

I read something about floating point here.

For some reason I want the people to be able to run this WDC C compiler. The comparison leaves CC65 as the one to be chosen because it's the one that works, having speed and code size against it.

Who are "the people"?

Personally, I am not interested in the WDC C compiler - mostly because it won't run natively under Linux and I don't feel I need it enough to bother with WINE, DOSBox or whatever just to run it. That may sound somewhat churlish, but really - if WDC want me to use it then they can make it easy for me to use because my time is precious to me and spending hours/days (as some have) just trying to get some code to work via it is not what I want to do.

So if/when I next need C I'll be using cc65 - because it works, and I was easily able to configure it for my systems (even though there is scant documentation on how to do that - and it's not just a matter of a new .cfg file - you need to alter the sources...)

As for floating point - I started to write my own IEEE compliant code and stopped and used my ATmega "co processor" to do the hard work for me (for my BCPL system - BBC Basic has excellent and faster floating point written in 65C02) There is an Apple FP library but I do not think they have ever published the sources (and I'm not referring to the Woz ones, but a separate library known as S.A.N.E.)

But... If someone can put together a rock-solid tutorial on the WDC C compiler to run under Linux from a Makefile, then I'll certainly take a look.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Well... anyone interested.


Found while research:

SANE _is_ IEEE-754/854, using single, double and extended precision (4, 8 and 10 bytes respectively). The SANE library was available for 8-bit Apple II models (used by AppleWorks, for example), and is part of the toolbox for the Apple IIgs and Macintosh. (my italics)

I don't know if the Apple IIgs toolbox is available for download, though. All I can find are books about it, but not it. Also, I don't know if the toolbox includes sources or binaries.



What I've been able to do is just installing wine through the package manager, and setting environment variables. I'll have to research (maybe trivial stuff for coders) how to prepare a working makefile that should be using... cc65? and mod it to use wdcXXXas and / or wdcXXXcc, as it seems to be needed.

It looks to me like the IIgs Toolbox is a part of the ROM. I think the various ROM versions can be found to download as binaries (they are needed to emulate the iigs) but I didn't have any luck finding a disassembly.

https://archive.org/details/GSOS_6.0.1_source

Inside the file there, there ise this IIGS.601.SRC/GSToolbox/SANE/ folder...

- elems.asm
- elems.macros
- sane.asm
- sane.macros

For me the other missing link is not just running the compiler but obtaining it as well. I've been pretty spoiled by projects and frameworks which include bash scripts to check for and install all the needed tooling. It's particularly helpful in modern workflows that involve developing on some disposable remote virtual instance, or simply to make it easier to teach others how to write for your platform. Pretty much everywhere I've worked encouraged writing/maintaining such scripts to speed onboarding and make equipment upgrades less of a headache.

This makes having to go to WDC's website, give them your email address, and wait to receive a *limited-use download link* really unappealing.

Well... They ask you not to disassemble the binaries, and not use them for commercial products that would run 65xx code in a chip provided by anyone else apart WDC themselves.

I can see that as a fair petition.

I would not recommend basing decisions on this pretty biased article. Someone pointed me to this comparison some time ago, because it seemed to mention a bug in my compiler (vbcc). Trying to verify this was made somewhat tedious, because the author of this comparison uses his own simulator and, in the case of vbcc, his own linker scripts and configuration files. After having a short look I found that the test that did not work with vbcc uses the pages 0x300 and 0x400 to write the results in a simulated frame-buffer or something like that. However his vbcc linker files contains:

I did not investigate further, but putting the data and bss section in the frame buffer does seem suspicious to me. As I did not want to waste much time with the tinkered configs, I slightly adapted the code to the C64 screen buffer and the result compiled with vbcc for C64 looked very similar to the one compiled with cc65. Strangely however, the player "sprite" only showed with cc65. Further investigation showed that the test code used an uninitialized variable for the y-coordinate of the player. After fixing this bug in the test, the result of vbcc exactly matched that of cc65.

When I tried to add a timer variable to measure run-time on the C64, the code did not compile anymore on cc65, because it exceeded the 256 byte limitation of cc65. Apparently the test was exactly tailored to cc65's limitations whereas the vbcc result was basically sabotaged. It is obviously not an unbiased comparison but rather the author started with code for cc65 and did no further investigations when the code did not work with a compiler he personally dislikes (whereas for gcc which apparently generated actually broken code he even went out of his way to fix the assembly code by hand). Using this approach your daily-use compiler will of course tend to look more stable. That does not really say much.

As I wrote above, I am the author of the compiler that the author of this comparison hates, so obviously I am not unbiased as well. When I checked his article, I did not write anything and I did not really want to get involved (and write lengthy posts like this one). However, if people point to this blog, I have to say that after what I have checked so far, it is my firm (and as my findings hopefully show mostly fact-based) opinion that this comparison is much too flawed to base a compiler decision on.

I did not spend much time with this article (mainly wanted to check if there was a bug in my compiler) and only limited time with other 6502 compilers. So I will not comment on the stability of the different compilers. I just can say do not use this article to base your decisions on. It is in no way a fair comparison.

Interesting, thanks. Just to note, the idea of a 256 byte limit in cc65 was new to me, but a search turns up this:
"There are some limitation on the size of local variables. Not all operations are available if the size of local variables exceeds 256 bytes."
(It's easy to imagine how that might have happened.)

FYI, vbcc comes with a fp library using wozfp as well as one using the SANE FP routines. They have been made into a linkable library by creating relocation information using two versions of the ROM for different memory locations. While using quite a lot of space they seem to be a very solid IEEE implementation. Surprisingly, they seem to be about as fast as the wozfp routines, even though they internally perform all calculations on 80bit format and most operands have to be explicitly converted to 80bit and back again. Of course that probably says more on the speed of the wozfp routines which shine when it comes to memory usage.

Yeah, I've been studying Woz' code for decades, and I haven't yet encountered an obvious example of him intentionally spending any bytes just to save some cycles.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

What would be a fair set of tests that could be created to make a comparison between 65xx C compilers?

Or FP libraries, regarding code size or calculation speeds?

Yes, it does not seem to contain a code path for handling stack-frames larger than 256 bytes. Probably not an unreasonable restriction. I guess the intersection of code that requires larger stack-frames with code that runs reasonable on a 6502 system will be limited. Also, cc65 is often used with an option that converts all local variables to static ones. Still a funny coincidence that the test juust fitted...

Well, that is a non-trivial area of science, basically. And it is made harder by the fact that the existing 6502 compilers do vary quite a lot regarding their goals/capabilities, and quite a lot of existing C code does not work on 6502. So, clearly not an easy task, but IMHO at least you should either use code that has not been written/pre-selected with any specific compiler in mind, or it should be adapted/optimized equally for all compilers.

As always, pointing out flaws is much easier than creating a flawless comparison.


That would probably be easier to compare, but some work is needed to create a test-framework that works equally with all fp libraries. vbcc can be used to compare wozfp and SANE, but at the moment no other fp libraries are available for it. Of course, if anybody wants to port another fp library to work with vbcc, that would be much appreciated.

Another way to go about it is to write the type of code you are actually going to be using the compilers for. You may not actually care if a particular compiler is better at doing something you don't need it to do.