home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / hardware / 26681 < prev    next >
Encoding:
Text File  |  1993-01-23  |  2.4 KB  |  47 lines
  1. Newsgroups: comp.sys.mac.hardware
  2. Path: sparky!uunet!usc!sdd.hp.com!decwrl!adobe!macne035.boston.us.adobe.com!user
  3. From: zisk@adobe.com (Stephen Zisk)
  4. Subject: Re: Motorola's 68060 for the Mac
  5. Message-ID: <zisk-220193151809@macne035.boston.us.adobe.com>
  6. Followup-To: comp.sys.mac.hardware
  7. Sender: usenet@adobe.com (USENET NEWS)
  8. Organization: Adobe Systems Incorporated
  9. References: <D2150056.o6gh64@erics.infoserv.com> <1993Jan22.054617.25775@bilby.cs.uwa.edu.au>
  10. Date: Fri, 22 Jan 1993 20:30:26 GMT
  11. Lines: 34
  12.  
  13. In article <1993Jan22.054617.25775@bilby.cs.uwa.edu.au>,
  14. quinn@cs.uwa.edu.au (Quinn) wrote:
  15. > The Lisa had an 68000 and implemented virtual memory but only for 
  16. > code segments.  Therefore I assume you can always manage to restart
  17. > instruction fetches on the 68000.  I guess that putting data in
  18. > code segments was frowned upon (and didn't work).
  19.  
  20. No, you cannot restart from failed instruction fetches. This is a
  21. common cause of bus errors. The real problem with the 68000, which was
  22. fixed by the 68010, is that some internal register state is not saved
  23. to the stack on a bus error. This means you can not recover if some
  24. calculation was ongoing when the bus error occured.
  25.  
  26. What you can do is a slimy bit of probing by making the segment calls
  27. include code surrounded by a bunch of no-ops, so that there are no
  28. ongoing calculations. You can even write a compiler to do this on long
  29. pointer references, so that the system code recovering from a bus fault
  30. can page in the right stuff, satisfiy the hardware translators in the
  31. MMU (after all, you don't have to use a 68851 as MMU, you can roll your
  32. own), and start again at the right spot.
  33.  
  34. The even uglier trick we used for our "high-performance" machines at a
  35. previous company was to have primary/secondary 68Ks, where the WAIT
  36. signal on the primary 68K becomes asserted on bus error, the secondary
  37. 68K goes off and satisfies the fault, and then WAIT is unasserted on
  38. the primary 68K and it continues on its way, not even knowing a bus
  39. error occured. This was an expensive solution when 68Ks were $200 a pop,
  40. but would be very cheap these days at < $5.
  41.  
  42. Stephen Zisk (zisk@adobe.com)  Disclaimer: These are my personal views
  43. Adobe Systems Incorporated     and do not represent the position of
  44. Eastern Regional Office        Adobe Systems Incorporated.
  45. 24 New England Exec. Park
  46. Burlington, MA 01803           They pay me but they don't muzzle me!
  47.