complete emulation of PC

[Jeff Robertson]

Does anybody know of a complete emulation of an "IBM or compatible PC"
written entirely in Java? This would involve emulation of the x86
processor, memory, video hardware, etc.

There are a number of virtual machines and emulators out there, but
none that I know of that are Java.

As an example of the kind of thing that you should be able to do with
this, you should be able to take game binaries compiled under MS-DOS
and run them inside an applet.

This is for pleasure, not for work.

 

[Roedy Green]

As an example of the kind of thing that you should be able to do with
this, you should be able to take game binaries compiled under MS-DOS
and run them inside an applet.

It would be extremely slow to emulate on a bit level. Another way to
do it, more difficult but faster, is to translate the code to the
equivalent byte code or native machine code on your platform.
Intel code is not very tractable. You can't even easily tell
instructions from data.

 

[Jeff Robertson]

It would be extremely slow to emulate on a bit level. Another way to
do it, more difficult but faster, is to translate the code to the
equivalent byte code or native machine code on your platform.
Intel code is not very tractable. You can't even easily tell
instructions from data.

Sure, it would be slow. But a modern PC is so much faster than the
class of machine I'm interested in emulating that it should make up
for the slowness, shouldn't it? We're talking about a 2 GIGAhertz
machine emulating a 2 MEGAhertz machine.

 

[Brad BARCLAY]

Sure, it would be slow. But a modern PC is so much faster than the
class of machine I'm interested in emulating that it should make up
for the slowness, shouldn't it? We're talking about a 2 GIGAhertz
machine emulating a 2 MEGAhertz machine.

IBM PC class systems were never as slow as 2Mhz -- the slowest models
were 4.77Mhz.

Brad BARCLAY

 

[Neil Campbell]

Does anybody know of a complete emulation of an "IBM or compatible PC"
written entirely in Java? This would involve emulation of the x86
processor, memory, video hardware, etc.

There are a number of virtual machines and emulators out there, but
none that I know of that are Java.

As an example of the kind of thing that you should be able to do with
this, you should be able to take game binaries compiled under MS-DOS
and run them inside an applet.

This is for pleasure, not for work.

I don't know of one, but it sounds like quite a fun idea. If you started an
open source project, I'm sure plenty of people would be willing to
contribute.

 

[Roedy Green]

e're talking about a 2 GIGAhertz
machine emulating a 2 MEGAhertz machine.

On every instruction, you first of all have to decode the instruction.
That in itself could take a fair number Java statements. The fields
are variable and packed on odd boundaries. Have a look at the bit
packing for all the variants of the mov instruction. (This is not
exactly fresh, but I wrote an assembler for the 8086 and 8087). Then
you have to simulate the instruction itself. Some are easy like 16 bit
add. Then there is the effect on the condition code registers to
simulate. You have to be detect -ve and overflow. You would be doing
well to simulate with only 1000 machine instructions per original.
Does anyone have an estimate of how well hotspot does in lines of java
= machine instructions average or java byte codes = machine
instructions average?

You also have to simulate the OS calls it uses, or the hardware it
uses. e.g. if it pokes to the regen screen, you have to give it some
ram it thinks in the regen screen and periodically scan that for
changes and draw the appropriate characters.

You might want to try some even more primitive machines first. See
http://mindprod.com/jgloss/projlovelace.html

 

[Eric Sosman]

You also have to simulate the OS calls it uses, or the hardware it
uses. e.g. if it pokes to the regen screen, you have to give it some
ram it thinks in the regen screen and periodically scan that for
changes and draw the appropriate characters.

The memory should be a big array of PCByte objects, and
the regions with special purposes (video RAM, etc.) should
be populated with subclasses that extend PCByte and have the
necessary special behaviors.

That eliminates the inefficiency of polling. ;-)

 

[Neil Campbell]

On every instruction, you first of all have to decode the instruction.
That in itself could take a fair number Java statements. The fields
are variable and packed on odd boundaries. Have a look at the bit
packing for all the variants of the mov instruction. (This is not
exactly fresh, but I wrote an assembler for the 8086 and 8087). Then
you have to simulate the instruction itself. Some are easy like 16 bit
add. Then there is the effect on the condition code registers to
simulate. You have to be detect -ve and overflow. You would be doing
well to simulate with only 1000 machine instructions per original.

Yes, but if you're careful, once you've translated the original you can
cache that translation and just reuse it; effectively you can become a form
of dynamic compiler. The overhead will still be high, but once you get
going you could certainly do better than 1000 instructions per original
instruction.

 

[Brad BARCLAY]

On every instruction, you first of all have to decode the instruction.
That in itself could take a fair number Java statements. The fields
are variable and packed on odd boundaries. Have a look at the bit
packing for all the variants of the mov instruction. (This is not
exactly fresh, but I wrote an assembler for the 8086 and 8087). Then
you have to simulate the instruction itself. Some are easy like 16 bit
add. Then there is the effect on the condition code registers to
simulate. You have to be detect -ve and overflow. You would be doing
well to simulate with only 1000 machine instructions per original.
Does anyone have an estimate of how well hotspot does in lines of java
= machine instructions average or java byte codes = machine
instructions average?

Well, let's not forget that if we were to hypothetically target the
8086 and have it run on modern hardware that there isn't a 1:1 speed
relationship.

The 8086 itself couldn't decode and run an instruction in a single
clock cycle. Many of the instructions took 3 or more cycles to decode
and execute. There was only one pipeline, so you couldn't do parallel
decodes/operations like you can on modern processors.

I think that the issue of speed isn't going to be a stumbling block in
this hypothetical project -- instead, the biggest problem is going to be
/timing/. The original PC's clock ran at 1 431 818 Hz. That's one
cycle in just under 7*10e-7 seconds (or 7*10e-3 milliseconds). That's
going to be rather difficult to emulate under Java on a modern
multitasking OS -- my desktop OS of choice (OS/2), for example, has an
8ms granularity.

This can obviously be somewhat fudged, and for many application it
simply won't matter. For anything timing-dependant, however, it may be
an issue.

Memory allocation might also be an issue. Emulating the system RAM and
ROM might require a 1MB byte array. And the ROM itself might pose an
issue, as getting a ROM image for such a system might be tricky -- we'd
have to produce our own reverse-engineered version.

I'd be tempted to join such a project if it's initial goals were low --
to emulate an IBM PC with a monochrome graphics adapter. Such a
reference platform is very well documented, and makes for a realistic
first attempt. Everything could be expanded from there.

Brad BARCLAY

 

[Roedy Green]

Yes, but if you're careful, once you've translated the original you can
cache that translation and just reuse it; effectively you can become a form
of dynamic compiler.

That's how the Mac Power PC manages to emulate a Motorola 68K with
reasonable efficiency. The Motorola 68K is a simpler chip to emulate
than the 8086. It is still a far from trivial task.

Given the many ways you can cheat on an 8086, e.g. computing a number
and adding it to the instruction counter and writing self-modifying
code, it would be very tricky to emulate with compiled code.

 

[Roedy Green]

I'd be tempted to join such a project if it's initial goals were low --
to emulate an IBM PC with a monochrome graphics adapter.

Forths use typically use a very limited subset of the OS capability.
And it is easy to patch such os interface code to use some other
method.

A subgoal might be to run programs written in Forth. Trying to emulate
everything the BIOS and OS does greatly adds to the complication.

 

[Neil Campbell]

That's how the Mac Power PC manages to emulate a Motorola 68K with
reasonable efficiency. The Motorola 68K is a simpler chip to emulate
than the 8086. It is still a far from trivial task.

Given the many ways you can cheat on an 8086, e.g. computing a number
and adding it to the instruction counter and writing self-modifying
code, it would be very tricky to emulate with compiled code.

Difficult, sure, but doable. Transmeta's Crusoe chip has a software layer
than dynamically translates x86 code to its own instruction set.
Admittedly, it can use some hardare tricks as well, but there are other
software only solutions.

Writing it in Java makes it more difficult again, because of the
restrictions of the VM, but it would certainly be interesing to try.

 

[Andrew Cowper]

You might want to try some even more primitive machines first. See
http://mindprod.com/jgloss/projlovelace.html

For other primitve machines - try

http://www.spectrum.lovely.net/
http://www.dreamfabric.com/c64/