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