A GCC backend for the 6502?
A GCC backend for the 6502?
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?
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?
- GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Quote:
GCC backends can now be written to use a variable number of zero-page locations as 'soft-registers'
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.
-
Nightmaretony
- In Memoriam
- Posts: 618
- Joined: 27 Jun 2003
- Location: Meadowbrook
- Contact:
-
Rick Cortese
- Posts: 17
- Joined: 28 Sep 2009
Re: A GCC backend for the 6502?
BGXUQU wrote:
Hi all,
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?
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?
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
-
Nightmaretony
- In Memoriam
- Posts: 618
- Joined: 27 Jun 2003
- Location: Meadowbrook
- Contact:
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.
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.
Re: A GCC backend for the 6502?
BGXUQU wrote:
While a C compiler for the 6502 already exists (cc65), the project seems to be abandoned,
Here among other places:
http://groups.google.com/group/comp.sys ... ac2f?hl=en#
- BigDumbDinosaur
- Posts: 9425
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
CC65
Evidently no support for the W65C816S.
x86? We ain't got no x86. We don't NEED no stinking x86!
-
Nightmaretony
- In Memoriam
- Posts: 618
- Joined: 27 Jun 2003
- Location: Meadowbrook
- Contact:
- BitWise
- In Memoriam
- Posts: 996
- Joined: 02 Mar 2004
- Location: Berkshire, UK
- Contact:
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.
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
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
- BitWise
- In Memoriam
- Posts: 996
- Joined: 02 Mar 2004
- Location: Berkshire, UK
- Contact:
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
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.
This earlier effort can provide a few ideas, but a clean reimplementation is requred.
-
Nightmaretony
- In Memoriam
- Posts: 618
- Joined: 27 Jun 2003
- Location: Meadowbrook
- Contact:
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...
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...