Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (
More info?)
Douglas Siebert wrote:
> Kind of a moronic position for those speculators to take since the
whole
> point of the virtualization tech from both Intel and AMD is that it
will
> be completely invisible to the OS and user mode code. It only has to
be
> coded in the hypervisor and there aren't exactly thousands of
different
> implementations of that kind of software, and the critical sections
where
> these differences mattered would be quite small. Who cares if there
are
> two code paths for those sections? If game authors can write
completely
> different rendering paths for ATI and NVidia cards, I'm sure EMC and
MS
> can handle making their software handle both Intel and AMD
virtualization.
> Since Xen is open source it will certainly be done for both, and
probably
> done by Intel and AMD engineers, at that. Maybe even with support
ready
> before you can even buy the CPUs themselves.
That reminds me, how are they adding these extra instructions into the
x86 instruction set? It's been years since I looked into x86 assembly
(since the 386 and 486 days), and previously they used to just add new
instructions into the second bank of instructions by adding a specific
instruction prefix (I believe it was called the "ESC" prefix). However
they couldn't just add those extra instructions anywhere they liked
(well, actually initially they could, since it was just Intel
controlling it all back then), but as that second map got filled up,
they had do it strategically, they had to add them in a
compatible-fashion. Have they opened up a new instruction path
nowadays?
> Anyway there's already a few forks in the x86 world, since Intel
doesn't
> support 3Dnow!, AMD doesn't support hyperthreading, AMD didn't
support
> MONITOR and MWAIT in their SSE3 implementation. Oh yeah, for a while
> there Intel didn't support AMD64, but they recently fixed that.
Also there was a brief period where Intel's version didn't support the
NX-bit in the paging tables.
> Which points out another alternative. That AMD just does what Intel
did
> when they implemented AMD64. Wait until they come out with the docs
about
> the tech (which Intel just did) and take a month to copy them with
some
> minor modifications to suit your CPU's implementation a bit better
(like
> if you had stuff like glueless SMP support the other guy doesn't)
Then
> announce it as shipping the following year. If AMD followed that
path,
> they'd release their info in a month, then announce a ship date of
2006.
> Oh wait...
Well, it took considerably longer for Intel to copy AMD64 than a month.
I think the AMD spec docs were out a full year before AMD actually
released any products. And then it took Intel another 1.5 years to
release their own version. So altogether it was 2.5 years later for
Intel. Mind you I would guess that the AMD64 instruction set would be
much more complicated to copy than a virtual-machine instruction set.
There was an earlier example for AMD. During the introduction of the
MMX instruction set, AMD had their version released on the same day as
Intel's. There was talk that AMD was planning on doing its own
proprietary instruction set previously, but then it decided to license
MMX from Intel and it simply remapped all of its proprietary
instructions to the MMX instruction mappings instead. AMD was able to
do that virtually overnight. I can imagine if compatibility in virtual
machines is a requirement, then it shouldn't be too difficult to remap
Pacifica to Vanderpool or vice-versa. It must relatively
straightforward in the same way MMX was straightforward.
But it may not be necessary, virtual machines aren't that common that
they need compatibility.
Yousuf Khan
Facebook
Twitter
Instagram