Emulate SSE2 on a Pentium III or lower ?
Hilaire VERSCHUERE
I wrote SSE2 optimisations in my program, but I'm working on a PIII,
so I can compile but not execute to test it. Does anyone knows an SSE2
emulator that would let me to test if my program works ?
Hilaire Verschuere
http://hilr.free.fr
Matt Taylor
news:ea8b66fd.03030...@posting.google.com...
If you're lucky, VMware or Virtual PC (or another PC emulator) may have
these instructions implemented. I wouldn't count on it, though.
What you may be able to do is write an exception handler that traps illegal
instructions. It can then decode the instruction and emulate it. It will be
slow, but at least you'll have a good idea as to whether it has any bugs in
it.
The only other solution is to get access to a Pentium 4 somehow.
-Matt
TS
>these instructions implemented. I wouldn't count on it, though.
I guess these instructions are still CPU dependant as they aren´t
privileged ones and thus executed by the CPU directly.
Matt Taylor
news:3e651827...@News.CIS.DFN.DE...
> >If you're lucky, VMware or Virtual PC (or another PC emulator) may have
> >these instructions implemented. I wouldn't count on it, though.
>
> privileged ones and thus executed by the CPU directly.
Of course they are.
I don't know what I was thinking; I forgot that VMware and Virtual PC don't
really emulate. They copy and translate. It's much faster. I guess that's
out of the question, then. The only option is a real emulator like Bochs,
and I doubt Bochs supports it. I don't know about others, though...
-Matt
Alan Woodland
How do AMD/Intel etc keep adding extensions that become common in the
next generation of cpus without ever having instrucitons clashing?
Alan
Tim Roberts
>
>On a sort of related note:
>
>How do AMD/Intel etc keep adding extensions that become common in the
>next generation of cpus without ever having instrucitons clashing?
What makes you think their new instructions don't clash?
People are now smarter about checking for SSE2 before running SSE2
instructions, and so on, so the clashes don't cause problems.
However, programs that execute the wrong instructions on the wrong CPU will
probably behave in a very unexpected matter.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Daniel Pfeffer
> >these instructions implemented. I wouldn't count on it, though.
>
> privileged ones and thus executed by the CPU directly.
If you feel like doing a large amount of work, you can trap the "illegal
instruction" trap (INT 06) and emulate any instruction that you wish. It
would probably be more cost-effective to simply buy a new PC (or perform a
"motherboard transplant" on your existing PC).
Daniel Pfeffer
H. Peter Anvin
By author: Alan Woodland <aj...@aber.ac.uk>
In newsgroup: comp.lang.asm.x86
>
> On a sort of related note:
>
> How do AMD/Intel etc keep adding extensions that become common in the
> next generation of cpus without ever having instrucitons clashing?
>
Don't reuse opcodes. New opcodes which haven't been used in the past
give a #UD trap on older processors.
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
James Stevenson
"H. Peter Anvin" <h...@zytor.com> wrote in message
news:b453su$qr3$1...@cesium.transmeta.com...
> Followup to: <1046832110.628803@dyfi>
> By author: Alan Woodland <aj...@aber.ac.uk>
> In newsgroup: comp.lang.asm.x86
> >
> > On a sort of related note:
> >
> > How do AMD/Intel etc keep adding extensions that become common in the
> > next generation of cpus without ever having instrucitons clashing?
> >
>
> Don't reuse opcodes. New opcodes which haven't been used in the past
> give a #UD trap on older processors.
i think what he means by that is
AMD develop new opcode y and use byte code x
Intel develop new opcode z and use the same byte code x
if y / z do 2 different things then they run into a
problem if they both use x for the code.
do they have ranges specified or do they tell each other what
they are developing ?
James
Tim Roberts
>
>i think what he means by that is
>
>AMD develop new opcode y and use byte code x
>Intel develop new opcode z and use the same byte code x
>
>if y / z do 2 different things then they run into a
>problem if they both use x for the code.
>
>do they have ranges specified or do they tell each other what
>they are developing ?
Neither one. There are and will continue to be clashes. As long as user
programs take care to ensure they don't their execute Athlon XP routines on
a Pentium IV and vice versa, the clashes don't metter. Fortunately, we're
all getting very good at that.
Matt Taylor
news:1046832110.628803@dyfi...
> On a sort of related note:
>
> How do AMD/Intel etc keep adding extensions that become common in the
> next generation of cpus without ever having instrucitons clashing?
Actually AMD has introduced a very small number of instructions: their 3DNow
and Extended MMX instructions. Since Intel creates 90% of the new
instructions in the ISA, there is no problem (except artificial problems
created by SSE 2).
A long time ago when Intel actually had competition, Cyrix, AMD, IDT, and
others all conspired (heh heh) and proposed an open extension mechanism for
the x86 ISA. This mechanism uses two 0F prefixes (0F 0F) and decodes
differently. Intel seems to have respected this despite not supporting the
only extension that was ever proposed: 3DNow.
I -think- the MMX extensions that AMD introduced went into the 0F opcode
map, but I'm not sure. How AMD avoided conflicts I don't know, but AFAIK all
of their MMX extensions have been absorbed by Intel.
-Matt
Matt Taylor
news:gkgg6vonl3fg341nu...@4ax.com...
There are no clashes except ones Intel introduced with SSE 2.
-Matt
Matt Taylor
> Alan Woodland <aj...@aber.ac.uk> wrote:
> >
> >On a sort of related note:
> >
> >How do AMD/Intel etc keep adding extensions that become common in the
> >next generation of cpus without ever having instrucitons clashing?
>
> What makes you think their new instructions don't clash?
>
> People are now smarter about checking for SSE2 before running SSE2
> instructions, and so on, so the clashes don't cause problems.
>
> However, programs that execute the wrong instructions on the wrong CPU
will
> probably behave in a very unexpected matter.
The encodings don't clash with the exception of some SSE 2 instructions,
specifically the integer SSE 2 instructions. They encode exactly like the
MMX instructions except they use prefixes. On a Pentium 3 or Athlon, the
instructions will execute without causing an illegal instruction exception,
but they will use the MMX registers instead of the SSE registers.
-Matt
wicked...@trioptimum.com
"Matt Taylor" <pa...@tampabay.rr.com> wrote in message
news:Tj7aa.22691$lW3.2...@twister.tampabay.rr.com...
> "Alan Woodland" <aj...@aber.ac.uk> wrote in message
> news:1046832110.628803@dyfi...
> > On a sort of related note:
> A long time ago when Intel actually had competition, Cyrix, AMD, IDT, and
> others all conspired (heh heh) and proposed an open extension mechanism
for
> the x86 ISA. This mechanism uses two 0F prefixes (0F 0F) and decodes
> differently. Intel seems to have respected this despite not supporting the
> only extension that was ever proposed: 3DNow.
I also recall Cyrix having some funky MMX extentions where the result would
go into an 'implied register' that was determined by inverting the last bit
of the register selector. So you could add mm0 and mm2 and the result would
be in mm1. NASM seems to have then documented, but I don't know if anyone
uses these.