Path: utzoo!attcan!uunet!comp.vuw.ac.nz!virtue!canterbury.ac.nz!phys169 From: phys169@canterbury.ac.nz Newsgroups: comp.sys.ibm.pc.misc Subject: Re: Difference between a 386 and a 386sx Message-ID: <1990Sep21.091806.9200@canterbury.ac.nz> Date: 22 Sep 90 07:21:35 GMT References: <1990Sep16.194605.11968@ecn.purdue.edu> <4383@bwdls58.UUCP> <14110@mentor.cc.purdue.edu> Followup-To: comp.sys.ibm.pc.misc Organization: University of Canterbury Lines: 21 In article , wayne@dsndata.uucp (Wayne Schlitt) writes: > In article <14110@mentor.cc.purdue.edu> edgincd2@mentor.cc.purdue.edu (Chris Edgington *Computer Science Major*) writes: >> >> If you wanted to determine whether or not the chip you are using is a 386 >> or a 386sx, couldn't you just execute some 32 bit intructions and time the >> number of machine cycles it takes to execute them. >> > > no, because you can't tell if the extra time is because of slow memory > causing wait states, or if the smaller bus is causing the wait states. > all you know is that the time to do something is slower than the > theoretical maximum. > How about reading a lot of 32-bit numbers from random places in memory (to foil any caching system), half of them aligned on 32-bit boundaries, the others not, and test for a significant difference? By the way, does anyone have a ready-made bit of code that checks the cache size and effectiveness? Mark Aitchison, Physics, University of Canterbury, New Zealand.