#16820 - yasuna - Wed Feb 25, 2004 3:43 pm
hello, i'm using .Net framework and the new language c# ! can we code gba with c# ?
#16830 - Miked0801 - Wed Feb 25, 2004 6:09 pm
Why? ;)
I believe there's a GCC compiler for C# so in theory it would be possible, but...
#16844 - ampz - Wed Feb 25, 2004 9:02 pm
..And you cannot use the .net framework :)
#16855 - torne - Wed Feb 25, 2004 11:16 pm
A GCC frontend for C#? Where? I'd like to see it. (it *is* possible, but would be moderately useless; it would be like being able to compile Java but having none of the standard Java library available).
#16861 - ampz - Thu Feb 26, 2004 12:11 am
Stranger things have happened..
I read somewhere that a Visual Basic package for linux is in progress.
#16910 - SmileyDude - Thu Feb 26, 2004 8:45 pm
Wouldn't a C# and Java compiler for the GBA have to provide some sort of runtime library? That's one of the really nice things about C is that you don't need any runtime support.
And, the other question would be if you already know C#, why wouldn't you just give C and/or C++ a try?
_________________
dennis
#16911 - Lupin - Thu Feb 26, 2004 10:00 pm
I am quite sure that there is already a visual basic compiler for linux...
.Net on gba? I will commit suicide if this will ever happen.... (please don't start working on a .Net framework for GBA now :P)
#16915 - ampz - Thu Feb 26, 2004 10:34 pm
GBA.net :)
#16917 - sajiimori - Fri Feb 27, 2004 12:17 am
Somebody already got Java working on GBA. As far as everybody asking "why C#", how about properties? Delegates? Automatic storage management? Lack of cruft (comparitively speaking)? Safety by default? No header management?
#16933 - jma - Fri Feb 27, 2004 3:36 pm
And the fact that it sux... sorry, that just slipped out :)
Jeff
_________________
massung@gmail.com
http://www.retrobyte.org
#16934 - SmileyDude - Fri Feb 27, 2004 5:05 pm
| sajiimori wrote: |
| Somebody already got Java working on GBA. As far as everybody asking "why C#", how about properties? Delegates? Automatic storage management? Lack of cruft (comparitively speaking)? Safety by default? No header management? |
I would agree that Java the language and C# the language provide some desirable features over C and C++ -- but, I go back to the runtime support. To run either of those languages, you need runtime support. And, quite frankly, I don't want a runtime competing with my code for CPU time and ROM space.
_________________
dennis
#16935 - DarkPhantom - Fri Feb 27, 2004 5:15 pm
You wouldn't nessecarilly need a C# compiler. Remember, Microsoft has developed their own version of what can be considered "byte code" like with Java. Just like GCC converts C++ into assembly. The microsoft C# compiler translates C# into Microsofts "intermediary" language. Which is basically like a universal assembly code. I've only skimmed the documentation but as I understand it, all you need to do to "port" C# is to write a just-in-time-compiler, like what Java uses, or write a program that will permenently convert the intermediary into ARM/THUMB code. In either case, you'd need to write a minimal implementation of the .NET framework. Alternately, you could also just write an interpreter or "emulator" for the intermediary but Microsoft says that this should never be done.
It's funny because Microsoft claims that .NET and their intermediary language makes C#, J# and VB.net all platform independant (which is theorietically true) even though .NET is only available for Windows and no program exists to translate the intermediary for any processor other than the 80X86. The best part about this though, is that if you actually got C# running on the GBA, J# and VB.net would also work because they also use the intermediary language and .NET framework.
All of this begs the question "why?" Even if you rewrote most of the core objects you're funtionality would be very limited plus, you wouldn't have access to any of the GameBoy's specific capablities unless somebody wrote classes for the GameBoy which would make any program be dependant on "GBA.NET."
Say somebody was to implenment just a C# compiler that would generate native code. C# is a higher level language then anything currently being used on the GBA. Direct hardware manipulation would be a pain so you'd need to use some really highlevel libraries which would probably happer performance. Why go through all that trouble? C# is certainly not the ideal language to be programming a console video game system with.
_________________
"head straight for your goal by any means
there is a door that you've never opened
there is a window with a view you've never seen
get there no matter how long it takes"
-Theme of Shadow, Sonic Adventure 2
#16950 - sajiimori - Fri Feb 27, 2004 9:23 pm
| Quote: |
And the fact that it sux... sorry, that just slipped out :)
|
Can't disagree with ya there.
| Quote: |
To run either of those languages, you need runtime support. And, quite frankly, I don't want a runtime competing with my code for CPU time and ROM space.
|
The key word there being "I". Are you posting to help the person asking the question, or do you just want to share your preferences with all of us?
| Quote: |
It's funny because Microsoft claims that .NET and their intermediary language makes C#, J# and VB.net all platform independant (which is theorietically true) even though .NET is only available for Windows and no program exists to translate the intermediary for any processor other than the 80X86.
|
Microsoft's own CLI runs on XP, OS X, and FreeBSD. Portable.NET additionally runs on Linux and Solaris, supporting the x86, PowerPC, ARM, Sparc, PARISC, s309, Alpha, and IA-64 processors.
| Quote: |
...you wouldn't have access to any of the GameBoy's specific capablities...
|
C# allows pointer math and direct memory access if you use the "unsafe" keyword. You can also link it to C libraries. Recall that even C doesn't give access to all of GBA's features (SWIs for instance).
| Quote: |
...unless somebody wrote classes for the GameBoy which would make any program be dependant on "GBA.NET."
|
You're worried that if somebody wrote a library specifically for .NET on GBA, it would only work with .NET on GBA? Ok, and existing GBA apps don't compile on Windows, either.
#16951 - DarkPhantom - Fri Feb 27, 2004 9:34 pm
Okay sajiimori. Seems you really like Microsoft are are well aquainted with C#. (more and better than me, respectively). If you're so smart, name one advantage that there would be to programming the GBA in C#, without or without anykind of .NET implemtation. I know about the unsafe keyword, that's why I said it would be a pain, not impossible.
You can access SWI interrupt functions very easilly in C/C++ using inline assembly:
asm("swi #0x060000"); // let's do some divsion!
Correct me if I'm wrong but you couldn't do something like that with C#. True, it's not technically part of C so, you're not "doing it with C" but it's being done in a C program none the less. And don't complain about the SWI using registers that the C compiler would be using for variables because you can easilly assign what varaibles go where using GCC.
_________________
"head straight for your goal by any means
there is a door that you've never opened
there is a window with a view you've never seen
get there no matter how long it takes"
-Theme of Shadow, Sonic Adventure 2
#16954 - sajiimori - Fri Feb 27, 2004 9:54 pm
| Quote: |
name one advantage that there would be to programming the GBA in C#
|
I named several earlier. Whether they are advantageous for you is not for me to say.
| Quote: |
True, it's not technically part of C so, you're not "doing it with C" but it's being done in a C program none the less.
|
Arguably, the program would no longer be C (according to ANSI). But the point is taken. I personally don't use inline assembler -- I keep a seperate .s file -- so for me the difference is not significant.
Anyway, if you want to continue this discussion, I'd appreciate it if you'd keep the ad-hominem to a minimum (e.g. "MS-loving smarty-pants").
#16957 - poslundc - Fri Feb 27, 2004 10:05 pm
| DarkPhantom wrote: |
You can access SWI interrupt functions very easilly in C/C++ using inline assembly:
asm("swi #0x060000"); // let's do some divsion! |
I don't know a damn thing about C#, but this would be some very foolhardy code to run.
Dan.
#16959 - DarkPhantom - Fri Feb 27, 2004 10:18 pm
| sajiimori wrote: |
| Anyway, if you want to continue this discussion, I'd appreciate it if you'd keep the ad-hominem to a minimum (e.g. "MS-loving smarty-pants"). |
Yeah, sorry about that but I felt attacked just because I was simply mistaken on where C# could be currently be run.
As for poslunc. Yeah, I wouldn't run that code either but I'm just saying it would be possible to access SWI directly from C if you wanted to. There are some useful BIOS functions that one might want to use in a C program (probobly not division, I just picked that I one cuz it's the only one I could think of off the top of my head). Probobly you want to make a little C callable function that would access them in assembly but, that wasn't my point.
_________________
"head straight for your goal by any means
there is a door that you've never opened
there is a window with a view you've never seen
get there no matter how long it takes"
-Theme of Shadow, Sonic Adventure 2