#6421 - TravisOwens - Sun May 25, 2003 3:10 am
I'm a budding C#.NET coder and I was wondering if anybody knew of any person/group experimenting with some dev tools that could convert .NET complied code (aka CLR) into something the GBA could run?
Considering there are 47+ .NET languages, I'm sure you could all think of how powerfull (and quirky) that would be. Imagine writing GBA games in Visual Basic.NET, Perl.NET, Fortran.NET, etc.
For all you C/C++ purists, keep the mindless flames to yourself but feel free to add something intellectually stimulating.
#6427 - Jason Wilkins - Sun May 25, 2003 9:17 am
You seem to have left everybody speechless. I'm sure it is possible. I can imagine that the Common Language Runtime would not cause too much overhead. I'm also sure that compiling the bytecodes to machine code and laying it all out in a cartridge would not be incredibly difficult either.
There may be problems with the fact that many languages do not have the mechanisms required to access memory registers or framebuffers, making it necessary to write a wrapper library for them.
There would not seem to be any technical hurdles, the real question is why anyone would want to. C and C++ are systems programming languages and were designed to do exactly what they are being used for on the GBA. C and the GBA are a great fit for each other.
I believe that higher level languages need to be designed specifically for the GBA, like Dragon Basic or Catapult, so they will have run-times which are efficiently implemented for the GBA. I myself have thought about creating a couple higher level languages specifically designed for the GBA.
(one simple language for setting registers, and another for animating sprite particle systems)
I'm not a C purest, but I like practicality. I like the problem and the solution to fit each other well. The problems that the CLR is trying to solve are not ones that really exist on the GBA (like the need to have components written in different languages work together). While I believe it could work, and perhaps even work well, it seems kinda pointless. I guess it depends on how many of those 46 languages would actually be useful for writing a game.
I hate to rule anything out without testing it first, so I'll leave the door open, and say it would be cool if someone ported the CLR to GBA and it worked well.
I have to say that because I'm still interested in getting the GCC Java compiler to work on the GBA ^_^
_________________
http://devkitadv.sourceforge.net
#6430 - tutifruti - Sun May 25, 2003 10:29 am
Maybe you can write a CLR with VB.NET and make a powerfull engine also with VB.NET and then talk with Nintendo asking for a 1Gbyte cartidge (512MB Rom/ 512MB Ram (minimum)) and a 4Ghz sfx processor. Also talk with Microsoft for instructions if one ActiveX become unregistered and the user needs support. An automatic updater for security issues is also recomended.
Sorry, I couldn't resist... :P
#6436 - torne - Sun May 25, 2003 3:47 pm
CLR code can't be trivially translated into native code any more than Java can; the issues are mostly the same. For example, gcj, the GNU native code compiler for Java, produces native binaries, but requires you to link to a massive java support library to provide things like the Java threading and locking model, garbage collection, class loading, and all the other features in the VM that you take for granted. The same, or even more, would be required for the CLR. CLR/Java apps are *never* single-threaded because of the way the VM or its native-code library equivalents do things; so you automatically need a (preemptive) thread scheduler even for trivial code (though I've almost finished my GBA scheduler *grin*).
The problems involved are shockingly gigantic; if you want a multiple-language target for the GBA, you would be better off trying to port Personal Java or J2ME in virtual-machine form, as their requirements are at least lessened; though you'd be best off designing a real embedded VM model. I'm not aware of any virtual machine architectures designed for such extreme conditions as are present on the GBA (only 32k of fast memory..etc), whether native-code compiled or not.
It is typically *much* harder to implement a native-code translator for a VM model than it is to just implement a VM.. check the progress of gcj if you doubt this. =)
Embedded systems == machine level code. Designing a suitable cross-language model for tiny systems is the subject of much research and little result. =)
Torne
#6470 - Jason Wilkins - Mon May 26, 2003 8:35 pm
I was under the impression that GCJ was further along.
I'm not sure if the problems you describe are actually "shockingly gigantic," at least to me because I had already considered them and wasn't shocked ^_^
However, those reasons are why I do not consider it a very practical thing to do.
_________________
http://devkitadv.sourceforge.net
#6475 - torne - Mon May 26, 2003 10:24 pm
Well, speaking as someone who's studied the inner workings of more than one JVM, absorbed the VM specs by painful osmosis, and in toying with the CLR has found it to be yet more complex still (though I've only had cursory glances into CLR code in the form of Mono so far), I really wouldn't want to try. =)
Maybe I can provide some nice language bindings for my OS. It has quite sensible abstractions. Right now I'm working on a capable and flexible implementation of concurrency. *grin*
Torne
#6488 - Jason Wilkins - Tue May 27, 2003 5:30 pm
I'll take your word for it, since I've managed to keep JVM and CLR at arms length so far. I'm more interested in high-performance computing and JVM and CLR just aren't that. My day job is about to foist .NET upon me though. Maybe I can flee before that happens ^_^
_________________
http://devkitadv.sourceforge.net
#6492 - Torlus - Tue May 27, 2003 7:52 pm
There's a project about a JVM for GBA at http://www.badpint.org/jaysos/.
Note that it's a port of Waba, not a port of Sun's KVM.
But as many people here, I don't think that this kind of high-level stuff could be considered as a real solution for game programming.
_________________
GBA,GC,NGPC,GP32,FPGA,DS stuff at http://torlus.com/
#6538 - torne - Wed May 28, 2003 4:30 pm
Jason: I don't want to start a java speed debate, and I certainly wouldn't write Java for the GBA, but on a full PC where limits are much higher, I have yet to write any Java code that doesn't run at the speed of equivalent C or higher. I do serverside/network stuff (not web services, real servers) and have reimplemented a number of things written in C/C++ for Linux in Java in order to *gain* performance (in exchange for memory, mostly). The server VM from Sun is truly amazing and as long as you have a vast enough heap to work with (like, say, 512Mb for a medium server, a gigabyte or more for a heavy app), it will *outperform* fully optimised C code by anything up to 20% or so by doing runtime optimisations that cannot be computed at compile time. =)
Re JaysOS/Waba on the GBA, Waba is a nice toy and is quite pleasant for implementing applications; I wouldn't want to write a game in it though. It's interpreted-only so will always be orders of magnitude slower than C code let alone my handtuned asm that I'm so fond of painstakingly writing. *grin*
The OS I'm building is a little like JaysOS, but I'm not referring to his code, and am building a more formal structure (exokernel) with less static limits. It's not intended to be practical, it's just an OS design project for me, really, but it will in theory be a nice way to implement PDA style apps on the GBA (I have a human-interfaces student working on designing input systems for me *giggle*). Also, since I'm a masochist, I'm writing it all in asm as well. Thumb asm. =)
Torne
#6541 - ampz - Wed May 28, 2003 5:08 pm
| torne wrote: |
| It will *outperform* fully optimised C code by anything up to 20% or so by doing runtime optimisations that cannot be computed at compile time. =) |
I have a big problem seeing how anything interpreted can outperform native code. Granted, the performance difference between java and native code is not that big, at lest in some cases. Load up some graphical user interface and java lags behind big time.
I also have a big problem seeing how better optimisations can be done at run time than at compile time. The compiler have access to way more information than the virtual machine.
Processor developers (Intel and AMD) Spend lots of resources trying to optimise during runtime. Still, good optimizing compilers can do much much more. GCC is _not_ the best optimizing compiler. (surprise)
Also, function oriented languages (like C) generally perform better than Object Oriented Languages (like java). The difference is not big, and is largely dependent on the coder.
#6562 - torne - Thu May 29, 2003 3:14 am
I did say I didn't want to start a Java performance debate, but hey.
Java under HotSpot is only interpreted until a specific code segment is show to be performance-critical; this is not JIT, Just-In-Time compilation, but hot compilation where a method may be compiled into an optimised version of itself even midway through execution. JIT makes startup times and memory usage massive; HotSpot distributes the load, and reduces it overall by not bothering to compile segments that are infrequently used.
Java's GUI is slow because it *draws* the GUI in *Java code*. If you use IBM's SWT, a native-code widget library (that is platform-independent on the front end, and backends exist for many OSes, including such obscure things as the Photon GUI for QNX, an embedded system), it's not noticeably slower than native code.
Better optimisations may be done at runtime using HotSpot's server VM because it can make assumptions which may not prove to be true at all times. For example, if a method in general may return either true or false (and has no side effects) but in the context it gets called from most, it always happens to return true (for this program execution only), then it can be replaced with a stub expression equal to true; and then swapped back again if the context changes. This allows you to make optimisations that are specific to a single program execution, or even just for some part of that execution, which is impossible at compile-time. The VM has access to almost identical information to the compiler in Java, too; if you ever try disassembling Java bytecode (that has not been obfuscated) you will see that other than losing private symbol names, the structure is almost identical. Add the fact that the VM has access to runtime info, and it is *definately* possible to outperform compiled code in some cases. Notice not all, or even most. In the majority of my code, HotSpot-run Java runs at approximately the same speed as native code, and outperforms in more cases than it underperforms.
Function/object oriented languages make virtually no difference in speed if implemented correctly. Java's single-inheritance model allows extremely fast virtual method dispatch, which is the only aspect of normal OO code which can be said to be 'slow'. Also, HotSpot will optimise away virtual dispatch into regular dispatch, or into inline code, if it is possible in the given (runtime, and therefore more useful) context, and appears that it will benefit performance. Java's lack of lightweight objects is more of a concern from a memory-usage standpoint (All Java objects have a monitor and class, which consumes one to three words of memory (I believe Sun's VM uses two) per object over a simple structure; but this only affects heap sizes, not execution speed.
In short, most non-GUI related Java speed issues don't exist any more thanks to Sun's HotSpot (IBM have an equivalent; other VMs are lagging somewhat) and other similar technologies, and coupled with the added developer productivity (measured, please don't argue, is boring), platform neutrality, and safety, makes it a good contender.
If you really want to see, try writing a high-performance asynchronous (single-threaded or thread-pooled, not thread/process-per-connection) web server with some dynamic content capabilities (Apache 2 might do, but for educational purposes, you should write your own), then implement the same thing in Java and compare; when I did, their execution speeds were within 10% (advantage in both directions depending on exact load), and although the Java version used about 35% more memory, it had less (found) bugs, took me only three-quarters of the time to write or less, and is, in the opinion of several people who saw it, easier to read and understand. =)
Java really has improved since all the regularly touted myths were actually true.
Torne
#6582 - Jason Wilkins - Thu May 29, 2003 8:32 pm
From your description, if someone created a systems programming language (like C/C++) with hotspot technology (like Java) it would be my perfect language ^_^
_________________
http://devkitadv.sourceforge.net
#6587 - torne - Thu May 29, 2003 9:32 pm
HotSpot works by exploiting the fact that it has interpreted code to start with; traditionally, systems programming is not done at a sensibly interpretable level.
However, if you had, for example, one of the flashy ARM cores with the JVM bytecode instruction set implemented in hardware, and came up with a minimalist VM startup section written in ARM to get the machine up and running, you could implement your OS in Java quite happily. It's been tried before and wasn't very popular because the VM technology of the time sucked, and it's not popular now just because, well, people don't like the idea of doing systems programming in an interpreted language =)
Java allows more and more systems-level programming now; for example, you can write USB drivers in Java (using a stock native-code shim that provides you with the generic USB device interface) in order to support custom devices in a platform-neutral way; you can use the recently provided memory mapping capabilities of the New IO system to talk direct to hardware (used for doing hardware OpenGL from Java, for example).. in short, the layers of native code required, while always required, are getting thinner and thinner with time as Java is seen as a better implementation langauge for software in general, rather than just apps which are specifically intended for multiplatform/web bases.
I'm a madman, of course, who programs in Java one day, and hand-optimised assembler the next; I like to use the *most* appropriate tool for every job, and except for the GBA system programming I'm doing, that's usually Java. =)
Torne