To: 386users@twg.com Subject: 80386 mailing list, vol 4 #1 Date: 7 Feb 89 19:00:25 EST (Tue) From: steinmetz!crdos1!386users@uunet.uu.net (Wm E. Davidsen) 80386 User's mailing list vol 4 #1 Jan 8, 1989 In this issue: Different types of cache on 386's (4 msgs) Logitech Bus Mouse and VP/ix 1.1.0 Re: 386 Add in boards Using a Hayes-type modem with System V/386 80486 (2 msgs) C-Kermit & SCO Xenix 2.3.1 Sources for X Windows Re: Intel iSBC386/16 386 & cache Northgate 386 The addresses for the list are now: 386users@TWG.COM - for contributions to the list or ...!uunet!TWG.COM!386users 386users-request@TWG.COM - for administrivia or ...!uunet!TWG.COM!386users-request P L E A S E N O T E If you want to get on or off the list, or change your address, please mail to the 386users-request address, or the message will be delayed by having to hand forward it (for your convenience, not mine). ---------------------------------------------------------------------- From: john@wa3wbu.UUCP (John Gayman) Subject: Different types of cache on 386's Date: 22 Nov 88 01:35:19 GMT Can anyone tell me breifly what the difference is between "Direct Mapped Cache" and "Two-way Set Associative Cache" and why one would be preferred over the other ? I usually see the first being a 32K and the second 64K. Thanks. This is on a 386 system. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P ------------------------------ From: darel@maccs.McMaster.CA (Darel Mesher) Subject: Re: Different types of cache on 386's Date: 23 Nov 88 19:00:14 GMT There are _many_ different caching strategies (limited only by designer imagination) however 3 more popular cache organizations are ; Associative Direct Mapped Set Associative An Associative cache uses a content addressable memory (CAM) where a tag (address) is presented to the cache and simultaneously all valid cache tag entries are compared. In the event of a 'hit' the data is returned, a 'miss' generates an external memory fetch (usually a block of data is transfered [eg. 4 words] in burst mode) and the new data and tag displaces a current cache entry. Since the cache uses a CAM, the replacement mechanism can be much more efficient than the Direct Mapped approach. Typical replacement strategies include Least Recently Used (LRU), Random and First In First Out (FIFO). Needless to say, the complexity of a CAM is great, each cell in the cache has to have its own tag comparitor, and for on-chip caches this is a luxury that not often available. This complexity is a trade-off for one of the most efficient caching strategies. Direct Mapped caches are by far the simplest and most compact (in terms of chip real estate) however, with simplicity comes draw- backs. Direct Mapped caches directly map the tag (address) to the corresponding data. There is no replacement algorithm, the tag (address) determines which location in the cache must be used. Hence aliasing is a problem: ,-----. ,-----| = ? |-----> HIT Tag check and data | `-----' retrieval done | ^ simultaneously. | |N-m bits | ,--------. Example: N= 4 and m= 2 bits N-m bits| | TAG | ,-------' | (RAM) | Tag Data Valid N bit/ `--------' ---------------------- ---< ^ addr 00 | | | | addr \_________________| 01 | 10 | data | 1 | m bits | 10 | | | | (LSB) v addr 11 | | | | ,--------. ---------------------- | DATA | | (RAM) | `--------' Therefore addr 1001 would map | to the second entry in the | table and in this case it is data <----' valid (bit = 1) and 'HIT' signalling a cache 'hit'. The problem of aliasing can be demonstrated using the above example. If a loop in the executing code mades repeated references to different addresses with the same Tag field then that cache entry would generate a 'cache miss' each time thru the loop. For example if both address 1101 and 1001 are repeatedly referenced then each reference would generate a cache fault that would force an external memory fetch. In short, this would result in perpetual displacement of the xx01 cache entry while inside the loop. This scenario represents the limitations of Direct Mapped caches. Set Associative can be considered as providing a compromise between Direct Mapped (simple,reasonable performance) and Associative (complex, execellent performance). N-way set Associative caches provide N Direct Mapped caches which are inspected simultaneously. Using the Direct Mapped example from above with a set size of 2 the cache table would look like; Tag Data Valid -------------------------- 00 |.......|...........|......| |_______|___________|______| 01 |..10...|...data....|...1..| |__11___|___data____|___1__| 10 |.......|...........|......| |_______|___________|______| 11 |.......|...........|......| | | | | -------------------------- Therefore, there are now two entries for the 01 tag and as in the example above, references for the two address 1101 and 1001 would both result in cache hits. The hardware is still relatively simple and replacement strategies can be employed for entry displacement. It has been shown that optimum set sizes fall into the 2 to 4 range (since a programmer rarely manipulates more than 4 data structures simultaneously). The 2-way Set Associative approach shows a noticable performance enhancement over the direct mapped approach. It is not uncommon to find CPUs with different size and types of on-board caches. The National Semiconductor NS32532 has a 512 byte Direct Mapped Instruction cache, a 1024 byte 2-Way Set Associative Data cache and an on-board MMU with a 64 entry Associative (CAM) Translation Lookaside Buffer. This one CPU has all three cache types mentioned above! -- Darel Mesher ...!uunet!mnetor!maccs!darel McMaster University darel@maccs.mcmaster.ca ------------------------------ From: rmarks@KSP.Unisys.COM (Richard Marks) Subject: Re: Different types of cache on 386's Date: 23 Nov 88 16:23:17 GMT In article <673@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: > Can anyone tell me breifly what the difference is between "Direct >Mapped Cache" and "Two-way Set Associative Cache" and why one would be >preferred over the other ? I usually see the first being a 32K and >the second 64K. Thanks. This is on a 386 system. I'll try. Basically all cache is addressed by the low bits of the address. The address in the cache is usually to the word (4 bytes) level. So you can always get something from the cache, the question is VALIDITY. You get an extra 8 bits along with the 32 bits of data from the cache. These 8 bits are compared with the next 8 bits of the address. If they match, you have cached data. (The highest 8 bits must match or cache gets reset. This is not a problem on a PC but it is on Unix). So far I have described "Direct Mapped Cache". Now in most PC programs there is a seperate code and data segment. Usually these are addressed from the low segment offset; so low offsets are used more frequently. Thus considering the above DMC algorithm, there is a good chance of having code and data access the same offset and thus the same cache location. This causes cache to keep reloading and reduces it's effectiveness. The two-way cache allows two segemnt addresses for the same offset. I thought most 386 machines use DMC while the Motorola MMU'c use two-way. Does anyone know which 386's use two way?? The 386 Unisys machines I know of (the 6000/50 and PW850) use DMC. Richard Marks rmarks@KSP.unisys.COM ------------------------------ From: rmarks@KSP.Unisys.COM (Richard Marks) Subject: Re: Different types of cache on 386's Date: 23 Nov 88 16:45:47 GMT I goofed. In my previous posting on cache, I said that our (Unisys) PW850 only has Direct Cache. It comes with 32k direct cache; but you can add another 32k and then it becomes 2-way associative cache. By the way, these PW850's are real good boxes and they are selling at clone competitive prices. Richard Marks rmarks@KSP.unisys.COM ------------------------------ From: root@mjbtn.MFEE.TN.US (Mark J. Bailey) Subject: Logitech Bus Mouse and VP/ix 1.1.0 Date: 20 Nov 88 23:34:38 GMT Hello netlanders, I finally got MY version of VP/ix 1.1.0 along with my long awaited update to 2.3.1 OS. I installed the 2.3.1 upgrade with no real trouble and it seems to work fine. However, when I installed VP/ix, it never asked me about a mouse and I also remember reading that it might or might not depending on my setup. I assumed that because 2.3.1 used the mouse, VP/ix made use of that. I followed the instructions to install my mouse. I have a Logitech Bus mouse on interrupt vector 5. I typed 'mkdev mouse' and selected option '6' for the Logitech Bus mouse. Well, all went very well, and it relinked the kernel with no problems. Then I rebooted my system (cold) and proceeded to use the 'usemouse' command to check it out. It didn't work. The mkdev prrogram created two device files in /dev/mouse, bus0 and vpix0. They had major number 10 and minor numberS 0 and 1 respectively. When I booted my system, no mention of the mouse appeared in the boot screen. When I try to run vpix or usemouse, I get a "cannot open" error on the bus0 and vpix0 (for VP/ix). Does any one have any idea what might be happening here? SCO, if you are listening, do you? The Logitech manual claims that the "bus board i/o address is set at 23C to 23F." Shouldn't the mouse, if properly installed, show up on the boot screen? Also, I tried setting the base address to 0H (auto config) and 023CH during the mouse setup with the same results each time. I would appreciate any information that anyone might provide on this matter. It isn't the end of the world I guess, but I have having to figure out how to use the keyboard again in my DOS applications! :-) By the way, when the machine is booted on the DOS partition, the mouse works great. I have a Tandy 4000 (386/16 mHz) with 2 meg RAM if that is of any consequence. Email responses would be fine. I will summarize and post if I learn anything of real valae. Thanks in advance! Mark. -- Mark J. Bailey "Y'all com bak naw, ya hear!" USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________ VOICE: +1 615 893 4450 / +1 615 896 4153 | JobSoft UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co. DOMAIN: mjb@mjbtn.MFEE.US.TN | Murfreesboro, TN USA ------------------------------ From: viggo@freja.dk (Allan Kim Schougaard) Subject: Re: 386 Add in boards Date: 18 Nov 88 14:59:16 GMT Hi. Maybee one of you could answer this : Can a 80286 be replaced by 80386SX in some smart way ? By the way : Is V50 a replacement for 80286 ? (If not then what is a replacement for ?) Viggo at DIKU (Viggo@freja.dk) ------------------------------ From: tom@dvnspc1.UUCP (Tom Albrecht) Subject: Using a Hayes-type modem with System V/386 Date: 22 Nov 88 22:18:56 GMT We are having trouble hooking up a Hayes-compatible modem to a 386-based system running System V.3. In order to get Unix to send the dial codes to the modem, carrier detect must be forced high from the modem (i.e. AT&C0). With this setting we are unable to actually detect when the modem looses carrier from the remote system. 'sh' ends up staying around and 'getty' never gets respawned for the line. Any suggestions as to how we can talk to the modem and detect remote carrier? Thanks! -- Tom Albrecht Unisys UUCP: {sdcrdcf|psuvax1}!burdvax!dvnspc1!tom ------------------------------ From: bkliewer@iuvax.cs.indiana.edu (Bradley Dyck Kliewer) Subject: 80486 Date: 28 Nov 88 16:34:57 GMT Has anyone seen information on the 80486, recently -- especially projected production dates? I would also like to know what new features it's supposed to have. Bradley Dyck Kliewer Hacking... bkliewer@iuvax.cs.indiana.edu It's not just an adventure It's my job! ------------------------------ From: caulton@inuxd.UUCP (D Caulton) Subject: Re: 80486 Date: 29 Nov 88 16:30:31 GMT > Has anyone seen information on the 80486, recently -- especially projected > production dates? I would also like to know what new features it's supposed > to have. I talked to Intel just about a month ago--they refuse to officially acknowledge the chip as having any features at all. They have only admitted it exists grudgingly. Infoworld had some rumors about it a month or two ago--you might look there. As I recall it will be an awesome chip, with full math coprocessor functions built into the instruction set (there will, I think, be two versions--one weak, which will have these functions, and a streamlined one without them.) The first machines running with it are supposed to run at 40 MHz, going up from there. But it will be a might expensive- these machines will cost upwards of 20,000 samolians. Not a bad deal for a machine more powerful than most minis, though. Anybody else have more information on these? David Caulton AT&T Bell Labs Indianapolis, IN ------------------------------ Date: Tue, 22 Nov 88 20:59 EST From: MAJ David McGuffey Subject: C-Kermit & SCO Xenix 2.3.1 This is a follow-up to my first message -- probably didn't have enough info for anybody to figure out my problem. As I mentioned earlier, I installed SCO Xenix 2.3.1 (complete system) on a Zenith 386 with 2 MB of memory and a Zenith 14" VGA grey scale monitor on the Zenith 449 video card. I also installed a terminal (Zenith 181) on COM2 (/dev/tty2a), and a USR 1200 Password modem on COM1 (/dev/tty1A). The modem line and terminal line all work as expected. I can use cu to dial out either from the console or from the terminal. I will assume that the Device and Dialers files are set up correctly if cu is working. I received and built C-Kermit 4E(070) with the command "make xenix". The make went ok without any errors reported. When I brought it up, I could not set the line to COM1 (/dev/tty1A) -- wermit reported "Permission Denied" and returned to the C-Kermit> prompt. I then logged in from the 181 on COM2 and ran kermit on both ends. With the line set to /dev/tty2a, wermit and MS-Kermit successfully exchanged files. diff reported that the original and the returned copy (to the 181 and back) were exact copies of each other. I'm satisfied that wermit in the "remote" mode works as expected, but I cannot set it up to dial out to a mainframe and exchange files. The "Permission Denied" message indicates to me that ownership of /dev/tty1A and/or wermit and the read/write permissions may the the problem. SCO indicates that the dial-out device needs to be owned by uucp -- cu works so I don't really want to muck with that. I tried to chown and chgrp wermit to uucp, root, and bin with no luck. I ran the "make" as a user and as root, but that didn't make any difference either. I'm sure the problem is simple. Since most things work, I'm sure I'm close -- maybe too close to see the simple problem and the solution. Could someone please tell me how to get kermit to dial out so that I can exchange files with a mainframe? ------------------------------ From: steinmetz!uunet!convex!sir-alan!mikes Subject: Sources for X Windows Date: Sun Nov 27 14:28:09 1988 There are two anonymous uucp archives that carry X V11 Release 3 (and maybe 4, by the time you read this) - "daisy" and "alphacm". "daisy" has a TB+ that can run at 19.2Kbps (actual throughput will vary - I'm getting 900 bytes/sec); alphacm is 2400. The phone number for alphacm is 1-714-898-8634; login of "bbs". He allows anonymous uucp access; one of the bulletins describes the process. That system is the home system for the XBBS BBS system. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! A n n o u n c i n g !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! T h e !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! W e s t C o a s t X a r c h i v e !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! The West Coast Xarchive is now available. The purpose of this archive is to provide access to all publicly available X Window System based soft- ware through UUCP. The archive contains a complete comp.sources.x direct- ory and a copy of what can be found on expo/contrib and expo/pub. The expo directories will be updated roughly once a month. The archive can currently be accessed at 1200/2400 baud or at 19.2K baud (Telebit Trailblazer). Access is by anonymous login, the userid is UXarchive with no password. The dialin numbers are: 415-967-4619 1200/2400 dial-in 415-967-4718 trailblazer dial-in A sample L.sys entry might be: daisy Any ACU 19200 4159674718 "" \d ogin: UXarchive daisy Any ACU 2400 4159674619 ogin:-BREAK-ogin: UXarchive To get a current listing of what files are available and where they can be found, download the file /usr/spool/uucppublic/Xarchive/ls-lR.Z Since some of the files in the archive may tend to be rather large, I am also offering snailmail service for users. To make my life simple Please include the following when request a tape by mail: 1. The tape (either reel, Sun cart, or uVax cart format) 2. a reusable or return mailer for the tape 3. POSTAGE 4. a COMPLETE return address 5. a list of the files that you want (please don't be too pickey, it's easier to send the whole archive than 75% of it) 6. if the tape is in reel format, the tape density Since I do this in my copious spare time, please allow for about a three to four week turn around for tape requests. ...{decwrl|ucbvax}!imagen!atari!daisy!turner (James M. Turner) ...uunet!daisy!turner Daisy Systems, 700 E. Middlefield Rd, P.O. Box 7006, Mountain View CA 94039-7006. (415)960-0123 ------------------------------ Date: Tue, 22 Nov 88 15:43:20 PST From: Jamey Graham Is anyone out there using System V Unix Version 3 for 386 machines and X Windows. If your are please drop me a note on what ports are available for what versions of V.3. My vendor, currently, does not have a port. Interactive Systems has 10.4 but I need something a little more generic, like for AT&T Unix System V version 3 that we can tailor. Thanx, Jamey Graham jamey@mercury.rsivax ------------------------------ Subject: Re: Intel iSBC386/16 Date: 30 Nov 88 07:53:54 GMT (Wed) From: steinmetz!uunet!slxsys.specialix.co.uk!jpp (John Pettitt) > Date: Sun, 16 Oct 88 14:35:38 -0400 > From: ken@gatech.edu (Ken Seefried iii) > Subject: Intel iSBC386/16 > > I was wondering if there were many people that are running either the > Microport or Interactive port on an Intel iSBC386 motherboard. Is this an > acceptable hardware platform? > > Any comments? > > [ It works... Intel makes chips, not motherboards. This is one of the slower > boards out there, and its price doesn't match its performance. Get a clone. > --vix ] Thats true of the 301 board (the 16 Mhz version) but the 302 is a another matter. The 302 is a 25 Mhz board with a performance about twice that of the 16 Mhz. We have a customer with the following: Intel 302 (16 MB ram) DPT 3011 Cacheing disk controller with 12.2 MB Cache 2 * ESDI disks (600 MB each) 32 port Specialiix SI card (plug plug . . . :-) 386/ix He thinks it's great. Does anybody know of a bigger `live' 386 system out there ? We use the 302 in house as a development system and have no problems at all. The quality is so much better than any clone. And when the 401 appears . . . :-) > Thanks... > ...ken John Pettitt Specialix International Disclaimer: We sell I/O cards and DPT disk controllers not Intel Motherboards. ------------------------------ From: mac3n@babbage.acc.virginia.edu (Alex Colvin) Subject: 386 & cache Date: 29 Nov 88 17:52:47 GMT I see that some of the 386 PCs come with cache controllers. . What does cache gain you with 0 wait state memory? . How does this controller handle shared RAM, such as is found on network cards? ------------------------------ From: warren@psu-cs.UUCP (Warren Harrison) Subject: Northgate 386 Date: 28 Nov 88 19:22:40 GMT If anyone out there has had any experience with the Northgate 386, good or bad, I'd like to hear about it. In particular, I'd like to hear about their service and reliability. Also, after buying one, did you think it was a good deal? Thanks. Warren -- ------------------------------------------------------------------------------- Warren Harrison CSNET: warren@pdx.edu Department of Computer Science UUCP: {ucbvax,decvax}!tektronix!psu-cs!warren Portland State University Internet: warren%pdx.edu@relay.cs.net Portland, OR 97207-0751 ------------------------------ End of 80386 M/L ****************