[comp.sys.acorn] Mac emulators.

AWilliams@melbourne.uucp (Alan Williams) (06/17/91)

In article <4549@stl.stc.co.uk> ajdh@stl.stc.co.uk (Andrew J D Hurley) writes:

Lots of stuff deleted, about lots of previous items about Mac disc readers, MS 
DOS and other stuff.

I comment on the item previous to this one.  It raised the point that a Mac 
emulator, rather like the PC Emulator would be a nice idea.  I don't know a lot 
about these sort of things but is strikes me as if there is a single rather serious 
difficulty involved in writing an emulator for a 680x0 processor: it has the 
opposit byte sex to an ARM.  That is to say if an ARM stores a 32 bit register to 
RAM it goes in low byte first, but if a 680x0 was to do this it would go in high 
byte first.  Thus an emulator would have to do byte reversals on all multi byte or 
word access.  This I guess might cause a performance reduction of maybe 30 or 
40 % relative to an emulator such as the 80188 one.

The up shot of this is that an emulator for a 680x0 MPU running on an ARM 
would be far too slow to be useful.  

Alan.

The opinions expressed here are my own and not necessarily those of Acorn.
 

gtoal@tardis.computer-science.edinburgh.ac.uk (06/18/91)

In article <125@melbourne.uucp> AWilliams@melbourne.uucp (Alan Williams) writes:
>The up shot of this is that an emulator for a 680x0 MPU running on an ARM 
>would be far too slow to be useful.  

Not that any such emulator exists of course, but if it did exist I might
imagine having heard that on a fast Arm3 it could have been clocked as
running at about half the speed of a Mac Classic.

All purely hypothetical of course.

G

bdb@cl.cam.ac.uk (Brian Brunswick) (06/18/91)

In article <125@melbourne.uucp> AWilliams@melbourne.uucp (Alan Williams) writes:
>The up shot of this is that an emulator for a 680x0 MPU running on an ARM 
>would be far too slow to be useful.  
(Because of the byte sex problem)

The answer to this is to eor all byte addresses with 3 - then word
and half-word accesses go quite nicely, apart from ones that are only
2 byte aligned. These can be fixed up nicely by using the fact that LDR
from a non aligned address rotates the word read.... This actually looked
quite reasonable, and I began to write a 68000 emulator, but I discovered that
STR doesn't rotate on non aligned stores :-( Oh well... perhaps my enthusiasm
will be restored some time in the future... the trouble is I'm always
very annoyed when I use macs because they lack stuff the arc has...
but then again I get annoyed with the arc too... The OS is so yucky inside!
Such is life.
Brian.Brunswick@uk.ac.cam.cl  Disclaimer.  Short sig rules!

s001532@kowande.bu.oz.au (Jeremy Lee) (06/19/91)

	Hell, what we REALLY need is a program that could intelligently convert 68000 (or later) code into ARM. You could even convert the calls to the window manager to RISC-OS calls, and even, god forbid, put the pull-down menus into pop-up versions.
	You could write it in a "Slow" language (ie anything slower than ARM code) as you'd only have to run it once. You could even do it in BASIC!

	Yes, I know about all the problems involved in accurately dissasembling a program, and matching Window manager to WIMP calls. (special modules could be written to provide mac-like SWI's) Perhaps hand tuning could be done.
	Look at it this way. The two systems do pretty much the same thing, and I have even taken a breif look through the little tech. information apple provides, and yes, IMH but naive O, it might even be done! The result would be code that runs faster than on a Mac, and maybe even multitasking too.

	Legally, you wouldn't be able to distribute any modified versions, but perhaps the law would allow a "list of corrections" that you could feed in with the mac version.

	I'm surprised no-one has done this for IBM yet.

	Of course, I might just be insane.

	Jeremy Lee