vbcc optimizing C compiler now with Oric Atmos support
Re: vbcc optimizing C compiler now with Oric Atmos support
Attached are results with different optimization options ( -O={1023,991,-1} ).
smaller size: 991 < 1023 < -1
faster code: 1023 < -1 < 991
I'll continue with 991 until the 2-pass (size/speed) bench is ready for all compilers.
This was fun exercise.
smaller size: 991 < 1023 < -1
faster code: 1023 < -1 < 991
I'll continue with 991 until the 2-pass (size/speed) bench is ready for all compilers.
This was fun exercise.
- Attachments
-
- results-opt.zip
- (9.1 KiB) Downloaded 47 times
Re: vbcc optimizing C compiler now with Oric Atmos support
Thanks for the update. I had a look at some of the more surprising results and there still are a lot of questions, e.g.:
- Why do almost all compilers have a failed-to-run for the frogtest? You already posted working versions from all compilers in the other thread.
- How did you get those extremely fast results for sdcc in the sort-tests? At first, I thought it might be due to the small array with hardcoded numbers. Using something like very aggressive inlining and unrolling, a compiler could perhaps perform the sort basically at compile-time. However, I compiled merge-sort with sdcc, and it does not seem to do anything special. Checking the generated code, I do not see how the results could be so much better than of all of the other compilers. Unless I am missing something, are you sure your measurements are correct?
- I was oviously stunned by the lcc-results for the pi test being so much better than those of vbcc (completely contrary to all other tests). First thing I recognized is that the test uses long for all variables. lcc apparently uses 16bit longs which is not C compliant, making the test not really comparable. But even then I would expect that to give between a two- and four-time advantage to lcc (probably somewhat offset by its worse code generation) rather than a factor of >50 like in your tests. How did you measure those?
- There is also use of long in mandelbrot.c (and - strangely - in this case an extremely bad score for lcc). You should use int16_t or int32_t with correct adaptations for each compiler for pi and mandelbrot.
Re: vbcc optimizing C compiler now with Oric Atmos support
The 'frogmove' is real working app for Oric and runs forever, so all test must be indicated as 'fail-to-run' (here sdcc really fails but I didn't check why). Actually the idea for this test was to twit how it looks visually (sdcc not included in picture):
I had other plans for the weekend but ok, you convinced me, I'll try to make it good enough to be present at public
(I'm just trying to avoid writing long texts because it's so time-consuming task).
EDIT: sdcc result in sorting are fake.
Re: vbcc optimizing C compiler now with Oric Atmos support
Ok, I see. That's a bit misleading in the table.
Yes, it is a nice visual benchmark.Actually the idea for this test was to twit how it looks visually (sdcc not included in picture):
No hurries, I don't want to ruin your weekend.I had other plans for the weekend but ok, you convinced me, I'll try to make it good enough to be present at public
Ok.EDIT: sdcc result in sorting are fake.
Re: vbcc optimizing C compiler now with Oric Atmos support
I've been playing a bit with vbcc, the main thing is that despite being very exhaustive, I think the documentation is missing some stupidly simple examples of command line to use to get quickly started.
So from what I saw, after doing:
I was then able to assemble a small test program
When called with
I get a test.asm source code:
which indeed is pretty much the conversion of the C code, with the added optimisation of reusing the 'c' instead of reloading it, which is nice.
If I compile with
I get a 266 bytes long program which does not exit, because it ends with a JMP on itself, is it something that can be disabled?
Regarding the default output names, when exporting an object file, we get "name.out", when using -S we get "name.asm", would it be possible to have "name.tap" instead of "name.out" when generating an actual tape file?
So from what I saw, after doing:
Code: Select all
SET VBCC=D:\vbcc\vbcc6502_r3p3\vbcc6502\vbcc6502_win\vbcc
SET PATH=D:\vbcc\vbcc6502_r3p3\vbcc6502\vbcc6502_win\vbcc\bin;%PATH%
Code: Select all
int main()
{
char* scr=(char*)0xbb80;
scr[0]='v';
scr[1]='b';
scr[2]='c';
scr[3]='c';
}
Code: Select all
vc +atmos -O4 -S test.c
Code: Select all
;vcprmin=10000
section text
global _main
_main:
lda #118
sta 48000
lda #98
sta 48001
lda #99
sta 48002
sta 48003
ldx #0
txa
rts
; stacksize=0+??
zpage sp
zpage r0
zpage r1
zpage r2
zpage r3
zpage r4
zpage r5
zpage r6
zpage r7
zpage r8
zpage r9
zpage r10
zpage r11
zpage r12
zpage r13
zpage r14
zpage r15
zpage r16
zpage r17
zpage r18
zpage r19
zpage r20
zpage r21
zpage r22
zpage r23
zpage r24
zpage r25
zpage r26
zpage r27
zpage r28
zpage r29
zpage r30
zpage r31
zpage btmp0
zpage btmp1
zpage btmp2
zpage btmp3
If I compile with
Code: Select all
vc +atmos -O4 test.c -o test.tap
Regarding the default output names, when exporting an object file, we get "name.out", when using -S we get "name.asm", would it be possible to have "name.tap" instead of "name.out" when generating an actual tape file?
Re: vbcc optimizing C compiler now with Oric Atmos support
What are you missing? The README mentions simple examples:
Code: Select all
Compiling works pretty much like most compilers, e.g.:
vc file.c -o binary
When using floating point, link with the math library:
vc file.c -lm -o binary
For IEEE floating point, link with -lmieee and use -ieee:
vc file.c -ieee -lmieee -o binary
Choose a different target confguration with +<cfg>:
vc +c64 file.c -o file.c64
vc +nes file.c -o file.nes
vc +atari file.c -o file.com
vc +bbc file.c -o file
vc +m65 file.c -o file
vc +atmos file.c -o file.tap
vc +x16 file.c -o file
You can either use +atmosr which will create a file with BASIC header that returns to BASIC and can be started multiple times. Also, libsrc/6502-atmos contains the source code for the startup-code (startup.s) which contains the loop. You could change that and copy a modified startup.o into targets/6502-atmos/lib.If I compile withI get a 266 bytes long program which does not exit, because it ends with a JMP on itself, is it something that can be disabled?Code: Select all
vc +atmos -O4 test.c -o test.tap
This is the area where I am not familiar enough with the Oric to know what kind of configs are most useful. For example, is there any benefit for a program to return to BASIC (which AFAIK might require to save/restore a number of memory locations) if it can not be reliably run a second time anyway (due to data section not preserved)?
Actually, you will always get "a.out" when not specifying an output file. This is the convention used by many compilers like gcc. I also prefer it like that. For asm or object files you usually create one output for every input file (at least when ignoring cross-module optimizations). Therefore, there is a natural name for those files. In the linking stage you will usually have many input files and there is not an obvious output name. You could use the first input file, but it is not uncommon to do something like "vc *.c" (especially with foreign code). IMHO it helps here to have a fixed name rather than having to search what the output is called this time.Regarding the default output names, when exporting an object file, we get "name.out", when using -S we get "name.asm", would it be possible to have "name.tap" instead of "name.out" when generating an actual tape file?
I agree that in your special case with a single input file it might be make sense. But I think in a real project you will want to explicitly specify an output name in the linking stage anyway. Therefore I want to stay with widespread convention here.
Re: vbcc optimizing C compiler now with Oric Atmos support
Ok, did not think of looking at the readme, I was only looking at the pdf file.What are you missing? The README mentions simple examples:
Regarding the configurations, what is the default config used if you don't specify a +<cfg>?
So regarding atmos config specifically:
I personally find the differences between +atmos, +atmosb and +atmosr very confusing, and imo, you should not care about BASIC at all or looping: If the user wants their program to not leave, it's their problems, not the compiler or linker.- add re-entrant option +atmosr for Oric/Atmos
- add raw-binary option +atmosb for Oric/Atmos
- updated vlink (use uppercase names for oricmc)
- new target Oric/Atmos
- updated vlink (needed for Oric tape files)
- added support for Oric target format
Typically if you load a program, if it does not modify any of the system variables, it will most probably be able to come back to the BASIC prompt (or any program that called it) without anything failing.
Another important factor is that many people disable the system: Typically games like Blake's 7 or demos like Pushing The Enveloppe don't use the ROM at all, so they can use whatever they want in zero page or page 2, so don't assume anything about the calling system.
Typically the startup code is doing things which it should not be doing, like caring about caps lock
Code: Select all
; disable caps lock
lda #127
sta $20c
Code: Select all
; set user stack
lda #<MEMEND
sta sp
lda #>MEMEND
sta sp+1
How is that implemented?- add argc/argv support for Oric/Atmos
From what I see, that seems to use some trickery using a REM after the LOAD command, and parsing the BASIC buffer?
Re: vbcc optimizing C compiler now with Oric Atmos support
MOS6502 updated. I've put the info in new topic, so this one to be for vbcc related discussions only.
As I said before - I like vbcc ...
As I said before - I like vbcc ...
Re: vbcc optimizing C compiler now with Oric Atmos support
It looks for vc.config or vc.cfg (on Windows).
The standard startup code should set up a C environment that allows to run (within its restrictions of course) standard portable C programs without having to adapt them specifically to Oric. If someone is writing specific Oric-code, it is of course possible to modify the startup code or to use -nostdlib and provide your own startup-code and/or libraries.Typically the startup code is doing things which it should not be doing, like caring about caps lockI also think that things like erasing the BSS or copying the zero page should be optional.Code: Select all
; disable caps lock lda #127 sta $20c
In the linker file targets/6502-atmos/vlink.cmd.Where is MEMEND defined?
Yes. There are examples in vbcc.pdf in "C Library=>6502/Atmos=>Startup and Memory=>Command Line". I just took the code that was originally written for cc65. You can have a look at it in libsrc/6502-atmos/mainargs.sHow is that implemented?- add argc/argv support for Oric/Atmos
From what I see, that seems to use some trickery using a REM after the LOAD command, and parsing the BASIC buffer?
Re: vbcc optimizing C compiler now with Oric Atmos support
@vbc: No dig deal, but what about warning free compilation
Code: Select all
vbcc/frontend/vc.c:600: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
Re: vbcc optimizing C compiler now with Oric Atmos support
Unfortunately there is no way to avoid warnings on all compilers. The hint is also not that helpful here, considering that it suggests replacing a standard C library function with a POSIX-only function that does something different...iss wrote: ↑Tue Feb 14, 2023 1:21 am @vbc: No dig deal, but what about warning free compilationCode: Select all
vbcc/frontend/vc.c:600: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
Re: vbcc optimizing C compiler now with Oric Atmos support
I had to clean up my messy build so now thanks to a cute new Rakefile I can switch from compilers and targets in no time...
Switching to vbcc went smooth :
- vbcc spotted few typos,
- some warnings (but legitimate ones, unsigned char bitfields)
- I had to borrow an itoa(), not a big deal
- and I need to cleanup some profiling macros that vbcc don't like (didn't checked, not important for now)
There's only one thing that I'll miss : binary litterals (YES they're not part of C99 std but I LIKE THEM !)
Without doing anything the code size is bigger with vbcc (9.5k -> 15k, might be caused by libc calls) but I did not used any optimization on both compilers. Time to RTFM
I'm absolutely happy to finally have a working vbcc ! That open my mind on cross compiling for non-6502 targets, just to see what's doable
Another hole into the rabbit hole
Switching to vbcc went smooth :
- vbcc spotted few typos,
- some warnings (but legitimate ones, unsigned char bitfields)
- I had to borrow an itoa(), not a big deal
- and I need to cleanup some profiling macros that vbcc don't like (didn't checked, not important for now)
There's only one thing that I'll miss : binary litterals (YES they're not part of C99 std but I LIKE THEM !)
Without doing anything the code size is bigger with vbcc (9.5k -> 15k, might be caused by libc calls) but I did not used any optimization on both compilers. Time to RTFM
I'm absolutely happy to finally have a working vbcc ! That open my mind on cross compiling for non-6502 targets, just to see what's doable
Another hole into the rabbit hole
Re: vbcc optimizing C compiler now with Oric Atmos support
Curiously I had never seen them being used, but I happened to read about people using them just yesterday on another forum as well. So I had a look at vbcc and it turns out they were extremely simple to add. Therefore they will be supported in the next release (although I cannot say when that will be). If there is interest in trying it out, I can upload a source snapshot for testing.
Re: vbcc optimizing C compiler now with Oric Atmos support
It's really a matter of taste, but I find
Code: Select all
#define NOT_WALKABLE 0b01010010
Code: Select all
#define NOT_WALKABLE 0x52
When you'll have a snapshot to check, I'll happy do !
Re: vbcc optimizing C compiler now with Oric Atmos support
The main reason for people not using boolean literals, is that many of the old compilers for old architectures have never been updated to use them, and we rarely need to use bit masking on modern projects.
But yeah, when doing assembler, I use binary over hexadecimal decimal when doing things like masking bits or storing bitmap graphics in a recognizable way.
But yeah, when doing assembler, I use binary over hexadecimal decimal when doing things like masking bits or storing bitmap graphics in a recognizable way.