Path: utzoo!attcan!uunet!husc6!bbn!apple!sun-barr!ames!purdue!haven!uvaarpa!hudson!bessel.acc.Virginia.EDU!gl8f
From: gl8f@bessel.acc.Virginia.EDU (Greg Lindahl)
Newsgroups: comp.sys.atari.st
Subject: Re: Misc. questions---16Mhz answer
Message-ID: <1491@hudson.acc.virginia.edu>
Date: 12 May 89 03:33:47 GMT
References: <890511022432.694645@PCO-MULTICS.HBI.HONEYWELL.COM> <1989May11.204205.26151@gpu.utcs.utoronto.ca>
Sender: news@hudson.acc.virginia.edu
Reply-To: gl8f@bessel.acc.Virginia.EDU (Greg Lindahl)
Organization: Dept. of Astronomy, University of Virginia
Lines: 18

In article <1989May11.204205.26151@gpu.utcs.utoronto.ca> lharris@gpu.utcs.UUCP (Leonard Harris) writes:

> The main problem with caching is compatibility - a lot of st software
> will simply not run on a cached machine.

This depends on the cache. PC Klones that have caches must allow self-modifying
code, because apparently lots of PC programs are self-modifying. 68000 programs
aren't supposed to be; if they are, you have to fiddle with the cache when you
try to run on a 68020. Companies with code that won't run on the TT will be
scrambling to fix it, if the TT is ever released.

I'd like more details on how the cache is implemented, and some performance
numbers for all the speedup boards. Even a non-cached board should speed FP
because software FP involves a lot of integer multiplies and divides.

------
Greg Lindahl       |  Welcome to Mars, Earthling. We Martians don't like
gl8f@virginia.edu  |  illegal aliens, so we'll just have to deport you.