A new C compiler for the 6502 and derivatives

[handyandy]

I scanned my copy of the Hyper C manual this weekend. Here it is...

Cheers,
Andy

[barrym95838]

Good stuff! Thanks Andy!

Mike B.

[handyandy]

Hi Mike,

You're welcome! I learned a lot from it.

Cheers,
Andy

[jamestn529]

Reading the HyperC manual, and writing a bit more test code, I still can't decide on using a register or accumulator architecture for the bytecode. I appreciate you finding the HyperC manual, that's a great resource, Andy!

I see two ways to do the bytecode compiler: (1) a HyperC-like register based bytecode, perhaps with more registers (A, B, r3, and so on), and (2) a Forth VM-like bytecode, with a top-of-stack register. I'm leaning towards the second approach. The first would incur costs from register-to-register moves, where as the second would only deal with indexing and popping overhead (1 cycle for X indexing, 2 for INX/DEX). Is there any good reason to use the first approach?

Of course, another backend can be written for the compiler. I need one to focus on, however.

[handyandy]

Hi James,

I can only comment on HyperC as that's what I'm most familiar with. The manual defines a 16 bit VM that uses the zero page as 16 bit registers and defines a set of pseudo-opcodes for the interpreter. The interpreter works very much like the FIG FORTH's inner interpreter except for its definition of the VM. I guess it depends on how much of a stack you want to use. HyperC uses a software stack set at high memory that works downward and is not confined to 256 bytes. HyperC's return stack (at least for the 6502) is still in page $1. HyperC's software stack is like FORTH's data stack except it uses a zero page location for a pointer instead of a machine register. More details regarding HyperC may be found here: http://mirrors.apple2.org.za/ground.ica ... es/Hyperc/ . As far as I know there was a HyperC compiler for the Apple IIe/c and the Apple Macintosh.

Maybe you can borrow ideas from both approaches...

Cheers!
Andy

[resman]

I went through many of the same thoughts when designing PLASMA. Over the years, I took a number of approaches to solving similar problems that you are facing. One was the native code vs bytecode code generation. I ultimately went with bytecode only in my last implementation, thinking I would implement a JIT if I wanted optimized native code. Bytecode has a number of benefits including code density, relocatability, and ease of execution from "external" memory - auxiliary memory in an Apple //e or extended memory in an Apple ///. For the previous version, I did write a back-end code generator that would spit out native 6502 for the more basic ops, and call into the VM for the larger ops. Code size explosion kept me from outputting 6502 for every op. It did very basic peephole optimizations and tracked the TOS so it didn't need to DEX/INX all the time. PLASMA is about a simple compiler as you'll find (thus its name - Proto Language AsSembler). It might be of some use if you want to see what I tried. Maybe you'll get inspired and do something much more intelligent. You can browse the source for the code generator on the backwaters of SourceForge (yeah, it was that long ago):

http://vm02.cvs.sourceforge.net/viewvc/ ... iew=markup

I had other implementations of PLASMA that could return multiple values like all the cool new languages do nowadays, but I couldn't figure out a robust way to handle values that might get left dangling on the stack.

Dave...

Edit: make sure I had the correct version link

[handyandy]

After obtaining permission from the author I have had the source code to the Apple II HyperC operating system uploaded here: http://mirrors.apple2.org.za/Apple%20II ... ce%20Code/

I also have a *.zip of text files for those interested in the source code. Attached here: See the read.me file for instructions.

Cheers!
Andy

[BillO]

With the WDC tools now being free, isn't this kind of moot?

Interesting, but only for retro hobby stuff. Which I love BTW...

[handyandy]

At the time I thought it was an interesting implementation of a high level language for a 6502-based machine. I liked it better than BASIC or Pascal. I might have gone with Forth if there was documentation available at the time. Maybe there was but I couldn't find it. As of now it may have educational value. I still use it now and then...

Cheers,
Andy

[BigEd]

BillO wrote:

With the WDC tools now being free, isn't this kind of moot?

Hmm, I don't know all the details, but my first guess would always be
- better to have one more tool than one fewer
- better to have a tool under community stewardship
- better to have a tool with source available
- better to have a tool which will still run with all features in N years time

Which is to say, WDC probably won't have released sources, might withdraw their offer, might be offering something less than fully featured, probably won't be very responsive to bug reports.

[BillO]

BigEd wrote:

BillO wrote:

With the WDC tools now being free, isn't this kind of moot?

Hmm, I don't know all the details, but my first guess would always be
- better to have one more tool than one fewer
- better to have a tool under community stewardship
- better to have a tool with source available
- better to have a tool which will still run with all features in N years time

Which is to say, WDC probably won't have released sources, might withdraw their offer, might be offering something less than fully featured, probably won't be very responsive to bug reports.

Good points.

[Proxy]

Hi, I was just wondering if this is still an active project.

CC65 updates... sometimes, and WDC also have their own Compiler.
but I don't really know if either were improved much ever since this thread started.

but even then, as bigEd said, it's always better to have another option.

as far as i understood the thread there are basically 2 options
1. where the Compiler outputs code that natively runs on the target CPU, which is probably the most efficient option but also requires the Compiler to directly support each target CPU
2. where the Compiler outputs intermediate code that runs on a sort of VM on the target CPU, which adds a lot of overhead when running anything on it, but also means that supporting another CPU can be done by "just" porting the VM to that CPU. (overall Java but it's C)

Sorry I can't contribute much more to the discussion.

[BitWise]

I've been debugging the WDC 65C02 C compiler and have got it to a state where it crashes a lot less often and produces runnable code -- I've been using it to write demos for the W65C165MMC module.

I have to finish cleaning up the library and header files and then figure out with WDC how to get it released.

My home PC died a couple of weeks ago and I've lost some recent work but the main changes were checked into Git so hopefully not too much is gone for good.

[Proxy]

BitWise wrote:

I've been debugging the WDC 65C02 C compiler and have got it to a state where it crashes a lot less often and produces runnable code -- I've been using it to write demos for the W65C165MMC module.

I have to finish cleaning up the library and header files and then figure out with WDC how to get it released.

My home PC died a couple of weeks ago and I've lost some recent work but the main changes were checked into Git so hopefully not too much is gone for good.

that sounds good, but where would one get that fixed compiler? I currently got version 3.49.1

also are there any examples given for both C code and maybe a batch file that generates a binary? because i appear to be too stupid to do it myself.
but i don't really want to derail the thread, so maybe later i'll just make a "WDC C question" thread or something, as a place to ask stupid questions about how to actually use that thing.

[dmsc]

Hi!

Proxy wrote:

Hi, I was just wondering if this is still an active project.

CC65 updates... sometimes, and WDC also have their own Compiler.
but I don't really know if either were improved much ever since this thread started.

but even then, as bigEd said, it's always better to have another option.

There is another option now, the VBCC compiler port to 6502 http://www.compilers.de/vbcc.html see the announcement: viewtopic.php?f=2&t=6100

Also, there is a lot of activity lately in the CC65 project, many bug-fixes and new optimizations, over https://github.com/cc65/cc65/.

Have Fun!