You are not logged in.
Lost Password?


Register To Post



 Bottom   Previous Topic   Next Topic

#51
Re: A newer GCC compiler.
Posted on: 2018/12/17 10:49
Administrator
Joined 2000/1/8
Germany
2506 Posts
Highscore Top10Highscore Top ScoreCoder#1 PosterHOTY09 1stLong Time User (15 Years) App Coder90+ Game Ratings
Awesome, ElmerPCFX! I am glad these patches are finally out! I guess we now have a foot in the door for Linux (and possibly OSX) versions of VBDE. :-)
Top

#52
Re: A newer GCC compiler.
Posted on: 2018/12/18 20:35
VB Gamer
Joined 2016/3/13
42 Posts
Long Time User (3 Years)
Quote:

KR155E wrote:
I guess we now have a foot in the door for Linux (and possibly OSX) versions of VBDE. :-)

Yep, I had to change/fix a bunch of things to get the Linux compilation working again, and those should probably help the compilation on OSX.

I also fixed (or at-least tried to fix) a couple of bugs in GCC 4.7 that compiling on the latest GCC brought to light ... and generally cleaned-up the code to fix the warnings (or silence them if they couldn't be fixed).

I've found a site talking about how to compile GCC on OSX, and I may take a look at it myself if somebody doesn't beat me to it!

I really hope that you guys take a look at using the C++ support in VUEngine since you're already using an object-oriented design.

Using basic Embedded C++ language features should allow you to make your code a lot more readable/debuggable than using all of those cunning-but-fragile macros.
Top

#53
Re: A newer GCC compiler.
Posted on: 2018/12/20 14:21
Nintendoid!
Joined 2006/3/15
Ecuador
228 Posts
PVBCC 3rdCoderLong Time User (13 Years)
Quote:

Yep, I had to change/fix a bunch of things to get the Linux compilation working again, and those should probably help the compilation on OSX.

I've found a site talking about how to compile GCC on OSX, and I may take a look at it myself if somebody doesn't beat me to it!


Hey Elmer!

I already compiled it on macOS Mojave, but I didn't really documented the process and it was kind of messy and hackish since I had to even modify one of the config.guess files, among other things. Anyway, I'm still porting our preprocessor before being able to successfully build any of our demos, so, I'm not 100% sure that the compiler is working fine.

Quote:

I really hope that you guys take a look at using the C++ support in VUEngine since you're already using an object-oriented design.

Using basic Embedded C++ language features should allow you to make your code a lot more readable/debuggable than using all of those cunning-but-fragile macros.


The plan is to evaluate, in the middle term, if it is feasible given the complexity and memory requirements of the engine. But right now we want to concentrate in implementing a complete game instead of keep pushing developer features. Anyway, thanks to the preprocessor, the code is around 85% based on C++'s syntax (the only missing syntax feature is proper method calling), so, that part of the port should be really easy. The hard part will be, first, to customize the memory handling since I don't have enough experience on the inners of C++'s compiler and linker so I don't know if it is possible to instruct it to allocate the virtual tables in specific memory regions or even if they can just be computed at compile time and placed in the ROM area (we load them in DRAM instead of WRAM because they amount to more than 10 KB and they are populated at runtime); and second, to handle the allocation of dynamic objects, although I guess we just have to override the new operator and just use our own MemoryPool to avoid the usage of the heap.

jorgeche
Edited by jorgeche on 2018/12/20 14:43
Top

#54
Re: A newer GCC compiler.
Posted on: 2018/12/22 21:51
VB Gamer
Joined 2016/3/13
42 Posts
Long Time User (3 Years)
Quote:

jorgeche wrote:

I already compiled it on macOS Mojave, but I didn't really documented the process and it was kind of messy and hackish since I had to even modify one of the config.guess files, among other things.

Congrats! I hope that the changes that I made to get it compiling on linux, will make it easier for you to build it on OSX in the future.


Quote:

The hard part will be, first, to customize the memory handling since I don't have enough experience on the inners of C++'s compiler and linker so I don't know if it is possible to instruct it to allocate the virtual tables in specific memory regions or even if they can just be computed at compile time and placed in the ROM area (we load them in DRAM instead of WRAM because they amount to more than 10 KB and they are populated at runtime); and second, to handle the allocation of dynamic objects, although I guess we just have to override the new operator and just use our own MemoryPool to avoid the usage of the heap.

VTables are always constructed at compile-time. For speed on the VirtualBoy, you're going to want to have the linker put them in either the ZDA section, or the TDA section so that they can be addressed in a single instruction relative to the R0 or R5 registers.

Putting them in the R0 section would be best (IMHO), at the top of your mirrored ROM space so that they show up in the $FFFF8000-$FFFFFFFF region. But, IIRC, that would mean that you've have to do some fiddling about with your linker script.

Even then, I'm not sure that VTables are marked at register-relative by the compiler ... that may need another hack into the GCC source code.

The recent version of the patches has already started the process of making it possible to distinguish between the VirtualBoy and the PC-FX, so that I can take advantage of your system's ability to load unsigned bytes-and-words without masking off the high bits afterwards.
Top

 Top   Previous Topic   Next Topic


Register To Post