[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] [Atari-coldfire] VBCC issues
Hi,
On torstai 15 marraskuu 2012, Miro Kropáček wrote:
> Happily, passing doubles or long longs is very rare in Atari
>
> > code. And until the 16-bit extension bug is fixed, I would
> > suggest VBCC users just to use 32-bit.
>
> So if I understand it correctly, this is a problem only for VBCC's
> "-mshort" + double/long long?
No, the problem with 16-bit version of VBCC is separate from
the scratch register + 64-bit (double/LL) argument problem.
> But as general rule, doubles are used quite a much, take a look
> at any of my ports (quake specially).
I bumbed into that problem only because I'm testing VBCC version
that had libm (among everything else) compiled with the extra scratch
registers. I think with libm in current VBCC release the problem is
a bit harder to hit.
> Btw do I understand it correctly that you plan to have 16 bit gemlib +
> vbcc's libc as the base stack for GEM apps (for developers who, for some
> reason, prefer to use -mshort) ? If so, is there any point except "we
> can" ?
No, I'm not planning on doing 16-bit stuff, I just happened to
test it earlier because there was such a configuration for VBCC. :-)
I see VBCC "niche" somewhere between AHCC and GCC, as VBCC is:
- Modern compiler supporting subset of c99,
unlike the proprietary compilers for Atari
- Can optimize code better than AHCC
- Compiler itself is much smaller and produces smaller
binaries than GCC / MiNTlib [1]
- It supports floating point also on machines that don't
have FPU (ST, STE, Falcon), unlike AHCC
- Works fine on plain TOS, unlike new GCC versions [2]
I want a native Atari compiler that can be easily used under Hatari emulator
(i.e. works on TOS) and which produces code that works fine under ST too
(with floating point). AHCC is otherwise fine, but floating point needing
TT or better sucks badly.
The main downsides of VBCC are that it's:
- missing support for all unistd.h (POSIX) functionality
- not open source like AHCC & GCC, just freeware
- Being multiplatform with several maintainers (who have sources)
reduces risk of abandonment somewhat though
It's good to build SW with different compilers as they reveal
different bugs from it, so I consider there being more compilers
a bonus. :-)
> Anyway, nice initiative, I'm glad you continue to support Frank with
> Atari inputs, I enjoyed cooperation with him very much.
Me too. He's already found ancient Pexec() bug in Hatari GEMDOS HD
emulation and several minor issues with the new features in Hatari debugger;
some NetBSD compiler specific, some generic. Except for the Pexec() bug,
I've already fixed the Hatari issues. :-)
- Eero
[1] the latest version I got from Frank (that's compiled with
itself instead of with GCC + MiNTlib):
$ ls -s --sort=size|cat
total 1704
536 vbcc68ks.ttp
536 vbcc68k.ttp
252 vasmm68k.ttp
196 vlink.ttp
48 vc.ttp
40 vobjdump.ttp
36 vprof.ttp
32 vrm.ttp
28 ar.ttp
[2] While old GCC 2.x versions work on TOS, they're ancient
and not that good (in supporting modern C-standard,
optimization, memory efficiency, being supported etc).