I don't know about the LLVM backend, but the LLVM front end was moderately easy to hack with (I was developing a programming language).
(Aside: when is this forum getting upgraded? phpBB 2.0 is out of maintenance now and has known security holes)
A GCC backend for the 6502?
-
Mike Naberezny
- Site Admin
- Posts: 296
- Joined: 30 Aug 2002
- Location: Northern California
- Contact:
OwenS wrote:
(Aside: when is this forum getting upgraded? phpBB 2.0 is out of maintenance now and has known security holes)
- Mike Naberezny (mike@naberezny.com) http://6502.org
brain wrote:
VBR wrote:
So I hacked on cc65 instead, making some large, obvious improvements. (Note: the maintainer of cc65 did not accept them).
* Leaf function optimization (enabled with --leaf): leaf functions (i.e. functions that don't call other functions) use a special block of zero page memory (leafregbank). By default it is 16 bytes, but this can be changed with --leaf-space. If --leaf is combined with --static-params, leaf function parameters are passed directly in zero page. All locals in leaf functions use zero page (space permitting); the "register" keyword has no effect.
* Using the hardware stack for zero page save/restore (enabled by --hardware-stack): uses PHA for saving locals declared as "register". This is much faster than using the C stack, and often (but not always) more compact. Since the default maximum is only 6 bytes per function, there is not much risk of stack overflow, but it could happen.
* Optimizes zero page global pointers (marked with #pragma zpsym): pointers in zero page are now used directly, instead of being treated as if they weren't in zero page.
* Automatically use "fastcall" (enabled by --fastcall): automatically applies fastcall calling convention to static functions. This just saves having to type "fastcall" in function declarations. Despite its name, fastcall is not really faster, but it is more compact for functions called more than once.
* String merge (enabled by --string-merge): merges duplicate string literals.
---
I didn't make any effort to get them accepted, I just tossed out a big diff. So not too surprising that it was ignored.
I remember offering to contribute software patches to the cc65 maintainer to support the 65816. He also rejected them.
It seems to me that cc65's maintainer is hellbent on driving his compiler into utter obscurity. He's not contributor-friendly at all. If it's not HIS code and if it's not for the 8-bit 6502 ONLY, it's not going into the compiler.
I gave up in disgust.
If you want to hack on cc65, my recommendation is to fork the project and ignore the maintainer's pleas. It's basically what he recommended me to do anyway.
It seems to me that cc65's maintainer is hellbent on driving his compiler into utter obscurity. He's not contributor-friendly at all. If it's not HIS code and if it's not for the 8-bit 6502 ONLY, it's not going into the compiler.
I gave up in disgust.
If you want to hack on cc65, my recommendation is to fork the project and ignore the maintainer's pleas. It's basically what he recommended me to do anyway.
-
Rick Cortese
- Posts: 17
- Joined: 28 Sep 2009
Wouldn't it be too hard to implement these changes and maintain compatibilty with existing platforms? I mean except for a few bytes here and there platforms like the Atari and C64 seemed like they were designed with all of page zero belonging to the OS.
I mean even if you have conditional compilation the code for a one off SBC could get stuck in there forever.
Rick
I mean even if you have conditional compilation the code for a one off SBC could get stuck in there forever.
Rick
cc65 already targets Atari, Apple, and Commodore platforms, and no doubt more.
Zero-page usage isn't an issue. This is especially true when you consider that the 65816 permits a relocatable direct page -- you can put direct page anywhere in bank 0, even on a non-page-boundary if you are so inclined.
Additionally, you can now use the stack directly to reference variables, and to a limited extent, pointers as well.
Interfacing this to the host platform would be the responsibility of the C runtime library. (This, for example, is how you are able to run .COM and .EXE files in MS-DOS despite segmentation configuration differences.)
The biggest differences will be in the code generator. The 65816 has more opcodes, more addressing modes to optimize for (or out), and you can use the D (direct page pointer) register as a frame pointer while S (the stack pointer) continues operating as normal. (For those familiar with x86, D roughly corresponds with EBP while S corresponds with ESP).
The changes that'd need to be made are not trivial. But, not impossible either. If gcc can do it, . . .
Zero-page usage isn't an issue. This is especially true when you consider that the 65816 permits a relocatable direct page -- you can put direct page anywhere in bank 0, even on a non-page-boundary if you are so inclined.
Additionally, you can now use the stack directly to reference variables, and to a limited extent, pointers as well.
Interfacing this to the host platform would be the responsibility of the C runtime library. (This, for example, is how you are able to run .COM and .EXE files in MS-DOS despite segmentation configuration differences.)
The biggest differences will be in the code generator. The 65816 has more opcodes, more addressing modes to optimize for (or out), and you can use the D (direct page pointer) register as a frame pointer while S (the stack pointer) continues operating as normal. (For those familiar with x86, D roughly corresponds with EBP while S corresponds with ESP).
The changes that'd need to be made are not trivial. But, not impossible either. If gcc can do it, . . .
Ulrich Hecht's SNES sdk
Another non-gcc C compiler for 65816 is Ulrich Hecht's SNES SDK
There were some changes committed in August.
Quote:
SNES-SDK is a C toolchain and libraries targeting 65816 systems, specifically the Super NES (aka Super Nintendo, Super Famicom). It consists of a version of TCC equipped with a 65816 code generator
optimore-816
Elsewhere, a helpful person called Mic has announced an improved 65816 assembly language optimiser, to be plumbed into Ulrich's toolchain.
It's written in Euphoria, which I hadn't heard of. But it's fairly readable pattern matching (based on a previous Forth project) so could be considered portable.
It's written in Euphoria, which I hadn't heard of. But it's fairly readable pattern matching (based on a previous Forth project) so could be considered portable.
GCC 4.5 release
GCC 4.5.0 has now been released, with official support for the aforementioned named address spaces feature (as well as lots of other stuff). This release also ships with plugin support, which should make work on a 6502 backend much more feasible.
GCC 4.6 is now in its active development phase, so stay tuned for further news on the embedded targets front.
On the w65816 side, it would be nice to restore the support in gnu assembler (gas) which was zapped during their migration to the BFD library. This might enable gas to support the 6502 as well, which would be a prerequisite for gcc on either of these archs.
GCC 4.6 is now in its active development phase, so stay tuned for further news on the embedded targets front.
On the w65816 side, it would be nice to restore the support in gnu assembler (gas) which was zapped during their migration to the BFD library. This might enable gas to support the 6502 as well, which would be a prerequisite for gcc on either of these archs.