Xref: utzoo comp.sys.apple:23812 comp.sys.apple2:355
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!NISC.SRI.COM!cwilson
From: cwilson@NISC.SRI.COM (Chan Wilson)
Newsgroups: comp.sys.apple,comp.sys.apple2
Subject: Re: Accepting the Mac (was Re: More Macweek Rumors)
Message-ID: <14550@fs2.NISC.SRI.COM>
Date: 22 Mar 90 21:11:38 GMT
References: <1848@crash.cts.com> <18491@boulder.Colorado.EDU> <12667@thorin.cs.unc.edu> <1990Mar17.105403.17776@spectre.ccsf.caltech.edu> <14437@fs2.NISC.SRI.COM> <1990Mar20.154757.6064@spectre.ccsf.caltech.edu>
Reply-To: cwilson@NISC.SRI.COM (Chan Wilson)
Followup-To: comp.sys.apple
Organization: Network Info Systems Ctr., SRI Intl., Menlo Park, CA.
Lines: 28

In article <1990Mar20.154757.6064@spectre.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes:
>cwilson@NISC.SRI.COM (Chan Wilson) writes:
>
>>Hmm.  One wonders how hard it would be to write a converter betwixt 65K
>>and 68K assembler.
>
>Don't bother. C compilers are supposed to do this for you.

That's not very helpful if you don't program in C, now is it?  Besides, 
that'd be a good project for this 68000 co-processor board I'm looking at..

>Software emulation of CPUs is a bitch and is a real performance waster, unless
>you're primarily after the occasional convienience. Most of the time it isn't
>worth the trouble and cross-development systems work much better.

Now, I never said that I was going to emulate a 68K cpu in software.  That
would be a bitch.  I'm talking about translating the source code somehow.
(not that it would be any easier, mind you...)

>Todd Whitesel
>toddpw @ tybalt.caltech.edu

--Chan
			   ................
    Chan Wilson -- cwilson@nisc.sri.com <!> I don't speak for SRI.
Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu
  "And now, the penguin on top of the television set will explode."
			   ................