Jpc - Java Linux & Arm Optimized Dos Emulator


Captainbubby said:
http://www-jpc.physics.ox.ac.uk/InAction.html

Just putting this out there, I know there's been a lot of people asking about the potential of emulating old DOS games, perhaps this one might what we're looking for?

It's already optimized for the ARM CPU and there's a linux version to boot. :D



an interesting project, but its java, meaning it would be a good deal slower than c++ compiled code (ie, dosbox)
 
Last edited by a moderator:
Snu said:
an interesting project, but its java, meaning it would be a good deal slower than c++ compiled code (ie, dosbox)
Whilst for the principle is certainly right, surely it depends on how efficient the code is? And whilst I don't know how efficient dosbox actually is, I've heard inklings implying that it isn't especially. For starters, I would be *very* surprised if it resulted in this project's claimed 20%-of-the-cpu-it's-running-on; I don't believe I could run Starcraft on Win98 in Dosbox at a decent speed on my current PC, for instance (20% of 2ghz is ~400MHz, which theoretically should be enough, but practically definitely isn't).

That said, I haven't tried doing that in this emu either; it's entirely possible (and in fact, probable I imagine) that this emu isn't emulating anything beyond 186 or 286 machines - especially since they're using the original mario as example screenies. So maybe I could hapilly emulate a 400MHz 286 on my PC in Dosbox - it's just that the moment I move to a 386 or above, the required power to emulate the chip increases exponentially.

This is of course moot, because, as Slaanesh said, you need Java first.

Disclaimer: I am not a developer. There may be coding or power calculation fallacies above.
 
Last edited by a moderator:
Like a lot of emulators for Java I hear about these days this one is compiling to JVM. The argument is usually "hotspot can do a better job recompiling than anyone could", although I think the runtime requirements and the added layer of translation hinders this. Still good enough to provide decent results, so long as you're not emulating many other complex components in addition to the CPU. It's at least possible that it does better than DOSBox for what it does.

I want to know where it gets these 20% numbers though. The only way for such a number to be legitimate is if they've benchmarked programs that are 100% CPU bound running in real mode both on the CPU directly and in the emulator.

Obviously for it to be a possible option on Pandora Pandora will need not just the JVM but one with good JIT.
 
Exophase said:
Obviously for it to be a possible option on Pandora Pandora will need not just the JVM but one with good JIT.
Or someone could try to reverse engineer the jazelle stuff in the processor, dunno how possible/probable that is though.
 
Last edited by a moderator:
flatmush said:
Or someone could try to reverse engineer the jazelle stuff in the processor, dunno how possible/probable that is though.

I wish you the best :D

Read this paper: http://www.arm.com/pdfs/JazelleDBX_WhitePaper_2007v1p1.pdf
And note that you will need some software layer because some JVM opcodes need to be emulated (cf end of page 3, start of page 4 of the afore-mentionned document).

Also it looks like the iPhone and Google's Android don't make use of Jazelle DBX. There might be some good reason behind that decision...
 
Last edited by a moderator:
Laurent said:
And note that you will need some software layer because some JVM opcodes need to be emulated (cf end of page 3, start of page 4 of the afore-mentionned document).
I had assumed this was an undocumented feature, having seen the documents I don't see the major difficulty unless the remaining opcodes are more complex functions to integrate with the window manager and hardware?
Still I'm guessing if it requires interrupts to handle the remaining opcodes then it needs some support for jazelle to be implemented in the kernel, unless there's a method to redirect exceptions that I don't know of.

Anyway although I do have a reasonable understanding of arm assembly, I doubt I'd attempt this myself just because I absolutely hate java.

QUOTE
There might be some good reason behind that decision...

Usually the reason behind thing like this is that the work isn't worth the reward, they aren't going to make any more sales for increased java performance so there's no reason that they'd delay releasing them to implement it.
That doesn't mean it's worthless.
 
Last edited by a moderator:
Laurent said:
Oh BTW I have some news for you: Cortex-A8 hasn't Jazelle DBX, but Jazelle RCT ;)
QUOTE
Jazelle RCT can be used to significantly reduce the code bloat associated with AOT and JIT compilation, making AOT technology viable on mass-market devices. It can also be used to support execution environments beyond Java, such as Microsoft .NET Compact Framework, Python and others.

Jazelle RCT can be used to allow AOT compilation to be used more extensively and can also be combined with JIT technology on very high frequency platforms, where start-time and smoothness issues lessen.


Ok, I take it all back. That is pretty useless, never heard of RCT before, I thought all jazelle implementations were DBX. Why do people never learn that java == phail.
 
Last edited by a moderator:
Snu said:
an interesting project, but its java, meaning it would be a good deal slower than c++ compiled code (ie, dosbox)
Laurent said:
I hate Java too.
http://en.wikipedia.org/wiki/Java_performance

Take it back. :D

The fact is, Java is getting better and better with every new release. Even the initial startup times are currently being seriously looked at by the Java developers, so hopefully we'll see an end to these sorts of comments.
 
Last edited by a moderator:
First, it's not because of speed reasons that I hate Java. I just can't stand OO programming. I hate C++ as much as Java :D

Second, I bet I can write a faster program in C than any given CPU bound Java program.
 
Laurent said:
Second, I bet I can write a faster program in C than any given CPU bound Java program.
I bet I can write a faster program in Assembly than any given CPU bound C program, but it might take me a while.

It's not about performance, it's about ease of use. Java is much more user friendly than C.
 
Last edited by a moderator:
Shiny said:
It's not about performance, it's about ease of use. Java is much more user friendly than C.
C is simpler, it has lots less complexities. People think that java and C++ are better because of their feature-set but they tend to over-complicate things and encourage in-efficient programming.
Java was created for portability, so you don't use it for performance, you use it to create platform specific byte-code, thats what it was invented for and that is what it should be used for.
If your program isn't going to be 100% platform specific then you should be using c++ or c.
 
Last edited by a moderator:
flatmush said:
Shiny said:
It's not about performance, it's about ease of use. Java is much more user friendly than C.
C is simpler, it has lots less complexities. People think that java and C++ are better because of their feature-set but they tend to over-complicate things and encourage in-efficient programming.


Not exactly. Because everything is in object form, all you have to know is the fundamentals of OOP in Java, and then any library or new concept is easy, because they all use the same structure. I learned, within hours, how to HTTP POST an XML body, and then parse an XML response from the server. I had never done anything like that before. At all.

There are other examples, but I won't bore you with off-topic banter. The point is, just because this software has Java components doesn't mean it's going to be slow (or even hard to figure out).

flatmush said:
If your program isn't going to be 100% platform specific then you should be using c++ or c.
Then C++ or C has a very small audience in the FOSS world because most FOSS is developed for Windows, Linux, and Mac, or two of the three at least.
 
Last edited by a moderator:
Shiny said:
Laurent said:
Second, I bet I can write a faster program in C than any given CPU bound Java program.
I bet I can write a faster program in Assembly than any given CPU bound C program, but it might take me a while.
Well, of course if you want network and HTML for free, then development time will be less for Java, because of libs only, not because of the language.

QUOTE
It's not about performance, it's about ease of use. Java is much more user friendly than C.

Perhaps for you. But if your program ends up being too slow, then it won't be *end-user* friendly.
 
Last edited by a moderator:
I will point to a situation where Java wasn't "slow" and was "appropriate" for the task in question:

Tribal Trouble

In fact, I would surmise that one could probably GET that game (and it'd be cool as all get out) on the Pandora if they think the effort would at least break-even for them.

Having said this, Java's not appropriate for all tasks, much the same as C or C++ isn't (For example, there's tasks that Icon, Lisp, Forth, and a host of others are more suited to doing the work.)- so it's all six of one, half dozen of another.

I'll see if the Java support on N800's jelled enough to try this bad boy out and see what it brings to the table for us. We might be surprised enough to bother with it.

Having said this, I'm NOT holding my breath- blue's my favorite color, but I don't like it on my skin except as clothing... ;)
 
Hum, is that CPU bound? It doesn't look so :)

Yeah I know, I am a bastard :D

Anyway this Java stuff is like all religious wars, vi vs emacs vs whatever, Windows vs Linux, and so on. It boils down to "my d.ck is bigger than yours, because I spend my day answering spam to enlarge my penis".
 
I like that this has become a Java argument thread :D

javaJake said:
Not exactly. Because everything is in object form, all you have to know is the fundamentals of OOP in Java, and then any library or new concept is easy, because they all use the same structure. I learned, within hours, how to HTTP POST an XML body, and then parse an XML response from the server. I had never done anything like that before. At all.
The "fundamentals" of OOP are actually pretty substantial and could fill many course books. Really there's nothing implicitly difficult about picking up a library for any language if that library is cleanly written. I don't see why either of the things you've mentioned (HTTP posting and XML parsing) would be a problem given the correct libraries. I haven't used PHP in years but I'm sure I could do those things in it without taking too much time since it has good good libraries for those purposes. That doesn't mean that I think PHP is the best language on the face of the planet.

javaJake said:
There are other examples, but I won't bore you with off-topic banter. The point is, just because this software has Java components doesn't mean it's going to be slow (or even hard to figure out).
No, it definitely doesn't mean it'll be slow, but the same could be said for almost any language. I do believe that Java has a greater barrier for optimization because there are some things you can't work around.

javaJake said:
Then C++ or C has a very small audience in the FOSS world because most FOSS is developed for Windows, Linux, and Mac, or two of the three at least.
I think that he meant that C/C++ is good unless you need 100% portability.

The thing is, in practice Java programs don't end up being more portable than C ones because they rely on a large runtime to be ported. In the case of C, you need something like SDL for more than console I/O, but that's much simpler to port and I expect has already been ported to many more places than Java has been. Now, Java does guarantee that you're able to do a lot of things that a simple library like SDL won't, so if what you're doing uses these things then Java might be a better choice for portability.
 
Last edited by a moderator:
Back
Top