6502 port of the vbcc C compiler

[vbc]

Hello,

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

It contains a C compiler, assembler, linker and a very rushed port of a C Library for the C64.

A few of the good things:

- compiler is under active development
- supports C99 (variable-length arrays, designated initializers etc.)
- generates optimized code (I get >210 dhrystones/s on a C64, see sample directory)
- (limited) floating point support based on Steve Wozniaks code
- support for writing interrupt handlers
- attributes for putting variables into zero page
- supports stack-frames > 256 bytes

On the bad side, it needs more testing and some features are not yet fully implemented. Especially the C library is currently probably only usable for some tests as it is much too big and not at all optimized for 6502. Also, I do have not much experience with any 6502 machines beside the C64. For the future a C library that is optimized for the 6502 and supports more targets would be much desirable.

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

Best regards,

Volker

[BigEd]

Thanks Volker - that could be a very welcome addition to the toolchest.

[commodorejohn]

Nifty

[vbc]

vbc wrote:

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

I have now uploaded a new version at: http://www.compilers.de/vbcc.html

Major changes since Alpha 1:

- fixed some bugs
- added NES target including lazyNES library (NES) (thanks to Matthias "lazycow" Bock)
- added support for banked memory and far pointers
- added 32/64bit IEEE compliant floating point based on SANE (thanks to Andy Werner)
- added argv handling (C64) (thanks to Stefan Haubenthal)
- improved code generation for larger types
- added config for re-runnable programs (C64)
- more examples/demos

[qus]

Hi HERE, Volker. Hope you find this at least a bit interesting:

viewtopic.php?f=2&t=5622&p=76787#p76787

[vbc]

I have uploaded a new version: http://www.compilers.de/vbcc.html

Major changes since last update:

- first version of an Atari 8bit target (Atari)
- configuration for running banked code with REU (C64)
- configuration for TxROM mapper (NES)
- some speed and size optimizations of the C library (thanks to Frank Wille) => up to 234 dhrystones/s on C64
- chars are unsigned by default for slightly better code
- return values of banked function calls work now
- setjmp/longjmp added
- new option -depobj to fix problems with -deps
- zpage now supports multiple arguments (vasm)
- some support for mixing source and assembly with -g
- a few bug fixes
- updated/improved documentation

[arrow201]

Very cool. Have you tested an interrupt handler written in 'C'? Are there any examples for a step-by-step for a homebrewed board as I tried to do for cc65:
("Setting cc65 IRQ/NMI for homebrew board?": viewtopic.php?f=2&t=6200)

What is the interrupt call overhead like? The cc65 set_irq() appears to be a bit heavy:
"The stub saves the registers and zero page locations used by the C runtime and switches to the provided stack area. As a consequence, there is some runtime overhead, but it it is safe to execute C code"(https://www.cc65.org/doc/funcref-179.html)

Thanks !

[vbc]

arrow201 wrote:

Very cool. Have you tested an interrupt handler written in 'C'?

I have looked at the generated code, but I have not really tested it on 6502 yet.

Quote:

Are there any examples for a step-by-step for a homebrewed board as I tried to do for cc65:
("Setting cc65 IRQ/NMI for homebrew board?": viewtopic.php?f=2&t=6200)

If everything works as intended, you write your function using the __interrupt attribute and put its address into the interrupt vector.

Quote:

What is the interrupt call overhead like? The cc65 set_irq() appears to be a bit heavy:
"The stub saves the registers and zero page locations used by the C runtime and switches to the provided stack area. As a consequence, there is some runtime overhead, but it it is safe to execute C code"(https://www.cc65.org/doc/funcref-179.html)

The overhead might be a bit less, because the saving/restoring is done directly in the function body rather than by some library functions. Therefore vbcc does not have to save zero page registers that are not modified in the interrupt handler. The more complicated the handler gets, the more has to be saved. But in the end, everything that is used has to be restored.

For this simple handler:

Code: Select all

char cnt;

__interrupt void f()
{
 cnt++;
}

vbcc currently generates this code:

Code: Select all

_f:
        pha
        txa
        pha
        tya
        pha
        lda     sp
        pha
        lda     sp+1
        pha
        lda     #<(___isrstack-0)
        sta     sp
        lda     #>(___isrstack-0)
        sta     sp+1
        inc     _cnt
        pla
        sta     sp+1
        pla
        sta     sp
        pla
        tay
        pla
        tax
        pla
        rti

Actually, vbcc should be able to remove the stack switch in this case, because the software stack is not used. I should add this some time.

[vbc]

I have uploaded a new version: http://www.compilers.de/vbcc.html

Major changes since last update:

- first version of a BBC Micro/Master target
- support for 65C02
- C99 mode is now the default, -c89 selects C89
- several bug fixes
- small code improvements
- updated/improved documentation

[vbc]

I have uploaded a new version: http://www.compilers.de/vbcc.html

Major changes since last update:

- new target: MEGA65 (native mode, some banking support)
- new target: Commander X16 (thanks András Péteri)
- new options -prefer-statics/-force-statics (allocate local variables in static memory rather than on the stack)
- new option -range-opt (first implementation of some range-based optimizations changing induction variables to smaller types)
- added support for o65 object file format
- added support for Oric target format
- better use of x register
- improved cross-module function-inlining
- IEEE math library works with 65c02
- several code generation improvements
- fixed several bugs
- slightly reworked examples

[vbc]

I have uploaded version 3 of the vbcc distribution for 6502 targets at http://www.compilers.de/vbcc.html

Major changes since last update:

• - several bug fixes
  - improved code generation
  - linker mask optimizations to reduce overhead of some library functions (still much room for improvement)
  - improved attribute checks for banking
  - C64 new features:
  • - stdio functions allow file access on 1541 compatible drives
  - MEGA65 new features:
  • - free license for commercial usage
    - code generator uses 32bit extensions
    - code generator uses HW multiplier
    - full automated banking support
    - ROM-less library enabling full use of the entire RAM
    - stdio functions allow reading of files on SD card
  - BBC new features:
  • - stdio functions allow file access
    - full automated banking support for systems with sideways RAM
    - support for command line arguments
    - configuration for clean return after exit
  - CBM PET new features:
  • - added as new target

We are happy to announce that the Museum of Electronic Games & Art e.V. (http://www.m-e-g-a.org) has decided to sponsor the MEGA65 version of vbcc.
This does not only help us to continue supporting and improving this port but it also allows us to relax the terms of use for the MEGA65 community.
Everyone may now freely use vbcc to develop MEGA65 code for commercial as well as non-commercial usage (for details please refer to the license in the documentation).

We thank MEGA e.V. for the confidence in vbcc and hope that this step will help in the creation of new software for the MEGA65.

[BigEd]

Excellent news on sponsorship! Well done!

[vbc]

I have uploaded version r3p2 of the vbcc distribution for 6502 targets at http://www.compilers.de/vbcc.html

Major changes since last update:

• initial support for new target Oric Atmos

[BigDumbDinosaur]

!!!BUMP!!!

Whatever happened with this project?

[vbc]

BigDumbDinosaur wrote:

Whatever happened with this project?

What do you mean? It is still one of the best 6502 compilers.

Are you missing anything specific?