🚀 go-pugleaf

> 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

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."

> ... 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

Are those current products, currently anounced products,
hypothetical part numbers, or what ?

BillW

> 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?

Virtualization in this context refers to the ability to have the cpu run
a Virtual Machine OS.  An example is VM370.  One of the requirements for
being able to run a VM type os is that any other os (including a copy of
itself) as a task or process without it being able to detect (other than by
performance) that it does not control the cpu.  As an example the os that 
is running under the VM os has to believe that it can completely control 
the machine status word and that everything that it writes there will effect 
the hardware directly (ie. enabling and disabling the interrupts).   
Hardware support required to do this effectively requires the ability to 
write protect certain registers in the CPU from other tasks that are running 
at the os privilege level and cause those acesses to trap to the VM os. The 
VM os would then emulate the function of the write to the MSW and return the
appropriate results to the child os.  

There are some tricks to writing a VM os that allow it to function on a 
machine that does not have all of the hardware traps.  This can be done
by loading the child os at a level lower than the VM os and doing emulation
of the os level functions. Other tricks include adding specialized hardware
to the system.

***WARNING*** I am basically a hardware type so don't take all of this as
              absolute gospel.  Also interjection by someone that understands
	      Virtual OS's would be appreciated (Cliff?).

Virtualizing the 286 mode presents the same problems that the 32bit mode does
(they are really the same mode just different path widths in the execution 
unit).  So running 286 XENIX under UNIX system V.3/386 is not intended to
work.

The virtual 86 mode is a different matter.  When the os loads a task as a 
virtual 86 program the entire environment (86 os and application) is run
as at the application level.  Since the 8086 did not have the concept of
privilege levels the programs and os's don't expect to be able to change 
them.

As far as guide lines for writing a VM os or an os to run under a VM os,
I will leave that to people who know better what is involved.


-- 
------
"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