Path: utzoo!mnetor!uunet!husc6!mailrus!ames!ucsd!sdcsvax!ucsdhub!jack!crash!pnet01!sreeb
From: sreeb@pnet01.cts.com (Ed Beers)
Newsgroups: comp.sys.atari.st
Subject: Re: PC-Ditto speed "XDOS"
Message-ID: <2939@crash.cts.com>
Date: 8 May 88 18:56:09 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 29

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