[comp.sys.atari.st] PC-Ditto speed "XDOS"

fred@pnet01.cts.com (Fred Brooks) (04/27/88)

What we really need is a product like 'XDOS'. XDOS takes a MS-DOS program
and converts it to 680X0 machine code. When this is done the program often
runs faster then the INTEL machine it was written for. This product is already
running on UN*X systems maybe someone will get an ST version.


UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!fred
ARPA: crash!pnet01!fred@nosc.mil
INET: fred@pnet01.cts.com

neil@cs.hw.ac.uk (Neil Forsyth) (05/02/88)

In article <2882@crash.cts.com> fred@pnet01.cts.com (Fred Brooks) writes:
>What we really need is a product like 'XDOS'. XDOS takes a MS-DOS program
>and converts it to 680X0 machine code. When this is done the program often
>runs faster then the INTEL machine it was written for. This product is already
>running on UN*X systems maybe someone will get an ST version.

Interesting but I wonder what XDOS does about vector tables in the data
segment since Intel and Motorola store longwords differently ie. reversed.
And then there is always the clowns who pervert the idea by putting data in
the code segment.

-------------------------------------------------------------------------------
"I think all right thinking people in this country are sick and tired of being
told that ordinary decent people are fed up in this country with being sick and
tired. I'm certainly not and I'm sick and tired of being told that I am!"
- Monty Python - "I could be arguing in my spare time"

 Neil Forsyth                           JANET:  neil@uk.ac.hw.cs
 Dept. of Computer Science              ARPA:   neil@cs.hw.ac.uk
 Heriot-Watt University                 UUCP:   ..!ukc!cs.hw.ac.uk!neil
 Edinburgh
 Scotland
-------------------------------------------------------------------------------

jsp@sp7040.UUCP (John Peters) (05/03/88)

In article <2882@crash.cts.commore>, fred@pnet01.cts.com (Fred Brooks) writes:
more> What we really need is a product like 'XDOS'. XDOS takes a MS-DOS program
more> and converts it to 680X0 machine code. When this is done the program often
more> runs faster then the INTEL machine it was written for. This product is already
more> running on UN*X systems maybe someone will get an ST version.
more> 
more> 
more> UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!fred
more> ARPA: crash!pnet01!fred@nosc.mil
more> INET: fred@pnet01.cts.com

	This sounds very interesting to me.  Is XDOS public domain.  If not or
so (either one) where can it be found.  Thanks for this bit of info.

					--  Johnnie  --

trb@stag.UUCP ( Todd Burkey ) (05/05/88)

In article <2882@crash.cts.com> fred@pnet01.cts.com (Fred Brooks) writes:
>What we really need is a product like 'XDOS'. XDOS takes a MS-DOS program
>and converts it to 680X0 machine code. When this is done the program often
>runs faster then the INTEL machine it was written for. This product is already
>running on UN*X systems maybe someone will get an ST version.

We called the XDOS people recently (interested in using it on Sun's).
It appears that they have several programs 'ported' using XDOS and
they were willing to help 'port' programs for us. I got the strong
feelings that there is a lot of binary 'patching' going on in this
porting process. It definitely didn't sound like we could copy
something like flight simulator over to the Sun and run it after some
magical (i.e. automatic) transform by XDOS...of course, I am using
flight simulator as an example, since we wouldn't think of wasting
time playing games on an expensive Sun :-).

  -Todd Burkey      "A member of STdNET-The ST developers' Network"
   trb@stag.UUCP

df@nud.UUCP (Dale Farnsworth) (05/06/88)

Neil Forsyth (neil@cs.hw.ac.uk) writes:
=In article <2882@crash.cts.com> fred@pnet01.cts.com (Fred Brooks) writes:
=>What we really need is a product like 'XDOS'. XDOS takes a MS-DOS program
=>and converts it to 680X0 machine code. When this is done the program often
=>runs faster then the INTEL machine it was written for. This product is already
= 
= Interesting but I wonder what XDOS does about vector tables in the data
= segment since Intel and Motorola store longwords differently ie. reversed.
= And then there is always the clowns who pervert the idea by putting data in
= the code segment.

Yes, it has to maintain some data in the original Intel byte order.  There
is a performance hit, but it shouldn't be that difficult a programming task.

As to data in the code segment, this must be detected and accounted for.
It works.

-- 
Dale Farnsworth		602-438-3092	uunet!unisoft!nud!df

fred@pnet01.cts.com (Fred Brooks) (05/06/88)

neil@cs.hw.ac.uk (Neil Forsyth) writes:
>In article <2882@crash.cts.com> fred@pnet01.cts.com (Fred Brooks) writes:
>>What we really need is a product like 'XDOS'. XDOS takes a MS-DOS program
>>and converts it to 680X0 machine code. When this is done the program often
>>runs faster then the INTEL machine it was written for. This product is already
>>running on UN*X systems maybe someone will get an ST version.
>
>Interesting but I wonder what XDOS does about vector tables in the data
>segment since Intel and Motorola store longwords differently ie. reversed.
>And then there is always the clowns who pervert the idea by putting data in
>the code segment.
>
>-------------------------------------------------------------------------------
>"I think all right thinking people in this country are sick and tired of being
>told that ordinary decent people are fed up in this country with being sick and
>tired. I'm certainly not and I'm sick and tired of being told that I am!"
>- Monty Python - "I could be arguing in my spare time"
>
> Neil Forsyth                           JANET:  neil@uk.ac.hw.cs
> Dept. of Computer Science              ARPA:   neil@cs.hw.ac.uk
> Heriot-Watt University                 UUCP:   ..!ukc!cs.hw.ac.uk!neil
> Edinburgh
> Scotland
>-------------------------------------------------------------------------------

I think the idea would be a 8086 machine language compiler. If you think of
what a C or Modula-2 compiler does then expand that up to a complete
CPU chip language. I don't the data would be that hard to work with if
you had a configuration file for each program to help it compile to 680X0 
machine code. Of course you would have to do data flow and global check on
the process to keep things compiling correctly.

UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!fred
ARPA: crash!pnet01!fred@nosc.mil
INET: fred@pnet01.cts.com

sreeb@pnet01.cts.com (Ed Beers) (05/09/88)

df@nud.UUCP (Dale Farnsworth) writes:
>Neil Forsyth (neil@cs.hw.ac.uk) writes:
>=In article <2882@crash.cts.com> fred@pnet01.cts.com (Fred Brooks) writes:
>=>What we really need is a product like 'XDOS'. XDOS takes a MS-DOS program
>=>and converts it to 680X0 machine code. When this is done the program often
>=>runs faster then the INTEL machine it was written for. This product is already
>= 
>= Interesting but I wonder what XDOS does about vector tables in the data
>= segment since Intel and Motorola store longwords differently ie. reversed.
>= And then there is always the clowns who pervert the idea by putting data in
>= the code segment.
>
>Yes, it has to maintain some data in the original Intel byte order.  There
>is a performance hit, but it shouldn't be that difficult a programming task.
>
>As to data in the code segment, this must be detected and accounted for.
>It works.
>
>-- 
>Dale Farnsworth		602-438-3092	uunet!unisoft!nud!df

I think the real advantage to compiling the programs rather than interpreting
them like pc-ditto is that you can apply optimizing techniques.  I think that
xdos looks ahead and computes only those flags which will actually be used. 
An interpreter must compute all the flags although most are ignored.

UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!sreeb
ARPA: crash!pnet01!sreeb@nosc.mil
INET: sreeb@pnet01.cts.com