#23681 - Abscissa - Sun Jul 18, 2004 7:45 pm
I don't want to get into a debate on the merits of D or it's appropriateness for the GBA, but I was wondering if anyone knew if any of the existing GBA compilers or D compilers can currently be used to generate GBA roms from D source?
I don't know enough about the internals of GCC and such to really understand how this would work. Would a D compiler that can generate general ARM7 output be all I'd need, or would it need to target the GBA specifically?
#23686 - Miked0801 - Sun Jul 18, 2004 9:11 pm
Um - what's D? haven't heard of that yet - (I'm sure its the successor to C, but I have no details...)
#23689 - dagamer34 - Sun Jul 18, 2004 10:52 pm
Isn't D a game on Sega Saturn/Playstation? I hear you can't save your game and you have to beat the game in two hours or less or you loose. Talk about short-term entertainment.
Sorry if I got off topic... :)
_________________
Little kids and Playstation 2's don't mix. :(
#23697 - sajiimori - Mon Jul 19, 2004 1:08 am
It's been around for a while. I suppose it's somewhere between Java/C# and C++.
#23702 - Abscissa - Mon Jul 19, 2004 1:43 am
| Miked0801 wrote: |
| Um - what's D? haven't heard of that yet - (I'm sure its the successor to C, but I have no details...) |
It's not exactly a "true" successor to C (That would be C++ ;) ), and AFAIK I don't think the C/C++ standards commities have anything to do with it.
The official page is here: http://www.digitalmars.com/d/index.html
The overview section explains it all very well. Basically, sajiimori is right, it is sort of like something halfway between C/C++ and Java/C#. Like C/C++, it compiles to native code (no VM) and allows direct access to hardware (when allowed by the OS, of course), so it's actually useful for things like games and system applications. But like C# and Java, it aims to fix all of the major problems in C++ (And borrows a number of features from C#/Java, while fixing some of the things that went wrong).
It's designed with practicality as it's #1 priority (kinda like C#) rather than being obsessed with orthogonality at the expense of usability (as Java and Smalltalk are).
This quote is on that page and I think it sums it up very well:
| Quote: |
| "It seems to me that most of the "new" programming languages fall into one of two categories: Those from academia with radical new paradigms and those from large corporations with a focus on RAD and the web. Maybe its time for a new language born out of practical experience implementing compilers." -- Michael |
I have no idea who Michael is ;)
#23726 - keldon - Mon Jul 19, 2004 7:36 pm
oh yes, I vaguely remember D, but because it was named after C I didn't give it any notice :|.
The compiler needs to know nowt about the other hardware; it only needs to know the processor; however this means that you will have to make your own functions since there are unlikely to be any GBA objects with it; unless someone has specifically created it already (and not informed gbadev).
#23731 - Abscissa - Mon Jul 19, 2004 8:04 pm
| keldon wrote: |
| however this means that you will have to make your own functions since there are unlikely to be any GBA objects with it |
What do you mean? I don't quite follow...
#23735 - sajiimori - Tue Jul 20, 2004 5:35 am
D is not Java -- it allows direct hardware access. You don't need any special objects, and the compiler does not need to know anything else about the hardware.
#23738 - Abscissa - Tue Jul 20, 2004 8:11 am
I found a D front-end for GCC (early in development). It seems that to install it, you need to merge it in with the GCC source, and then compile it all. I don't know how GCC-savvy anyone here is (I'm definately not), but does anyone know if I would be able to stick the resulting bin(s) into devKitAdvance? Or would the D frontend stuff need to be merged into the source for devKitAdvance and rebuilt?
(Sorry if this is incoherent -- it's really late ;) )
#23740 - torne - Tue Jul 20, 2004 12:50 pm
You probably need to patch the source and recompile, but this shouldn't be difficult, it should work just the same on DKA as on a regular GCC.
#23747 - wintermute - Tue Jul 20, 2004 5:34 pm
you *will* need to patch the source and recompile.
In theory it should be relatively straightforward to modify the devkitARM build scripts to do this.
devkitadvance is likely to be problematic. The earliest patch is for gcc 3.3.2, the latest version of devkitadvance is 3.2.2 as far as I can see.
From a brief examination of the docs it looks as if D may require an OS
| Quote: |
Supported Systems
* GCC 3.3.x, 3.4 snapshots
* Linux (Red Hat 8)
* Mac OS X 10.3.2
* FreeBSD 5.2.1
* Cygwin
Similar versions should work and other Unix platforms may work. Although the compiler will probably work on most 32-bit architectures, the D runtime library will still need to be updated to support them.
"In order to prevent nested synchronized statements from deadlocking, pthread recursive mutexes are used. This can cause starvation problems on Linux. I will try the "error-checking" type mutex."
|
The best way to find out is to give it a go really - it may require some hacking on the runtime to get it building GBA binaries though.
#23752 - keldon - Wed Jul 21, 2004 2:28 am
| Abscissa wrote: |
| keldon wrote: | | however this means that you will have to make your own functions since there are unlikely to be any GBA objects with it |
What do you mean? I don't quite follow... |
As in the specific gba.h libraries that are binaries. But then again since it is all in a compiled object format; D should not have any problems. So ignore my last comment.