65816 port of the vbcc C compiler

[vbc]

Hello,

I have just released the first version of a port of the vbcc compiler to the 65816 at: http://www.compilers.de/vbcc.html

It contains a C compiler, assembler, linker and ports of a C Library for the Apple IIgs, SNES and a simulator (which can easily be adapted to SBCs or embedded targets).

A few of the good things:

- compiler is under active development
- supports C99 (variable-length arrays, designated initializers etc.)
- generates optimized code (see dhrystones in sample directory)
- supports near-, far- and huge-pointers and memory models
- (limited) floating point support based on Steve Wozniaks code
- support for SNES hardware multiplication/division
- support for writing interrupt handlers
- attributes for putting variables into zero page
- supports file I/O on selected targets (IIgs)

If you want to have a look at the compiler, I would be interested in hearing your results.

Best regards,

Volker

[BigEd]

Splendid!

[barnacle]

And some excellent documentation, too. (Though my interest is in a generic WDC 65c02 target.)

Neil

[vbc]

barnacle wrote:

And some excellent documentation, too. (Though my interest is in a generic WDC 65c02 target.)

You can download the latest 6502 release of vbcc. It also has a simulator target that can be adapted to other targets. That release does not contain the chapter on adapting to other systems, but it is the same process as for the 65816. The 6502 simulator target does not provide a ROM-based configuration, but the 6502-nes startup code has initialization code. Or you can just translate the 65816 code after throwing out the far/huge-parts.

If you have any problems, just let me know.

[AndrewP]

C99 for the 65816? Sign me up!

I'm using the WDC C compiler at the moment (I believe it's mostly just the Zardoz compiler rebranded) and it's... frustrating.

Ultimately I'd like to write a low level intermediate language for the '816 that both C and C++ can compile to. But. I am years and years from that point.

I still need to be able to write (non asm) code now though and that's why vbcc seems really appealing. I think I tried Calypsi for a bit but there was something critical lacking so I stopped.

[fachat]

Excellent!

What memory models are supported? Can I restrict code to execute in a single bank?

My assumption is it completely runs in native mode, right?

[vbc]

fachat wrote:

What memory models are supported?

The compiler currently supports near (16bit), large (24/32bit segmented) and huge (24/32bit linear) data pointers. Mixtures (using explicit qualifiers) are possible depending on the target. Code is always large at the moment, but small code will probably be added later. This does not seem to make that much of a difference.

Quote:

Can I restrict code to execute in a single bank?

You mean whether you can put all code into a single bank? When using the linker to create e.g. a raw binary and the code fits then you can pretty much define any memory layout. As mentioned above, the compiler will nevertheless currently use jsl/rtl.

Quote:

My assumption is it completely runs in native mode, right?

Yes.

[vbc]

I have just uploaded a second release of the vbcc compiler for the 65816 at: http://www.compilers.de/vbcc.html

Changes since r1:
- new floating point format based on MSBASIC code
- more complete math library
- vc allows passthrough of linker options
- certain options like stack size can now be specified on the command line
- minor code improvements
- a few bug fixes
- new versions of vasm/vlink

The biggest change is the addition of a floating point library based on the 6502 MSBASIC code which has been MIT licensed. It is much, much faster than the wozfp-based code (the mandelbrot demo from the samples directory is about 10 times faster).

[BigDumbDinosaur]

vbc wrote:

I have just uploaded a second release of the vbcc compiler for the 65816...new floating point format based on MSBASIC code...It is much, much faster than the wozfp-based code (the mandelbrot demo from the samples directory is about 10 times faster).

10× speedup is a huge leap.    I had no idea the Microsoft FP code was that much more efficient than the Wozniak-Rankin version.  I take it you did some optimization to take advantage of the 65C816?

[vbc]

BigDumbDinosaur wrote:

10× speedup is a huge leap.    I had no idea the Microsoft FP code was that much more efficient than the Wozniak-Rankin version.

The Wozniak-Rankin code is highly optimized for size, but it is very slow. I think it does a lot of bitwise shifting without much speed optimizations.

Quote:

I take it you did some optimization to take advantage of the 65C816?

I did tailor the ABI/interfacing code to work well with the compiler generated code and I made a few optimizations (mostly on the fly at places that I had to touch anyway in order to get it to work on the 65816). The code uses byte accesses all the time and with 1 byte exponent and 3 bytes mantissa, there were not many opportunities to beneficially use 16bit instructions without rewriting even more of the code. I use it mostly when copying full numbers, but even there having to change into 16bit mode and back eats up quite a bit of the savings.

Not having benchmarked my changes, I do not think they make that much of a difference. The 6502 version shows a similar improvement over the Wozniak-Rankin code.

[BigDumbDinosaur]

vbc wrote:

The Wozniak-Rankin code is highly optimized for size, but it is very slow. I think it does a lot of bitwise shifting without much speed optimizations.

Interesting.  I have not looked much at the Wozniak-Rankin code, so I wasn’t aware that they were targeting size rather than speed.  I suppose it made sense in the days when RAM was precious and zero page space was even more so.

BTW, I must commend you on the documentation published with the vbcc compiler package.  It’s lucid and to the point.    That is a somewhat-uncommon quality in much technical documentation.