one thing i am missing is a consistent library. there are numerous versions of libgccvb floating around, and everybody seems to have his own modified/updated version.
for example, i have just messed around with the source to dogp’s etch-a-sketch, which includes a customized libgccvb with numerous very useful functions and mnemonics, for example for direct screen draw, which can not be found in any other libgccvb version i have seen.
so, to give everybody the best possible tools and to avoid confusion, why don’t we all try to work towards a consistent library with regular releases, always being kept on the latest point of knowledge?
I’ve taken the time to make libgccvb safe to include in multiple source files by separating declarations of variables and functions from definitions to avoid redefinition errors when including libgccvb in multiple places. A user will need to link in a static libgccvb binary when compiling, but it should work with any version of gccVB. To compile, make sure gccVB is on the path, and then use GNU/MinGW make to compile.
Supplying binaries probably isn’t a good idea unless I can get a single library to play nice with both GCC 2.95 and GCC 4.x (unlikely).
I am not sure whether Nintendo’s compiler comes with a static librarian, but the workaround is to just compile each object file separately :P.
A few minor things have changed compared to what libgccvb was provided with the demos:
itoa is no longer static
asm functions are no longer inline
I have not yet tested this new library, but I will be making modifications as necessary if I run into problems. I would appreciate anyone who could compile this library and tell me about any issues, and whether it’s a suitable drop-in replacement for other libgccvb versions.
If there’s interest, I would also like some feedback on additions, gripes, and potential deletions from my copy of the library hosted on Github. Perhaps it can become a central repository :P.
One deletion I can think of: remove stdarg.h. All ANSI C compilers, hosted or freestanding, are supposed to provide their own, and unless gccVB’s is broken, I do not see the point of keeping a potentially conflicting copy.
Additionally, if __GNUC__ is not defined, the interrupt header shouldn’t be included, since as far as I can gather, those external declarations are embedded into the C runtime provided with gccVB.
Just wondering- has anyone attempted to compile and link against the github-host libgccvb using GCC 2.95 or another version besides GCC 4.4?
I’d like at some point to see the library also be VUCC-compatible (for authenticity :P), but there are a few things that would need to be altered.
In particular, the SOUNDREG and WA structs quite possibly will not work as is. Since compilers tend to add padding to speed memory accesses up, and both the listed structs depend on having no padding whatsoever, I’m a little surprised that they work at all (the sad souls- errr, dedicated hobbyists- who ported GCC did their homework 😉 ).
Additionally, there are a few GCC extensions used in the code, particularly inline, asm- these can be conditionally defined depending on the compiler used. I do not know what extensions to ANSI C that VUCC supports, but I highly doubt it supports all of GCC’s extensions. From what I gather (Googling :D), VUCC was a compiler that Nintendo contracted out to Green Hills. The assembler was from Intelligent Systems. As described below, assembly dependent code may simply not be shareable between GCC and VUCC.
The signature of main() also differs between VUCC (void main) and GCC (int main). Since they’re both freestanding, neither of them are wrong (ANSI says it’s compiler-defined), but perhaps a macro could be defined which uses one signature or the other depending on the detected compiler?
Lastly, can someone tell me WHY the interrupt vectors are defined in the C runtime for gccVB (RunnerPack??! I’m 99% certain that the way interupt vectors are assigned will not work with VUCC. I know GCC doesn’t have a problem with this, but converting fcn pointer to data ptr is undefined in ANSI C (has something to do with Harvard Architecture support or something? Idk.). From the sample demo code, interrupt vectors seem to be defined in a separate asm file for VUCC.
Any thoughts? Since my original post, I’ve learned that a number of people contributed to libgccvb in the past- perhaps new functionality can be added for ease of “jumping into VB.”? Besides the 6 simple demos, of course :P.
cr1901 wrote:
Just wondering- has anyone attempted to compile and link against the github-host libgccvb using GCC 2.95 or another version besides GCC 4.4?
It compiles and links fine with GCC 2.95.2 (or at least it seems to in the simple test I used). However, it complains with “video.c:26: warning: `/*’ within comment”.
In particular, the SOUNDREG and WA structs quite possibly will not work as is. Since compilers tend to add padding to speed memory accesses up, and both the listed structs depend on having no padding whatsoever, I’m a little surprised that they work at all.
SOUNDREG contains explicit padding, and everything is byte-sized. Everything in WA (WORLD, actually) is halfword-sized, and it’s a power of 2 in size, so what’s the problem?
Additionally, there are a few GCC extensions used in the code, particularly inline, asm- these can be conditionally defined depending on the compiler used. I do not know what extensions to ANSI C that VUCC supports, but I highly doubt it supports all of GCC’s extensions.
I don’t see the inline keyword being used anywhere.
As for inline assembly in VUCC, if you search for “asm” in CGRIND.EXE with a hex editor, it seems to support it, as well as literally implement Greenspun’s tenth rule. 😛
The signature of main() also differs between VUCC (void main) and GCC (int main). Since they’re both freestanding, neither of them are wrong (ANSI says it’s compiler-defined), but perhaps a macro could be defined which uses one signature or the other depending on the detected compiler?
HorvatM wrote:
It compiles and links fine with GCC 2.95.2 (or at least it seems to in the simple test I used). However, it complains with “video.c:26: warning: `/*’ within comment”.
Oops… will fix in a bit.
SOUNDREG contains explicit padding, and everything is byte-sized. Everything in WA (WORLD, actually) is halfword-sized, and it’s a power of 2 in size, so what’s the problem?
Nothing, because the logic of why padding is the way it is is sound :P. It’ll PROBABLY work in VUCC (as long as they use the same logic as you/GCC do for padding), just no guarantees, and I have no means to test.
I don’t see the inline keyword being used anywhere.
I defined it out using a macro for now :P.
As for inline assembly in VUCC, if you search for “asm” in CGRIND.EXE with a hex editor, it seems to support it, as well as literally implement Greenspun’s tenth rule. 😛
I think I don’t want to know…
Still interrupt vector logic will need to be changed- I highly doubt VUCC implements the interrupt vectors as extern variables embedded in its runtime like GCC does (which is also technically undefined behavior in ANSI, but few compilers are that “broken”- I’ll have to see if VUCC accepts converting fcn pointer to void/data ptr when I can test).
Does VUCC not accept int main?
I do not have the means to test right now. I simply went by what the “Sample Soft for VUE Programming” source did, which uses void main(). Again, neither one is wrong, but it may be confusing to those who decide to use VUCC.
