vbcc optimizing C compiler for 6502 now supports bbc

[vbc]

Hello,

I have uploaded a new version of my C compiler for 6502 with experimental support for BBC Micro/Master computers to: http://www.compilers.de/vbcc.html

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 banked memory and far-pointers
- (limited) floating point support based on Steve Wozniaks code
- (pretty good) 32/64bit IEEE floating point support based on SANE
- support for 65C02 extensions
- support for writing interrupt handlers
- attributes for putting variables into zero page
- supports stack-frames > 256 bytes

On the bad side, the C library is currently only partially optimized for the 6502 and may be too big for some applications. Not all functionality is supported at the moment. Especially file I/O is missing (stdin/stdout to keyboard/screen is supported).

I have never used a BBC Micro and the port is based on a bit of information I got from the internet. So, there are probably some things I did completely wrong. Feel free to tell me how to do it right.

So far I could only test with an emulator and do not know what works on real hardware. The samples directory contains a few examples (dhrystone benchmark and calculator) compiled for the BBC Micro. I would be interested to hear if they work on real hardware.

[Bobbi]

Amazing work! Writing a C compiler is no small task.

How does your compiler compare to cc65? Not so much in terms of BBC Micro support, more the core compiler. How does code size and performance compare for example? I use cc65 a fair bit, but I could be 'in the market for' something better

[vbc]

Amazing work! Writing a C compiler is no small task.

How does your compiler compare to cc65? Not so much in terms of BBC Micro support, more the core compiler. How does code size and performance compare for example? I use cc65 a fair bit, but I could be 'in the market for' something better

Regarding features, my initial post lists probably the most important ones.

Speed of the generated code can be several times faster than cc65, depending on opportunities for optimizations. The dhrystones benchmark which is included in the samples directory of my distribution gets ~234 dhrystones/s on a C64 compared to ~75 compiled with cc65 -Oisr. Other people have reported similar improvements, e.g. in those threads:

http://forums.nesdev.com/viewtopic.php? ... 26#p251672
http://forums.nesdev.com/viewtopic.php? ... 20#p254354
http://forums.nesdev.com/viewtopic.php? ... 20#p254433
https://www.lemon64.com/forum/viewtopic ... 3&start=17

Code size is more of a mixed bag. The library of vbcc is only partially optimized for 6502 yet, so programs using large library functions will have some overhead compared to cc65. The actual generated code can be smaller or larger. vbcc comes with a (still somewhat experimental) code compressor that can save quite some space. On the other hand, when optimizing for speed, the code can get bigger. The links above also have some code size comparisons, but I have not yet done a more thorough comparison yet.

[cmorley]

Do you have the instructions to integrate it into a local copy of compiler explorer properly?

I managed to get it to run in CE but only by using bin/vbcc6502 not the driver bin/vc. With bin/vc I got a "no config file" error .

[dominicbeesley]

Good work. I'm looking forward to trying this! The optimizations look promising

[Bobbi]

Yes I am looking forward to trying this out as well.

I have been secretly hoping for a better 6502 C compiler (secretly, because I was too lazy, and not smart enough, to do the hard work myself.)

[vbc]

Do you have the instructions to integrate it into a local copy of compiler explorer properly?

I managed to get it to run in CE but only by using bin/vbcc6502 not the driver bin/vc. With bin/vc I got a "no config file" error .

I am not familiar with compiler explorer, but vc expects its config file in $VBCC/config. Maybe you did not set this environment variable?

[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

[tricky]

https://godbolt.org/z/JN4AOA compiler explorer, supports many other compilers (x86 etc), but I think that this is cc65, it's a bit hard to tell on the phone!
Same genius who wrote jsbeeb

[Fabrizio]

@vbc
Thanks for supporting the BBC!
Unfortunately I have not manage to figure out how to install and use your cross-compiler.
I have tried the snapshot of 19/03/2021. Is it the latest version? I also see "Second beta of release 2 of vbcc for 6502" with no date.

Could you provide a simple example on how to compile a bbc program or a program for a given target?

Under my Posix environment (Cygwin/Windows) I have followed the instructions in your manual but I must have missed some important point because it does not find the config stdio.h nor the targets and not even the default target (ataricom?).

In my .bash_profile I have
export VBCC=/cygdrive/c/Retro/vbcc_win_x64/vbcc
export PATH="$PATH:/opt/cross-mint/bin:/opt/amiga/bin:/cygdrive/c/Users/fabri/AppData/Local/Programs/FS-UAE/Launcher/Windows/x86-64:/opt/gcc4ti/bin:/cygdrive/c/Retro/vbcc_win_x64/vbcc/bin"

I do not see where I have to edit the vc.cfg file. I have tried to copy one and rename it vc.cfg.

If I try to compile a trivial hello world I get:
$ /cygdrive/c/Retro/vbcc_win_x64/vbcc/bin_win/vc -v ./hello_world.c
vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann
vbcc6502 -I%VBCC%/targets/6502-atari/include -quiet -atascii -mainargs ".\hello_world.c" -o= "
C:\cygwin\tmp\vbcc068c.asm" -unsigned-char -O=1
>#include <stdio.h>
error 248 in line 1 of ".\hello_world.c": file 'stdio.h' not found
1 error found!
vbcc6502 -I%VBCC%/targets/6502-atari/include -quiet -atascii -mainargs ".\hello_world.c" -o= "
C:\cygwin\tmp\vbcc068c.asm" -unsigned-char -O=1 failed
(I am giving the full path to vc because there may be a conflict)

If I try to compile an empty program (that just returns 0 without any include) I get:
$ /cygdrive/c/Retro/vbcc_win_x64/vbcc/bin_win/vc -v ./hello_world.c
vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann
vbcc6502 -I%VBCC%/targets/6502-atari/include -quiet -atascii -mainargs ".\hello_world.c" -o= "
C:\cygwin\tmp\vbcc068c.asm" -unsigned-char -O=1
vasm6502_oldstyle -quiet -nowarn=62 -opt-branch -Fvobj "C:\cygwin\tmp\vbcc068c.asm" -o "C:\cygw
in\tmp\vbcc068c.o"
vlink -b ataricom -Cvbcc -T%VBCC%/targets/6502-atari/vlink.cmd -L%VBCC%/targets/6502-atari/lib
%VBCC%/targets/6502-atari/lib/startup.o "C:\cygwin\tmp\vbcc068c.o" -o a.out -lvc
Fatal error 9: Invalid target format "ataricom".
Aborting.
vlink -b ataricom -Cvbcc -T%VBCC%/targets/6502-atari/vlink.cmd -L%VBCC%/targets/6502-atari/lib
%VBCC%/targets/6502-atari/lib/startup.o "C:\cygwin\tmp\vbcc068c.o" -o a.out -lvc failed

What am I doing wrong?

[vbc]

@vbc
Thanks for supporting the BBC!
Unfortunately I have not manage to figure out how to install and use your cross-compiler.
I have tried the snapshot of 19/03/2021. Is it the latest version? I also see "Second beta of release 2 of vbcc for 6502" with no date.

The snapshot is a little more recent but less tested than the 6502-specific release. Also, the 6502 release contains several demos whereas the snapshot contains the tools for many non-6502 targets. Both should work but it is probably better not to intermix them.

Could you provide a simple example on how to compile a bbc program or a program for a given target?

If the installation is correct, it should be a simple matter of:

Code: Select all

vc +bbc hello.c -o hello

Under my Posix environment (Cygwin/Windows) I have followed the instructions in your manual but I must have missed some important point because it does not find the config stdio.h nor the targets and not even the default target (ataricom?).

In my .bash_profile I have
export VBCC=/cygdrive/c/Retro/vbcc_win_x64/vbcc
export PATH="$PATH:/opt/cross-mint/bin:/opt/amiga/bin:/cygdrive/c/Users/fabri/AppData/Local/Programs/FS-UAE/Launcher/Windows/x86-64:/opt/gcc4ti/bin:/cygdrive/c/Retro/vbcc_win_x64/vbcc/bin"

I do not see where I have to edit the vc.cfg file. I have tried to copy one and rename it vc.cfg.

If I try to compile a trivial hello world I get:
$ /cygdrive/c/Retro/vbcc_win_x64/vbcc/bin_win/vc -v ./hello_world.c
vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann
vbcc6502 -I%VBCC%/targets/6502-atari/include -quiet -atascii -mainargs ".\hello_world.c" -o= "
C:\cygwin\tmp\vbcc068c.asm" -unsigned-char -O=1
>#include <stdio.h>
error 248 in line 1 of ".\hello_world.c": file 'stdio.h' not found
1 error found!
vbcc6502 -I%VBCC%/targets/6502-atari/include -quiet -atascii -mainargs ".\hello_world.c" -o= "
C:\cygwin\tmp\vbcc068c.asm" -unsigned-char -O=1 failed

The configuration files for Windows are intended for use with the Windows command prompt. When using bash I presume that %VBCC% will not be correctly replaced but $VBCC is needed. You could try to use the config-files from the linux distribution of vbcc. Maybe they will work with cygwin.

vlink -b ataricom -Cvbcc -T%VBCC%/targets/6502-atari/vlink.cmd -L%VBCC%/targets/6502-atari/lib
%VBCC%/targets/6502-atari/lib/startup.o "C:\cygwin\tmp\vbcc068c.o" -o a.out -lvc
Fatal error 9: Invalid target format "ataricom".
Aborting.
vlink -b ataricom -Cvbcc -T%VBCC%/targets/6502-atari/vlink.cmd -L%VBCC%/targets/6502-atari/lib
%VBCC%/targets/6502-atari/lib/startup.o "C:\cygwin\tmp\vbcc068c.o" -o a.out -lvc failed

Maybe this is also related to replacement of the environment variables. Or do you have another vlink somewhere in your path?

[Fabrizio]

I am also using:
https://github.com/bebbo/amiga-gcc
which has some conflicting names as it also uses a forked vbcc.

[Fabrizio]

What do you mean by "using the config files from Linux"?
How do I use a config file?
vcc +<path to config file> foo.c
?

Could you provide a simple example how to use config files?

[Fabrizio]

It seems I have managed to make it work under the Windows subsystem for Linux.

My main dev environment for Cross-Lib is Cygwin because I can call compilers from it.
I will probably have to get rid of the other vbcc and see if your latest code can build my games for the Amiga OS.

[Fabrizio]

vc +bbc foo.c
creates a.out
What format is this?
Is it a raw binary that has to be somehow injected into ram?
Is it a binary with a header for a special emulator?

How is it loaded into an emulator?

[vbc]

I am also using:
https://github.com/bebbo/amiga-gcc
which has some conflicting names as it also uses a forked vbcc.

You may have to be careful not to mix them. Probably this contains an older vlink which does not support all 6502 targets.

What do you mean by "using the config files from Linux"?

You can download the vbcc snapshot for a Linux host from http://www.compilers.de/vbcc. It contains config files (in vbcc/config) suitable for Linux, i.e. using $VBCC instead of %VBCC% and / instead of \. For cygwin, it might work to overwrite the Windows config files with those.

How do I use a config file?
vcc +<path to config file> foo.c
?

Usually, the config files are placed in $VBCC/config (or %VBCC%/config). You should be able to choose the desired configuration just using +<name>. The path is usually not needed. If it does not work in your configuration, this is probably because you did not set the VBCC Windows environment variable but only the bash variable. vc.exe for Windows obtains the vbcc path by querying the environment variable VBCC using getenv(). In your case with cygwin/bash on Windows you may have to set the VBCC variable for Windows as well as in bash.

vc +bbc foo.c
creates a.out
What format is this?
Is it a raw binary that has to be somehow injected into ram?
Is it a binary with a header for a special emulator?

How is it loaded into an emulator?

vbcc creates a raw binary together with an .inf file (in your case a.out.inf). You can e.g. create a disc image using bbcim and mount this in an emulator. Some emulators also allow to mount a host filesystem directly. Some of the experienced BBC users probably can offer more insight into this topic than I can.

[lurkio]

---

[Fabrizio]

Speed of the generated code can be several times faster than cc65, depending on opportunities for optimizations. The dhrystones benchmark which is included in the samples directory of my distribution gets ~234 dhrystones/s on a C64 compared to ~75 compiled with cc65 -Oisr. Other people have reported similar improvements, e.g. in those threads:

I am testing vbcc vs cc65 for the c64 target on a simple purely computational task, i.e., the sieve:
https://github.com/Fabrizio-Caruso/Sieve

I build my tests with
make cc65_c64_sieve
make vbcc_c64_sieve

I am comparing the plain sieve.c version (no special optimization with page-zero for the CC65).
I am using -O -Cl --codesize 800 which the most useful and general optimization and produces generally better code than -Oisr (as long as no recursion is used). For vbcc I am using -O3 and -O4.

Current CC65: 2.000 secs - Size: 24099 bytes
Current VBCC: 2.220 secs - Size: 29253 bytes

So on this task VBCC is about 11% slower and produces a significantly bigger binary.

If I remove --codesize 800 and leave just -O -Cl, CC65 takes about 2.100 secs (very close to VBCC but still with a smaller binary: 24114 bytes)

No library is used.

I will run some other tests on purely computational tasks with no libs.

[Fabrizio]

I have made one more purely computational self-contained test between the latest CC65 vs VBCC.

I test the two cross-compilers with the computation primitive Pythagorean triples:
https://github.com/Fabrizio-Caruso/Prim ... an-Triples

I use CC65 with -Or -Cl --codesize 800 and VBCC with -O4.
I am not using zeropage optimization for CC65, which would make it even faster and smaller in size.

I build with:
make cc65_c64_triples
make vbcc_c64_triples

Here VBCC is doing something really inefficient with the code size:
CC65: 0.400 secs - Size: 4850 bytes
VNCC: 0.400 secs - Size: 10685 bytes

VBCC produces a huge binary for a very simple and short program.

On this example they have comparable speeds.

If I remove --codesize 800, CC65 takes 0.450 secs and the size is surprisingly slightly smaller: 4822 bytes. So, with just -Or -Cl, CC65 is 10% slower than VBCC.

[ChrisJC]

I see all of the examples have printf() in them.

Have you got any idea how big the printf() library is?, and whether that is dominating the output image?

Chris.

[vbc]

Speed of the generated code can be several times faster than cc65, depending on opportunities for optimizations. The dhrystones benchmark which is included in the samples directory of my distribution gets ~234 dhrystones/s on a C64 compared to ~75 compiled with cc65 -Oisr. Other people have reported similar improvements, e.g. in those threads:

I am testing vbcc vs cc65 for the c64 target on a simple purely computational task, i.e., the sieve:
https://github.com/Fabrizio-Caruso/Sieve

This is an extremely small and simple test, so no big differences can be expected. Also loop variables are defined as global variables to even prevent most of register allocation.

I am comparing the plain sieve.c version (no special optimization with page-zero for the CC65).
I am using -O -Cl --codesize 800 which the most useful and general optimization and produces generally better code than -Oisr (as long as no recursion is used). For vbcc I am using -O3 and -O4.

Current CC65: 2.000 secs - Size: 24099 bytes
Current VBCC: 2.220 secs - Size: 29253 bytes

I tried to reproduce those results and while I get the same timings printed, the tick values and the actual run-time do not seem to match. I get 110 ticks for vbcc and 120 for cc65. When using a stop-watch and emulator set to 20% speed, this seems to be reflected by the actual run-time. Probably the CLOCKS_PER_SEC is 50Hz vs 60Hz in the two compilers.

So on this task VBCC is about 11% slower and produces a significantly bigger binary.

According to my results vbcc is about 10% faster using your files and your options. This can probably improved a bit by using local rather than global variables as loop indices. Also note that -Cl is a non-C-compliant option. The vbcc-equivalent would be -force-statics (although it is probably not important for this test case as it does not use local variables).

Code size is indeed a bit hit and miss with vbcc at the moment. First, the C library is not optimized for the 6502. It is almost entirely C code written with larger systems in mind. Until there is a 6502-optimized library for vbcc, you should try to avoid at least the stdio functions if code size is an issue.

For the actual code, -O often gives better code size than higher optimization levels. You can also try "-O4 -inline-size=0 -unroll-size=0". If you are brave you can try "-O4 -size" which will also activate the experimental code-compressor. This can, however, reduce execution speed quite a bit and has not been tested too much so far.

No library is used.

I will run some other tests on purely computational tasks with no libs.

You are using the standard C library with full printf. The actual code generated for the three source files using the above options is less than 1K.

[Fabrizio]

Yes, I am using printf only to display the results but I am not timing printf.
I am only timing the "math".

Speed-wise they are similar in these cases.
CC65 is quite slow without -Cl because of the software stack (which is present in any C compiler for MOS6502).
It is probable irrelevant in these tests.

[Fabrizio]

@lurkio, what happened to your post?

[vbc]

I have made one more purely computational self-contained test between the latest CC65 vs VBCC.

I test the two cross-compilers with the computation primitive Pythagorean triples:
https://github.com/Fabrizio-Caruso/Prim ... an-Triples

I use CC65 with -Or -Cl --codesize 800 and VBCC with -O4.
I am not using zeropage optimization for CC65, which would make it even faster and smaller in size.

I build with:
make cc65_c64_triples
make vbcc_c64_triples

Here VBCC is doing something really inefficient with the code size:
CC65: 0.400 secs - Size: 4850 bytes
VNCC: 0.400 secs - Size: 10685 bytes

Again, pretty eccentric code that splits up expressions into single operations using global variables as temporaries.

However, in this case I can only reproduce your vbcc result. I get 20 ticks for vbcc but I get much slower 33 ticks for cc65.

VBCC produces a huge binary for a very simple and short program.

The actual code is <3K using -O4, <1.7K using -O, <1.6K using "-O4 -unroll-size=0 -inline-size=0", and <1.4K using "-O4 -size". The rest is library code.

On this example they have comparable speeds.

Strangely, on my test cc65 was >50% slower using your make commands. My cc65 is probably not up-to-date (2.18), but I was not aware of any significant code generation changes.

[Fabrizio]

CC65 has got some significant improvements in the last months from what I can see from the commits and pull requests in the last year.

[vbc]

CC65 has got some significant improvements in the last months from what I can see from the commits and pull requests in the last year.

Out of curiosity I built a current cc65 snapshot and it is indeed better than the older version. I can reproduce the results with 24 ticks. So this version is only 20% slower than vbcc in this test.

[Fabrizio]

I have compiled a hello world test with vc +bbc hello.c -o hello
#include <stdio.h>
int main(void) {
printf("Hello world!");
while(1){};
return 0;
}
I have managed to insert the hello and hello.inf files into a .ssd disk image hello.ssd
I can mount the disk image on an emulator (B-em 2.2) and see its content with *CAT but I am not able to load it and run it.

I can see the content of the disk with *CAT
and I can see that the binary is set to $FF1900 (is this correct?)

I have tried:
*RUN"HELLO" -> frozen with flashing cursor

*LOAD"HELLO"
CALL&1900 -> frozen with flashing cursor

The model in B-em 2.2 is BBC B w/8271 FDC

What am doing wrong?

[vbc]

I have compiled a hello world test with vc +bbc hello.c -o hello
#include <stdio.h>
int main(void) {
printf("Hello world!");
while(1){};
return 0;
}
I have managed to insert the hello and hello.inf files into a .ssd disk image hello.ssd
I can mount the disk image on an emulator (B-em 2.2) and see its content with *CAT but I am not able to load it and run it.

I can see the content of the disk with *CAT
and I can see that the binary is set to $FF1900 (is this correct?)

I have tried:
*RUN"HELLO" -> frozen with flashing cursor

stdout is line-buffered by default. Try adding fflush(stdout); after the printf or add '\n' to the printf-string.

[Fabrizio]

THANKS! It works!
Great!
I will probably be able to include vbcc into Cross-Lib.
This will allow me to "automatically" port all the games written with Cross-Lib to the targets provided by vbcc including the BBC Micro and BBC Master.

Fabrizio

[sweh]

Out of curiosity I did a quick "hello world" test to see how it works.

What I found a little odd is that you're using zero page addresses, but using long address mode
eg

Code: Select all

1904 A9 00    LDA #0
1906 8D 20 00 STA &0020

Instead of "8D 20 00" the sequence "85 20" would save a byte and be quicker.

Also, is the code meant to return back to BASIC, or is it designed to hang after running?