Hi all,

I'd like to know if anyone is working on a 6502 backend for GCC, or whether writing such a backend would be of interest.

Traditionally, generating good 6502 code from GCC has been considered unfeasible, since the 6502 is not a general-register architecture. However, recent versions of GCC (since 4.4) have included a new register allocation phase which should perform much better on register-limited architectures such as the Z80 or the 6502. Furthermore, GCC backends can now be written to use a variable number of zero-page locations as 'soft-registers': this approach is well-established and used e.g. in the standard 68HC10 backend.

In addition, recent versions of GCC also include some support for an ISO C language extension known as "named address spaces". Together with special-case support from the linker and the GCC library, this extension could enable C programmers to use banked memory in a fairly intuitive way. Since banked memory is widely used in embedded systems, support for the 6502 could serve as a valuable testcase.

While a C compiler for the 6502 already exists (cc65), the project seems to be abandoned, and its code generation suffers from a lack of middle-end optimizations. It would be rather interesting to see what kind of code GCC can generate.

Any takers?

Although I'm not the person to ask about GCC, I would comment that when someone says the 6502 has no registers, the answer is that basically all of zero page is processor registers, all accessible in 3 clocks (most of the 6502's contemporaries couldn't do anything at all in 3 clocks) and useful for all pointers and indirects. Forth makes very efficient use of ZP for the data stack and of course page 1 for the return stack, almost as if the 6502 was specifically designed for it. Even multitasking is fairly simple in Forth on the 6502, although you would have to be pretty careful with stack space if you want to do more than about 4 tasks at once and go to say 6 or 8 or 10.

Related to its ZP performance, fetching operands' low byte first was not just some irritating quirk, but part of the scheme to make it more efficient with bus cycles, since it could assume correctly that it had to get a low byte anyway, and it could fetch it while it's still figuring out whether it's supposed to get a high byte.

Since you're new to the forum, we have no idea how familiar you are with the 6502, but I had used it for a few years before someone pointed out to me what should have been obvious. It was a new way of thinking for me.

Welcome to the forum.

2 nice advantages of getting GCC in the mix:

1. free and open source
2. way supported and quite popular

_________________
"My biggest dream in life? Building black plywood Habitrails"

Development on several platforms seems to be abandoned i.e. NES or slow but the core development is still going on.

Thread drift but it has been 20 years since I took a C class. I liked C back then. As much as I have seen it haven recently the language has evolved badly. Seems like it has become a Tower of Babel, bizare code, and forced style. The Obfuscated C Code Contest was supposd to be a joke.

Rick

If you want to see obfusctaed insane code, have you ever heard of a computer language called Befunge? It would blow your mind something fierce...

_________________
"My biggest dream in life? Building black plywood Habitrails"

I don't think the C language has been evolving badly or in the direction of obfuscation. The only difference between C in the late 80s and C today is the adoption of the C99 standard, which has added quite a few useful features including bool, inline and stdint.h types (int8_t, uint8_t, int16_t etc.).

The only innovation apart from that has been a few language extensions published by ISO. One of these extensions is targeted to embedded systems; it includes fixed-point arithmetic, the aforementioned named address spaces and support for hardware I/O operations. All of which could be of interest to 6502 developers.

He just announced a new release a few weeks ago.

Here among other places:

http://groups.google.com/group/comp.sys ... c2f?hl=en#

Evidently no support for the W65C816S.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yet...

_________________
"My biggest dream in life? Building black plywood Habitrails"

I remember seeing someone post a GCC backend for the sunplus 6502 variant but I haven't found it again yet.

It must still be out there somewhere.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Found it:

http://oric.ifrance.com/COMPILERS/gcc6502.src.tgz

But haven't checked the contents.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I am familiar wih that patch. It's severely out of date, the machine model is idiosyncratic and it depends on a proprietary library of 24-bit operations (which is not available); basically, it's an ugly hack tailored to Franklin organizers. Besides, the FSF insists on getting a copyright assignment for all official contributions.

This earlier effort can provide a few ideas, but a clean reimplementation is requred.

Considered a backend for LLVM? LLVM's optimizations are at least as good as GCC's, and theres already support for as confined architectures as the PIC18 series. It definitely supports what you need.

Also, no need for code assignment.

perhaps a modify of the 6809 libraries for GCC?

_________________
"My biggest dream in life? Building black plywood Habitrails"

A straightforward approach would be to treat the 6502 like a 16-bit RISC with a large, uniform register file, implemented as zero page memory. This allows a standard register allocator to be used. Ideally, the register allocation would be global (i.e. whole program) to make best use of the potentially large number of "registers" (up to 128).

I looked at LLVM a couple years ago, but it made my head spin. It's pretty hard to understand, at least for a non-"computer science" person like me. So I hacked on cc65 instead, making some large, obvious improvements. (Note: the maintainer of cc65 did not accept them).

Maybe I'll look at LLVM again...