Hi all.

I noticed a while back site www.gnuxtools.com which provides $$$ compiled gnu assebler for 65xx/65xxx cpus.
From that info I went and picked up the binutils, gdb and gcc latest packages from ftp.gnu.org and though if I'd get lucky. Result was: binutils compiled and seems to provide correct code (AT&T assembly format), gdb and gcc configure but make pukes with *** Configuration w65-wdc-none not supported, make: *** [configure-gcc] Error 1.
I'm interested to know if anyone is trying to get the last 2 apps to compile for w65 as target.
I'd be happy to do test runs if someone with C _skills_ would start porting of the apps.
From seeing from cc65 and lcc I wasn't really happy with the code they provide from the C processor and I'd really want to code on some high level language (BASIC and fortran aren't counted :)

Regards:
nut trying to get free world apps to do the job

Well, currently GCC doesn't support the 6502.

There once was a version of GCC that supported the 65816 - I happen to know the guy who did it. The port wasn't accepted into mainline because it required too many changes to the machine-independent sections. Therefore, only the binutils changes were accepted.

Also, GCC didn't produce very good code for the 65816. From a compiler standpoint, the 6502/65816 are too irregular to easily generate good code. You wind up using the X/A register pairs to hold 16 or 32-bit quantities, and use the Y register for indexing.

Toshi

From experience, gcc produces really crappy bloated code on most platforms (particularly AVR and suprisingly SPARC).

I think someone needs to stop hacking around with GCC and start again by writing a decent retargetable compiler with separate optimised 8, 16, 32 and 64 bit backends (separately).

Your first mistake is thinking that C is somehow a "high level language." It's patently not. It's type checking rules leave much to be desired, it's about as modular as molten lego bricks, and relies too much on machine-specific details to get things right.

C has always been a middle-level language -- it was first designed to port Unix from the PDP-8 to the PDP-11. Previous to that, Unix had been written in pure-bred assembly language. Thus, C, unsurprisingly, is nothing more than a glorified assembler with more convenient syntax.

C also is a language that still shows its PDP heritage. It places too many assumptions on the underlying hardware architecture. Notice how all major processor architectures evolved towards a common model: flat address space, fairly decent number of registers, two operating privilege modes. Period. If your processor doesn't conform to this basic model, your processor is considered either anachronistic or bogus in design (e.g., x86 segments are DAMN USEFUL if you actually work WITH them instead of against them!! But NOOOooo, C programmers wouldn't have any of it. Note that people didn't start complaining about x86's segmentation until people tried to port their software to C for the PC!! And note how most early RISC processors expressly supported hardware tagging to support more dynamic languages like Lisp and Smalltalk, facilitating lightning fast garbage collection. Where is that today? You would think that with the wild popularity of Java, SOMEONE would have recognized the sheer importance of hardware-assisted garbage collection!).

If you want a true high level language, you'll need to program in a functional programming language, something like ML or Haskell. But as there are no such compilers for the 65816, you probably won't be doing that.

Because of C's architectural demands, C software will NOT run fast on a 65816. Therefore, it is strongly urged that you use a more processor neutral language (e.g., Forth, compiled BASIC, etc -- I am personally biased towards Forth), or use a language specifically tailored for the underlying processor itself (I'm not aware of any for the 65816), if you wish to get better performance from your 65816 application.

If you wish to continue to use C, by all means, do so. My little rant above is not meant to dissuade anyone from using C, nor am I blaming C itself for being what it is. I like C, really, I do. But it's just one of many languages in my toolbox, and as a general rule, I prefer others. It's more a venting on how the *world at large* makes C out to be this holy grail of languages when it's patently and provably not.

We now return to our regularly scheduled technical discussion.