Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!mcguire
From: mcguire@cs.tamu.edu (Tim McGuire)
Newsgroups: comp.sys.next
Subject: Re: in Time, again
Summary: Let's not panic, folks.....
Message-ID: <9008@helios.TAMU.EDU>
Date: 12 Oct 90 02:23:49 GMT
References: <8990@helios.TAMU.EDU> <332@casbah.acns.nwu.edu>
Sender: usenet@helios.TAMU.EDU
Organization: Computer Science Department, Texas A&M University
Lines: 28

In article <332@casbah.acns.nwu.edu> galanter@casbah.acns.nwu.edu (Philip Galanter) writes:
>>>They tell me that the first large batch of 68040s had a bug which did not
>>>affect any of the NeXT software because mach does not use the affected 
>>>opcode.  
>
>I have heard this form various NeXT folks as well, but it sure sounds goofy.
>So what instruction could possibly be so expendable, by NeXT _and_ any other
>developer/development system/compiler?  Maybe some kind of low level thing
>that _only_ the OS should be dealing with, like virtual memory paging or
>something?  Anybody out there from NeXT have the technical info that would
>help the above make sense?

I started this panic, so let me see if I can calm it down some.  I still
haven't heard what the problem is exactly, so I may be wrong, but let me
give you the following scenario:

Many moons ago, person X had a machine with a Z80 cpu.  This chip had a 
very nice set of opcodes for port i/o.  But X's machine didn't use them, 
since it had *memory mapped* i/o.  I assume that the only way the port 
opcodes would be necessary is if X changed the cpu over to another 
motherboard.  So, it the bug in question only affects hardware that the 
NeXT (due to its architecture) will never use, there will be no problem 
unless you plan on pulling the cpu chip and putting it in some other machine.

Now, does this sound reasonable?  

Tim McGuire
mcguire@cs.tamu.edu