[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Dynamic translation and native drivers (was bochs-990110 andbeyond? MP)

"J. S. Connell" wrote:
> On Tue, 12 Jan 1999, Bill Hayden wrote:
> > The same can be said in regards to the pass-thru Windows/Linux drivers we have
> > been discussing lately, i.e. non-Windows, non-Linux users will be left
> > behind.  As a multiprocessor PowerPC-based MacOS and BeOS user, I fall into
> > every one of the categories mentioned, so that is the reason for my concern.

The problem with machine specific code is that you need the expertise
in that particular architecture to remain active.  What ends up happening
in many projects is that someone will do a YYY port, then the base 
architecture gets changed/reved, and YYY port breaks.  If you are lucky,
then the person who did the YYY port will fix it.  If not, then the
port gets screwed until someone else takes the mantle.  

> I somehow doubt Kevin would screw the nonIntel users of Bochs over like
> that.  I might be able to offer some assistance with a SPARC backend for
> the dynamic translation, depending on how hairy it is.

well, even if the dynamic compilation was an option, having a version that
runs 50x slower is not too attractive as an option (BTW, I'll help out
on SPARC also).

> The discussion about "native" (or seminative, at least) drivers did not
> mention restricting it to Windows; one could write an fbcon driver for
> Linux or an X server for Intel UNIXes, and I'm sure BeOS must have _some_
> sort of facility for video drivers.  Heck, one could probably even write an
> INT 10h shim for DOS - VBE, anyone? =)

Not exactly sure what the above is saying.

As an observation:

Insignia has a product on the UltraSPARC + MAC called RealPC.  It's a Pentium
emulator (for $80 from SunExpress) that has not-pathetic performance on
my ultraIIi-300.  In it, they have native winblows drivers for: display
(with DDraw!), audio, HD, CDrom controller, mouse, and network adapter.
They also have their "FSA" drive scheme (allows mapping of unix -> windows
filesystem), something that would be useful also (vpix and merge had this).

This seems to be a good feature set for things that you want to do a 
emulated->native gateway for things.

Point on dynamic compilation:
As far as I can tell, you basically have 3 ways you can look at this problem:

x86 -> virtual CPU -> generic C-based optimizers
x86 -> x86 (rewriting so that only "safe" instructions are executed).
       Probably the easiest of the dynamic compilation lot, but non
       portable across CPUs
x86 -> cpu depended instruction streams.

Given these 3 options: I propose the following:

You might give serious consideration in creating a "jbochs". (java version of bochs).

Here is my reasoning (I know everyone is screaming "bochs is slow enough already!"):

1) Given that there is a fair amount of other work in getting java JITs better,
   it might be practical to concentrate on a x86->javaVM translator, and let
   the JIT people figure out how to get virtual instructions to run faster.
   Remember that creating instructions to execute will involve a non-zero
   knowledge of the CPU/OS combination of the platform you're writing to.
   linux x86 is not necessarily the same as solaris x86 -  this is going to cause
   a fair amount of redundant work.
2) This also allows in a well architected program to add native methods to
   speed things along.  ***MOST*** of the execution currently is confined to
   a few routines - a managable problem.
3) Since programmer resources are now NOT spent on CPU / OS dependencies,
   you can now spend time on doing the other big win like the windows->native
   interfaces for display, disk, etc.
4) The MP issues become ***a LOT*** simpler.  Let the JVM deal with it.
5) Give kevin a reason to learn Java :-)

I think over the longer haul, this is a better approach since it will become
an optimization problem, as opposed to being a translater problem.

Any thoughts?


Roger Fujii <rmf lookhere com>     Phone: (703)280-1243
Underemployed, and trying to keep it that way....

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]