jaa@sppy00.UUCP (Jeff Anderson) (09/17/90)
In article <1990Sep16.194605.11968@ecn.purdue.edu> tlhilde@ecn.purdue.edu (Troy Hildebrand) writes: > >Can anybody help me with the difference between a 80386 and a 80386sx? >I have been warned _not_ to go with a 386sx when purchasing a computer, >no matter what the cost difference is. What exactly is the difference >between an 386 based motherboard and an 386sx motherboard? This is in >regards to third party motherboards. Are there any particular features >which distinguish the 386 and 386sx boards? 386sx boards do not support 32 bit bussing. The processor supports 32 bit instructions, but the memory buss (for example) is only 16 bits. A sx is like a 286 with 32 bit instructions and more speed. ------------------------------------------------------------------------------ Jeff Anderson jaa@sppy00.UUCP Online Computer Library Center (OCLC) killer!osu-cis!sppy00!jaa 614-764-6222 ------------------------------------------------------------------------------
msandifo@ucs.adelaide.edu.au (Martin Sandiford) (09/18/90)
From article <935@sppy00.UUCP>, by jaa@sppy00.UUCP (Jeff Anderson): > In article <1990Sep16.194605.11968@ecn.purdue.edu> tlhilde@ecn.purdue.edu (Troy Hildebrand) writes: >>I have been warned _not_ to go with a 386sx when purchasing a computer, This would seem to be a little unreasonable to me. Maybe this person has an axe to grind? > 386sx boards do not support 32 bit bussing. The processor supports 32 bit > instructions, but the memory buss (for example) is only 16 bits. A sx is like > a 286 with 32 bit instructions and more speed. It would be more correct to say a 386sx is like a 386dx with a 24 bit bus and 16 bit data path. Martin.
wsinpdb@svin02.info.win.tue.nl (Paul de Bra) (09/18/90)
In article <1477@sirius.ucs.adelaide.edu.au> msandifo@ucs.adelaide.edu.au (Martin Sandiford) writes: >From article <935@sppy00.UUCP>, by jaa@sppy00.UUCP (Jeff Anderson): >... >It would be more correct to say a 386sx is like a 386dx with a 24 bit bus and >16 bit data path. This suggests that a way to distinguish a 386dx from a 386sx in software would be to put some value in existing memory at address 0x00xxxxxx and read it from address 0x01xxxxxx. If it comes out the same you would be running on a 386sx (not having the upper 8 bits of address bus), otherwise a 386dx. Can anyone confirm whether this works? (you need to be in real mode i guess, which is usually what you want anyway) Paul. (debra@research.att.com)
poffen@sj.ate.slb.com (Russell Poffenberger) (09/18/90)
In article <935@sppy00.UUCP> jaa@sppy00.UUCP (Jeff Anderson) writes: >In article <1990Sep16.194605.11968@ecn.purdue.edu> tlhilde@ecn.purdue.edu (Troy Hildebrand) writes: >> >>Can anybody help me with the difference between a 80386 and a 80386sx? >>I have been warned _not_ to go with a 386sx when purchasing a computer, >>no matter what the cost difference is. What exactly is the difference >>between an 386 based motherboard and an 386sx motherboard? This is in >>regards to third party motherboards. Are there any particular features >>which distinguish the 386 and 386sx boards? > >386sx boards do not support 32 bit bussing. The processor supports 32 bit >instructions, but the memory buss (for example) is only 16 bits. A sx is like >a 286 with 32 bit instructions and more speed. > Don't confuse the 286 and 386sx, they are quite different. Basically the 386sx is the SAME CPU as the 386(dx), except that the DATA bus is only 16 bits. This means that when it needs a 32 bit instruction or 32 bit data, it takes two bus cycles to do it. I also think that its address bus is limited (at least 16 Mbytes). Other than that, it can run ALL 386 programs fine, just slower. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
pnl@hpfinote.HP.COM (Peter Lim) (09/19/90)
386sx is a pure 16 bit version of the 386. 100% compatible software-wise, ie. supports all 386 instructions. However, the 16 bit bus means at least twice as slow (for same MHz) in all I/O including memory read/write. Fastest version available is 16 MHz (or may be there are some 20 MHz ones). Whereas the 386 can run from 16 MHz to 33 MHz. > instructions, but the memory buss (for example) is only 16 bits. A sx is like > a 286 with 32 bit instructions and more speed. > This is generally not correct. In most situation, a 286 machine will run faster than a 386sx machine (at same MHz). But 386sx can run 386 specific software. So, the 386sx is a dead end in speed but has a bright future in term of software compatibility now that we are seeing more and more 386 specific programs coming out. Regards, ## Life is fast enough as it is ........ Peter Lim. ## .... DON'T PUSH IT !! >>>-------, ########################################### : E-mail: plim@hpsgwg.HP.COM Snail-mail: Hewlett Packard Singapore, : Tel: (065)-279-2289 (ICDS, ICS) | Telnet: 520-2289 1150 Depot Road, __\@/__ ... also at: pnl@hpfipnl.HP.COM Singapore 0410. SPLAT ! #include <standard_disclaimer.hpp>
edgincd2@mentor.cc.purdue.edu (Chris Edgington *Computer Science Major*) (09/19/90)
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. Chris Edgington
jims@pro-berks.cts.com (Jim Sloan) (09/19/90)
In-Reply-To: message from tlhilde@ecn.purdue.edu The 386SX is a 32 bit processor that has ONLY a 16 bit data path. The reason many people say not to go with the SX is that any extra memory not on the motherboard (sheesh for that matter even motherboard memory) is only 16 bit memory, instead of 32-bit. Phoenix Systems Software P.O. Box 2525 West Lawn, PA 19609 c/o Jim Sloan My employer(s) is/are my customer(s). I cannot represent their views.
rlr@bbt.UUCP (rader) (09/19/90)
Mark Lord writes: >Troy Hildebrand writes: >> >>Can anybody help me with the difference between a 80386 and a 80386sx? >>I have been warned _not_ to go with a 386sx when purchasing a computer, > >Absolute foolishness.. The ONLY difference you care about, >is that a 386sx is slower than a 386dx. Other than that, they behave >identically, and each will run any existing software for the 80386. > >The 386sx is slower due to a narrower data path to memory, requiring >more cycles to move the same amount of data around. It is also slower >because Intel does not yet sample this chip at the same speeds as the 386dx, >which results in 386sx systems running at 16Mhz/20Mhz, instead of 25/33 Mhz. > Just as an aside, the 386sx relationship to the 386dx is a direct parallel to the 8088 relationship to the 8086. That is, the 386sx data bus is 16 bits while the 386dx data bus is a full 32 bits. 8088 data bus is 8 bits while the 8086 data bus is 16 bits. The reason for the major cost differential? The surrounding motherboard hardware is much less complex for the 386sx. However, thanks go to Mark Lord. I was unaware that no 386 software distiguishes between the 386sx or dx. This should ease my financial woes in my unavoidable home PC upgrade (from an old PC clone :( ). -- ron rader, jr rlr%bbt@rti.rti.org = Opinions are my own and do not | | i gotta six- rlr%bbt$rti.rti.org@CUNYVM = necessarily reflect those of | | pack, & nothin' to do ...!mcnc!rti!bbt!rlr = BroadBand Tech. (SO THERE!) *** Punk ain't no religious cult, punk means thinking for yourself - DKs ***
mlord@bwdls58.bnr.ca (Mark Lord) (09/19/90)
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. Good in theory.. but cannot be done. In order to "time" them, you need to know the exact CPU clock rate, which is another unknown. Also, caches and stuff can affect this. Ahha you say, so why not use 32-bit instructions that do not access memory? Simple reason: that would not tell you anything, since the 386sx IS a 32-bit processor inside the chip. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
mlord@bwdls58.bnr.ca (Mark Lord) (09/19/90)
>This suggests that a way to distinguish a 386dx from a 386sx in software >would be to put some value in existing memory at address 0x00xxxxxx >and read it from address 0x01xxxxxx. If it comes out the same you would >be running on a 386sx (not having the upper 8 bits of address bus), >otherwise a 386dx. But not many machines have physical memory in the hundreds of megabytes ranges.. so regrettably, I doubt that this would work in practice. Use virtual memory you say? Well.. in that case a 386sx will do the exact same internal translation as a 386dx, producing no observable differences either. Better luck next time. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
rcollins@altos86.Altos.COM (Robert Collins) (09/19/90)
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. > I think what you mean to say is to execute some bus-bound instructions, and time the execution. If you have a purely CPU-bound instruction, like BSF EAX, ESI, then the execution time is the same on SX and DX, given the same clock speeds, regardless of the fact that this is a 32-bit instruction. So, to answer the question I think you were asking: No. Many early 386 machines were implemented using a 286-designed motherboard. Therefore, these machines had 16-bit buses. But regardless of this fact, some buses run at 8Mhz, some at 8.33Mhz, some at 10Mhz, and others at 11Mhz. So, this would hardly be a fail safe way to tell the SX from DX. -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356
wayne@dsndata.uucp (Wayne Schlitt) (09/20/90)
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 cant 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. -wayne
torkil@Pacesetter.COM (Torkil Hammer) (09/20/90)
In article <1477@sirius.ucs.adelaide.edu.au> msandifo@ucs.adelaide.edu.au (Martin Sandiford) writes: # From article <935@sppy00.UUCP>, by jaa@sppy00.UUCP (Jeff Anderson): # > In article <1990Sep16.194605.11968@ecn.purdue.edu> tlhilde@ecn.purdue.edu (Troy Hildebrand) writes: # >>I have been warned _not_ to go with a 386sx when purchasing a computer, # # This would seem to be a little unreasonable to me. Maybe this person has # an axe to grind? I remember reading in BYTE some months ago a warning against running unix and lookalikes (SCO Xenix) on 386SX's. HOWEVER, the text warned not against the 386sx per se, but against cheap computers with unstable motherboards, second rate DRAMs not living up to the specs, and trying to run a 386SX at 20 MHz with just 1 MB of ram and 30 MB or so of disk.. The warning against el cheapos makes sense, as a UNIX crash is a lot messier to recover from than a DOS crash, and as they recommend 4-8 MB of ram and something like 80 MB of disk. There were a lot of cheapos made with 386SX's, but not a lot with the more expensive DX. So there should be no problems with a respectable 386SX running at 16 MHz with enough 80 ns ram and enough disk for the application. The SX is software compatible with the DX, and a SX system has a few advantages over the DX: The smaller bus and no cache leaves more room for goodies such as 8 MB on the motherboard and 8 expansion slots, and the simpler board is less likely to have design errors on it. There is also the cheaper price for the same software capability. The SX is slower than the DX, which is the only tradeoff - or what? Torkil Hammer
rcollins@altos86.Altos.COM (Robert Collins) (09/20/90)
In article <4387@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: > >Good in theory.. but cannot be done. In order to "time" them, >you need to know the exact CPU clock rate, which is another unknown. It's easy to determine CPU speed. I've had an algorithm to do this for over a year. It works on 8086, 186, 286, 386SX, 386DX, 486 at any speed up to (over) 50Mhz. Though, I haven't tried it on a 50Mhz CPU (we won't get any until next quarter), I have tried it on 386's and 486's up to 33Mhz in each case. The algorithm is accurate to 2 decimal places. The algorithm is independent of, and isn't affected by cache or memory speed. It seems to me that you claim to have a generic algorithm to determine an 386SX from a 386DX. I'll make you a deal. If you post yours (provided it works), I'll post mine! -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356
poffen@sj.ate.slb.com (Russell Poffenberger) (09/21/90)
In article <4388@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >>This suggests that a way to distinguish a 386dx from a 386sx in software >>would be to put some value in existing memory at address 0x00xxxxxx >>and read it from address 0x01xxxxxx. If it comes out the same you would >>be running on a 386sx (not having the upper 8 bits of address bus), >>otherwise a 386dx. > >But not many machines have physical memory in the hundreds of megabytes >ranges.. so regrettably, I doubt that this would work in practice. > >Use virtual memory you say? Well.. in that case a 386sx will do the >exact same internal translation as a 386dx, producing no observable >differences either. Better luck next time. In addition, I think you would have to be in protected mode. This complicates things. In real mode, I believe the addresses "wrap around" at 1Mb. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
poffen@sj.ate.slb.com (Russell Poffenberger) (09/21/90)
In article <1990Sep19.225310.15663@Pacesetter.COM> torkil@Pacesetter.COM (Torkil Hammer) writes: >In article <1477@sirius.ucs.adelaide.edu.au> msandifo@ucs.adelaide.edu.au (Martin Sandiford) writes: ># From article <935@sppy00.UUCP>, by jaa@sppy00.UUCP (Jeff Anderson): ># > In article <1990Sep16.194605.11968@ecn.purdue.edu> tlhilde@ecn.purdue.edu (Troy Hildebrand) writes: ># >>I have been warned _not_ to go with a 386sx when purchasing a computer, ># ># This would seem to be a little unreasonable to me. Maybe this person has ># an axe to grind? > >I remember reading in BYTE some months ago a warning against running >unix and lookalikes (SCO Xenix) on 386SX's. HOWEVER, the text warned not >against the 386sx per se, but against cheap computers with unstable >motherboards, second rate DRAMs not living up to the specs, and trying >to run a 386SX at 20 MHz with just 1 MB of ram and 30 MB or so of disk.. > >The warning against el cheapos makes sense, as a UNIX crash is a lot messier >to recover from than a DOS crash, and as they recommend 4-8 MB of ram >and something like 80 MB of disk. There were a lot of cheapos made with >386SX's, but not a lot with the more expensive DX. > >So there should be no problems with a respectable 386SX running at 16 MHz >with enough 80 ns ram and enough disk for the application. The SX is >software compatible with the DX, and a SX system has a few advantages over >the DX: > >The smaller bus and no cache leaves more room for goodies such as 8 MB on >the motherboard and 8 expansion slots, and the simpler board is less likely >to have design errors on it. There is also the cheaper price for the same >software capability. > >The SX is slower than the DX, which is the only tradeoff - or what? > You can get good dx motherboards with this kind of expandability. I have a 25Mhz 386DX (no cache), with 8Mb of ram on the motherboard (SIMM's) and has 8 expansion slots. When buying an SX, the speed is affected by two factors.. 1.) All 32 bit accesses take 2 memory cycles. 2.) The fastest SX Intel now makes is 20Mhz, whereas the slowest DX is 25Mhz. (Yes, Intel used to make slower DX's, but according to my knowledge, not anymore.) The only real advantage I see of an SX over a DX, given well constructed hardware, is the fact that RAM only need be upgraded in increments of 16 bits. This means 512K at a time for 256K chips, or 2Mb at a time for 1M chips. In a DX, you must use 32 bit increments, meaning 1Mb for 256K chips, or 4Mb for 1M chips. If you have a DX that uses 1M chips, and you want only 2Mb more, you must shell out more $$ and go with 4Mb. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
jimf@idayton.intel.com (Jim Fister) (09/21/90)
Though I couldn't tell you myself how to do it (too many other books to read) I do know of a program that will happily tell you what y'all have. It's called QAPlus, and it's put out by DiagSoft in Scotts Valley, CA. Not only does it give a good list of your PC's internals, but it can test them to death. The program found some video errors that no other program found as far as I remember. I'd consider it a must-have for people with PC's. Standard disclaimers apply; I speak for myself and my company breathes a sigh of relief. Greetings from the Rocking Metropolis. Oh: DiagSoft Inc. 5615 Scotts Valley Dr. Suite 140 Scotts Valley, CA 95066
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (09/21/90)
In article <1990Sep20.185214.780@sj.ate.slb.com> poffen@sj.ate.slb.com (Russell Poffenberger) writes: >In article <4388@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >>>This suggests that a way to distinguish a 386dx from a 386sx in software >>>would be to put some value in existing memory at address 0x00xxxxxx >>>and read it from address 0x01xxxxxx. If it comes out the same you would >>>be running on a 386sx (not having the upper 8 bits of address bus), >>>otherwise a 386dx. and numerous other (farfetched) ways to distinguish an SX from a DX deleted. OK, now, supposing one of these ways actually works, what are you going to do with this information? <sarcastic mode on> Pop up a window that congratulates/defames the owner for having one over the other. Repeat after me. A 386 is a 386 is a 386 is a 386..... No matter if it's an SX or a full fledged DX, one is just a little slower than the other. Jeez, next you guys'll be wanting some reliable way to tell if a Turbo XT clone is an 8mhz or a 10mhz board when the turbo switch is set to 4.77 mhz. <sarcastic mode off> -- Kaleb Keithley Jet Propeller Labs kaleb@thyme.jpl.nasa.gov "So that's what an invisible barrier looks like!"
pnl@hpfinote.HP.COM (Peter Lim) (09/22/90)
Well, how about this. Do some 16 bit and some 32 bit access from the
CPU ? Theorectically, if you can isolate the memory access time in your
test, then on a 386DX, there should be no difference between the two
types of accesses. Whereas, a 386SX would do better at 16 bit accesses ?
Will this work ?
Regards, ## Life is fast enough as it is ........
Peter Lim. ## .... DON'T PUSH IT !! >>>-------,
########################################### :
E-mail: plim@hpsgwg.HP.COM Snail-mail: Hewlett Packard Singapore, :
Tel: (065)-279-2289 (ICDS, ICS) |
Telnet: 520-2289 1150 Depot Road, __\@/__
... also at: pnl@hpfipnl.HP.COM Singapore 0410. SPLAT !
#include <standard_disclaimer.hpp>phys169@canterbury.ac.nz (09/22/90)
In article <WAYNE.90Sep19180242@dsndata.uucp>, 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.
mlord@bwdls58.bnr.ca (Mark Lord) (09/23/90)
In article <1990Sep21.002015.1201@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes: >>In article <4388@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >>>>This suggests that a way to distinguish a 386dx from a 386sx in software >>>>would be to put some value in existing memory at address 0x00xxxxxx >>>>and read it from address 0x01xxxxxx. If it comes out the same you would >>>>be running on a 386sx (not having the upper 8 bits of address bus), >>>>otherwise a 386dx. > >and numerous other (farfetched) ways to distinguish an SX from a DX deleted. Kaleb, and others, please be more careful to assosiate the proper quotes with the proper people. The above text is NOT mine. For that matter, it describes yet another method which will not work. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
mlord@bwdls58.bnr.ca (Mark Lord) (09/23/90)
In article <4093@altos86.Altos.COM> rcollins@altos86.UUCP (Robert Collins) writes: >In article <4387@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >> >>Good in theory.. but cannot be done. In order to "time" them, >>you need to know the exact CPU clock rate, which is another unknown. > >It's easy to determine CPU speed. I've had an algorithm to do this for >over a year. It works on 8086, 186, 286, 386SX, 386DX, 486 at any speed >up to (over) 50Mhz. Though, I haven't tried it on a 50Mhz CPU (we won't >get any until next quarter), I have tried it on 386's and 486's up to >33Mhz in each case. The algorithm is accurate to 2 decimal places. > >The algorithm is independent of, and isn't affected by cache or memory >speed. Impressive. I have yet to see a program which correctly informs me of the 18Mhz speed of my 386sx. Congratulations! But I'm still doubtful of the applicability of this to determining the exact CPU type, as in that case the bus-width, caches, wait states etc.. all interfere with any timing-based method of cpu identification. Remember, even a 386dx could be talking to physical 16-bit memory. Not common, I admit, but quite possible. I will not be posting any code to solve this problem, because I don't WANT any software to be able to tell the difference. I LIKE being able to run ALL 386 programs. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
bob@menno.bethelks.edu (Robert Schwartz) (09/23/90)
OK, so nobody can find a way to tell a difference. My question is this: Has anyone tried to run Mathematica on a 386sx? According to someone from Wolfram who spoke to me, Mathematica will NOT run on an SX. Personally, I wonder if that's true. Since there seems to be no way to tell the difference, it should run, right? -- Robert Schwartz email: bob@menno.bethelks.edu Dept. of Computer Science ...ncrlnk!ncrwic!menno!bob Bethel College ...texbell!ncrwic!menno!bob N. Newton, KS 67117
james@bigtex.cactus.org (James Van Artsdalen) (09/23/90)
In <4387@bwdls58.UUCP>, mlord@bwdls58.bnr.ca (Mark Lord) wrote: > In article <14110@mentor.cc.purdue.edu> edgincd2@mentor.cc.purdue.edu 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. > Good in theory.. but cannot be done. In order to "time" them, > you need to know the exact CPU clock rate, which is another unknown. Why is it that you must know the CPU rate? > Also, caches and stuff can affect this. True enough. But perhaps a cache would make the problem easier by eliminating page misses and wait states... > Ahha you say, so why not use 32-bit instructions that do not access > memory? Simple reason: that would not tell you anything, since the > 386sx IS a 32-bit processor inside the chip. OK, then let's use 32 bit instructions that *do* access memory. On an SX they'll take long because it takes two cycles. So one could do a "rep stosw" then a "rep stosd" and measure the ratio of time between the two... -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
mlord@bwdls58.bnr.ca (Mark Lord) (09/24/90)
In article <47642@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: > >OK, then let's use 32 bit instructions that *do* access memory. On an >SX they'll take long because it takes two cycles. So one could do a >"rep stosw" then a "rep stosd" and measure the ratio of time between >the two... This is a clever idea, that might work most of the time. However, caches could easily have an effect on this, and at best, this method will measure the memory/bus width, rather than the cpu type. A 386dx CAN be talking to 16-bit wide memory, it's just that most of us wouldn't bother with such a setup. But 16-bit memory cards provide cheap (and slow) memory for those who need it. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
rgreene@pnet01.cts.com (Robert Greene) (09/25/90)
bob@menno.UUCP (Robert Schwartz) writes: > OK, so nobody can find a way to tell a difference. My question is this: > Has anyone tried to run Mathematica on a 386sx? According to someone > from Wolfram who spoke to me, Mathematica will NOT run on an SX. > Personally, I wonder if that's true. Since there seems to be no way to > tell the difference, it should run, right? According to Novell, their 386 server package will not run on an SX either. UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!rgreene ARPA: crash!pnet01!rgreene@nosc.mil INET: rgreene@pnet01.cts.com
b460nom@utarlg.utarl.edu (S. Nomura) (09/25/90)
In article <102@menno.bethelks.edu>, bob@menno.bethelks.edu (Robert Schwartz) writes... > > Anyone tried to run Mathematica on a 386sx? According to someone from > Wolfram who spoke to me, Mathematica will NOT run on an SX. Mathematica runs on a 386sx without hitch. Period. -- S. Nomura Department of Mechanical Engineering University of Texas at Arlington
rcollins@altos86.Altos.COM (Robert Collins) (09/25/90)
In article <4405@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: > >Impressive. I have yet to see a program which correctly informs me of >the 18Mhz speed of my 386sx. Congratulations! > I put a 30Mhz crystal in a '486 and it says 30Mhz. I'm sure it will work @ 18Mhz as well. >But I'm still doubtful of the applicability of this to determining the >exact CPU type, as in that case the bus-width, caches, wait states etc.. >all interfere with any timing-based method of cpu identification. > I'm sorry if I implied I used timing as a means to determine CPU type... I don't. I determine the CPU type, then time it. -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356
rcollins@altos86.Altos.COM (Robert Collins) (09/25/90)
In article <47642@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >> Ahha you say, so why not use 32-bit instructions that do not access >> memory? Simple reason: that would not tell you anything, since the >> 386sx IS a 32-bit processor inside the chip. > >OK, then let's use 32 bit instructions that *do* access memory. On an >SX they'll take long because it takes two cycles. Yes, and they will take "long" on a DX with a 16-bit bus...as many early '386's had. >So one could do a >"rep stosw" then a "rep stosd" and measure the ratio of time between >the two... Oh really? What if the memory was all across the I/O bus? Shoot, it seems that the speed of the I/O bus would shadow the results of this test. -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356
ted@helios.ucsc.edu (Ted Cantrall) (09/25/90)
In article <4088@altos86.Altos.COM> rcollins@altos86.UUCP (Robert Collins) 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. The internal, CPU-bound instructions would time out the same for the 386SX and for the 386DX (assumption #1). The external, bus-bound instructions would be faster on teh 386DX than on the 386SX (assumption #2). (seems safe...;-) The actual time used by any set of instructions is dependant on an unknown system clock rate (assumption #3). (seems even safer!) Possible solution: Run a set of CPU-bound instructions and a set of bus- bound instructions and compare the times. The ratio sould give a consistant, reliable difference. (I just have no idea how to go about timing such things) -ted- ------------------------------------------------------------------------------- ted@helios.ucsc.edu |"He has showed you, O man, what is good; and what does the W (408)459-2110 |Lord require of you but to do justice and to love kindness H (408)423-2444 |and to walk humbly with your God?" Micah 6:8 (RSV)
jsp@milton.biostr.washington.edu (Jeff Prothero) (09/27/90)
Am I just dense, or what? There are lots of programs around that distinguish DX from SX machines. Most of them just seem to check the length of the prefetch queue. Code to do this has been posted. Has something happened to break this approach? Why the agonizing?
michaelk@copper.WR.TEK.COM (Michael D. Kersenbrock) (09/27/90)
Yes, the DX has a 16-byte prefetch queue, although my SX book doesn't label the depth. In any case, another way is by looking at the DX register upon reset. (how you get it reset is left as an exercise for the reader). The byte nibble is 03H in a DX and 023H in a SX. The lower byte is an unsigned 8-bit number giving the rev. level (although its not guaranteed to increment with each rev, or that there will be a uniform sequence). Still don't really know what knowing this buys me... :-) -- Mike Kersenbrock Tektronix Logic Analyzers Division michaelk@copper.WR.TEK.COM Aloha, Oregon
rcollins@altos86.Altos.COM (Robert Collins) (09/28/90)
(I tried to send this privately, via email, but it bounced...so I'll post it). JSP @ washington.edu wrote: > > Am I just dense, or what? There are lots of programs >around that distinguish DX from SX machines. Most of >them just seem to check the length of the prefetch >queue. Code to do this has been posted. Has something >happened to break this approach? Why the agonizing? Just a friendly note in case you don't know much about '386's...But the SX and DX have the same size prefetch queue. This can be confirmed by simply looking in the SX and DX hardware reference manuals (respectively) and verify that both have 16-byte prefetch queues. So code that checks the length of the prefetch queue isn't going to determine anything... except the length of the prefetch queue. Yes, there was code posted a while back that used this approach. Actually if you analyze this code, and provided a reasonable knowledge of how the internals of the CPU works, it is pretty clear that the posted code doesn't work...even to tell the size of the prefetch queue. What the poster failed to realize is that there is pipelining inside the CPU. The bus unit is fetching while the CPU doesn't need the bus. The decode unit is decoding in parallel with the execution unit. When the execution unit finishes, it signals the bus unit that it needs to store a value. (I got ahead of myself by not explaining that the posted algorithm attempted to modify code just outside the bounds of the prefetch queue, and therefore determine its size.) Finally when the bus unit is signaled, it stores the data. If that data is outside the prefetch queue, then the modified code gets executed. There is a very serious problem with this approach. What happens when you reduce wait states, turn up the clock, and add a cache? The bus unit gets control at a different time in the time line of CPU clocks. Therefore, this approach fails. This can easily be verified if you have access to various computers from SX to DX, 16, 25, 33Mhz with and without caches. Take that algorithm and see if it works. It doesn't, it miserably fails. (Yes I tried it.) Since the SX and DX have the same size prefetch queue anyways, the poster shouldn't have claimed his algorithm worked based on the principal of prefetch size. In fact, if the algorithm worked at all, it wasn't because of prefetch size, but because of the the prefetch UNIT WORD SIZE. On the SX, each prefetch unit is 16-bits, on the DX, each prefetch unit is 32-bits. So, the algorithm worked by accident, not by design. But finally, using the correct approach to try and determine differences in prefetch unit word size, now let's write an algorithm. Again it fails on various machines with different wait states, CPU speed, and caches. I guess you saw the original posting, but missed my followup when I explained all of this. So, to answer your statement...the posted algorithm simply doesn't work and that's why all the fuss. -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/01/90)
In article <35010018@hpfinote.HP.COM> pnl@hpfinote.HP.COM (Peter Lim) writes: | Well, how about this. Do some 16 bit and some 32 bit access from the | CPU ? This can tell you about the bandwidth to memory, but cache and 16 bit memory can make an SX and DX look too close to call. You are right that this gives useful information about system performance, however! Semi-related: I have a benchmark of my own devising, and on every 386 it shows that the 16 bit integer arithmetic is faster than 32, while on 486s short is slower than long. Interesting... -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
mlord@bwdls58.bnr.ca (Mark Lord) (10/02/90)
In article <4126@altos86.Altos.COM> rcollins@altos86.UUCP (Robert Collins) writes: >Just a friendly note in case you don't know much about '386's...But the >SX and DX have the same size prefetch queue. This can be confirmed by >simply looking in the SX and DX hardware reference manuals (respectively) >and verify that both have 16-byte prefetch queues. So code that checks >the length of the prefetch queue isn't going to determine anything... >except the length of the prefetch queue. Somebody with a manual should probably double-check this assertion. I do not have a manual any more, but my recollection is that both processors have 4-deep prefetch queues.. that is, each can prefetch up to 4 machine words. On a DX, a machine word is 32 bits, whereas on an SX it is 16 bits (for the BIU, that is). Thus, a DX has a 16-byte prefetch queue, and an SX has only 8. The posted code (I missed it) probably failed to properly preload the prefetch queue. To do this, one must cleverly code a loop which is 12-bytes in length, and which executes twice in succession, modifying itself the second time around (but not the first time). This is necessary to overcome problems with bus bandwidtch, which might otherwise affect this test. The actual coding of such a beastie is left as an exercise for The Reader. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
rcollins@altos86.Altos.COM (Robert Collins) (10/03/90)
In article <4463@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >In article <4126@altos86.Altos.COM> I wrote: >>Just a friendly note in case you don't know much about '386's...But the >>SX and DX have the same size prefetch queue. This can be confirmed by >>simply looking in the SX and DX hardware reference manuals (respectively) >>and verify that both have 16-byte prefetch queues. > >Somebody with a manual should probably double-check this assertion. >I do not have a manual any more, but my recollection is that both processors >have 4-deep prefetch queues.. that is, each can prefetch up to 4 machine words. > Sure, I don't mind double checking my own assertion...even though I gave a literary reference (which was actually an incorrect reference). This time, I will be more explicit... In "386 (tm) DX Microprocessor High Performance 32-Bit CHMOS Microprocessor with Integrated Memory Management" book by Intel (Part number 231630) on page 15 under section "2.4.1 Instruction Set Overview" comes the following quote: "The average instruction length is 3.2 bytes long. Since the 386 DX has a 16-byte instruction queue, an average of 5 instructions will be prefetched." This can be cross checked (the same text) in the Intel "Microprocessors" manual (part number 230843) on page 4-181. (The manual I just quoted is included inside this other manual.) Now, in the Intel "386 (tm) SX Microprocessor" manual (part number 240187) on page 10 under the section "2.2 Instruction Set" comes the following quote: "The average instruction length is 3.2 bytes long. Since the 386 SX has a 16-byte instruction queue, an average of 5 instructions will be prefetched." This same text can be cross referenced in the Intel "Microprocessors" manual (same as above, part number 230843) on page 4-118. >On a DX, a machine word is 32 bits, whereas on an SX it is 16 bits (for the >BIU, that is). Thus, a DX has a 16-byte prefetch queue, and an SX has only 8. > If this was true, then the SX manual would have stated that an average of 2.5 instructions would be prefetched, not 5. Of corse, Intel could have simply copied huge portions of the DX manual without checking for content. So, let me try and verify my statement from some other text... Let's turn to page 75 of the Intel "386 SX Microprocessor" manual, (P/N 240187) or page 4-483 of the Intel "Microprocessors" manual (P/N 230843). Under section "8.0 Differences between the 386 SX CPU and the 386 DX CPU" comes the following quote: "6. The 386 DX CPU prefetch unit fetches code in four-byte units. The 386 SX CPU prefetch unit reads two bytes as one unit (like the 80286). In BS16 mode, the 386 DX CPU takes two consecutive bus cycles to complete a prefetch request. If there is a data read or write request after the prefetch starts, the 386 DX CPU will fetch all four bytes before addressing the new request." Please take note of the consistant use of the word "byte" in the Intel manuals. They talk about prefetch unit size in terms of bytes. They also describe the prefetch queue size in terms of bytes. I believe it is reasonable to assume Intel is talking about the same size 8-bit quantity as being a byte -- in both references. Furthermore, under the same heading "8.0 Differences between the 386 SX CPU and the 386 DX CPU" there is no mention to different prefetch queue sizes. I believe that if there was a difference, this is where it would be listed. And since there is no mention of it, and the consistent use of the word "byte" as a descriptive term, firmly establishes the fact that the prefetch queue is 16 bytes (16 x 8-bits) long on both CPU's. So now somebody with a manual has double checked this assertions. It's ironic, but the request was to have "somebody with the manual" check this...even though I made reference to the manual?!?????????? -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356