6502.org

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)

There are no immediate plans to upgrade it. We are running the latest version in the 2.0 line and have made some additional patches on top of this. If you're aware of some specific security issues that we should address, please send them to me in a private message.

Can you elaborate on what they did and why they were not accepted?

Jim

* Static parameter passing (enabled with --static-params): uses fixed memory locations for parameter passing. Only applied to functions declared 'static' that don't have their address taken. The externally-visible calling convention is unchanged.

* 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.

I would be intersted in the patches for the 65816. I am just getting started in writing a library for my SBC-3. Having 65816 improvements would be helpful.

Daryl

I don't have any patches written. I stopped even _trying_ when the maintainer refused to help me understand the code well enough to create them.

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

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, . . .

Another non-gcc C compiler for 65816 is Ulrich Hecht's SNES SDK
There were some changes committed in August.

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.

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.