tomk@intsc.UUCP (Tom Kohrs) (11/12/86)
With comp.sys.intel now offcially formed I would like to see if there is suffcient interrest out there to keep it going. My interest in this group will be to persue discussions on the advanced (no flames yet please) architectures that Intel is selling (ie. 286,386, 586, and 786). With the focus towards technical discussions of applications, implementation questions and problems, and a responsible discussion of the architectural features with an emphasis toward what enhancements should be done on the 486 and beyond (68020 and vax compatibility have already been suggested). What I hope that this group does not become is a flaming ground for 68K fanatics to expound the Motorola propaganda, or as the standard cross posting catagory for comp.sys.ibm.pc. Questions regarding the programming and problems with the pc hopefully will stay in the pc catagory. Just a note to introduce myself. I am the architecture specialist for Northern California and Northern Nevada. I reside in Silicon Valley next door to the Intel factory so I have quick access to factory types to act as backup for any technical questions that are thrown up on the net. I hope this group will be useful and I am looking forward to following it in the future. -- ------ "Ever notice how your mental image of someone you've known only by phone turns out to be wrong? And on a computer net you don't even have a voice..." tomk@intsc.UUCP Tom Kohrs Regional Architecture Specialist Intel - Santa Clara
creedy@cca.UUCP (Christopher Reedy) (11/13/86)
> With comp.sys.intel now officially formed I would like to see if there > is suffcient interest out there to keep it going. As a starter: The recent BYTE article on the 80386 and virtualization indicated that it is not possible to have a 386 completely virtualize itself, as opposed to virtualizing the 8086 or 80286. Is this true? If it is, are there any rules that operating system developers could follow that would guarantee that an operating system could be run in virtual mode? > What I hope that this group does not become is a flaming ground for 68K > fanatics to expound the Motorola propaganda, or as the standard cross > posting catagory for comp.sys.ibm.pc. Questions regarding the programming > and problems with the pc hopefully will stay in the pc catagory. Amen. Chris Reedy, Computer Corporation of America
gnu@hoptoad.uucp (John Gilmore) (11/15/86)
In article <400@intsc.UUCP>, tomk@intsc.UUCP (Tom Kohrs) writes: > My interest in this group will be to pursue discussions on the advanced > (no flames yet please) architectures that Intel is selling (ie. 286,386, > 586, and 786)... > ...the 486 and beyond... Sounds good to me. Tom, can you start with a summary of the architecture of each of these chips? The only 586 I know of is the 82586 which is an "advanced" but very buggy Ethernet chip. Haven't heard of the 786 at all. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa "I can't think of a better way for the War Dept to spend money than to subsidize the education of teenage system hackers by creating the Arpanet."
jnw@mcnc.UUCP (John White) (11/17/86)
> ... with an emphasis toward what enhancements should > be done on the 486 and beyond (68020 and vax compatibility have already > been suggested). Well, I have some ideas about what might be nice on the 486. First add I & D caches, with separate internal data paths to each (like the 68030 is supposed to have). Then add some sort of 1-transfer/cycle memory access. The 68030 has a mode that allows 128bits from memory to be multiplexed over the 32bit data bus at 1-transfer/cycle. This is good for reading code, and most serious memory boards are at least 128 (+ parity&ECC) chips wide anyway. It might be nice to keep some kind of prefetch with the code, though. If the 486 is executing a newly loaded block of 128bits, then it might prefetch the next 128bits. If the 128bits currently being executed were already in cache (and are being executed for the second or n'th time), then this may be the bottom of a loop and so no prefetch should occur. A bus-error pin might also be useful to someone who wants to have some external memory management, or who wants to have software handling of memory ECC, or some other such thing. The 386 has the internal capability to handle page-faults, but I don't see any way of causing a page-fault type of interrupt externally. I would think that this would be easy to add. Variable page sizes would also be nice. (2**n, of course). By the time that the 486 is at the end of its useful life, there will be systems using it that will have really massive amounts of memory. I expect that some programs on these systems will do a more or less random access to memory quite often. But the 386 has to load two TLB entries before being able to access a random location in a big memory. If the pages were large enough, however, the TLBs would be able to cache the whole 4Gbyte address space, and there would be no performance penalty for having the memory management active. Also, a couple of pins could be added to the physical address bus. With 16Kbyte pages, you could have a 16Gbyte physical memory (which could hold several 4Gbyte logical address spaces). Well, these ramblings should at least get some discussion going. -jnw@mcnc
billw@navajo.STANFORD.EDU (William E. Westfield) (11/18/86)
Are those current products, currently anounced products, hypothetical part numbers, or what ? BillW