>> It is a bug for a processor to have any unassigned codes.
>
>In what way is it a bug? If all the codes are assigned, then future
>extensions become impossible.
Unassigned OP codes are properly given no-op execution and are
indicated as "reserved" in the programming documentation.
Best Regard
David Puryear <[EMAIL PROTECTED]> writes:
> No. From what I have read so far, P-Pro and PII is not effected, just
> Pentium(and MMX). It will be interesting to see how Intel handles this bug.
They only give a warranty that their chips are free from material
defects, not logic or microcode errors,
David Puryear <[EMAIL PROTECTED]> writes:
> Question: Can this code be placed in a Java/ActiveX program? Just wondering if
> I should disable them.
Java: No. Java is platform independent and thus one cannot embed
specific instructions.
ActiveX: Yes. This is Micro$oft technology, remember.
--
B
In article <[EMAIL PROTECTED]> you wrote:
: [EMAIL PROTECTED] writes:
: > Ted writes:
: > > Someone wondered (as one does) what might possibly happen if you tried
: > > the unassigned codes.
: >
: > It is a bug for a processor to have any unassigned codes.
:
: In what way is it a bug? If all the
On 09-Nov-97 Dan Hugo wrote:
I hat to be naive, but I've read a little bit about this bug (first on
www.news.com, and very little more on www.x86.org) and there is one
thing that is vague:
Are Pentium Pro and/or Pentium II also effected by this bug?
No. From what I h
I just tracked down a post to this mailing list from Tommy Lakofski that
wasn't on this thread, stating (from the linux.advocacy newsgroup) that
the problem is P5 only and does not effect PPro or PII.
I guess that's reassuring...
-dh
Dan Hugo wrote:
>
> I hat to be naive, but I've read a litt
The BugTraq post I read suggested that the P6 (Pro, II) does not have this
bug. Of course, there may be others...
On Sat, 8 Nov 1997, Dan Hugo wrote:
> Are Pentium Pro and/or Pentium II also effected by this bug?
-TL
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[E
I hat to be naive, but I've read a little bit about this bug (first on
www.news.com, and very little more on www.x86.org) and there is one
thing that is vague:
Are Pentium Pro and/or Pentium II also effected by this bug?
I would try it on my pro system, but I would rather not have to reset in
the
George Bonser <[EMAIL PROTECTED]> writes:
> If the instruction set is changed, the CPU part number should change. In other
> words, future extentions should be IMPOSSIBLE. Unused opcodes should execute a
> NOP or an instruction that causes the currently executing program to terminate
> in a known c
If the instruction set is changed, the CPU part number should change. In other
words, future extentions should be IMPOSSIBLE. Unused opcodes should execute a
NOP or an instruction that causes the currently executing program to terminate
in a known condition ... HALT? In this way, Pentium-N code
[EMAIL PROTECTED] writes:
> Ted writes:
> > Someone wondered (as one does) what might possibly happen if you tried
> > the unassigned codes.
>
> It is a bug for a processor to have any unassigned codes.
In what way is it a bug? If all the codes are assigned, then future
extensions become impossi
Ted writes:
> Someone wondered (as one does) what might possibly happen if you tried
> the unassigned codes.
It is a bug for a processor to have any unassigned codes.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail t
On 08-Nov-97 Ben Pfaff wrote:
> Shaleh <[EMAIL PROTECTED]> writes:
>> Barring malicious users, could these op codes have happened in
>> production code?
>
> At least according to the gas 2.8.1 sources, the instruction code
> 0x0f0f is not assigned to any instruction, so they should never appear
>
Shaleh <[EMAIL PROTECTED]> writes:
> Barring malicious users, could these op codes have happened in
> production code?
At least according to the gas 2.8.1 sources, the instruction code
0x0f0f is not assigned to any instruction, so they should never appear
in actual code.
--
Ben Pfaff <[EMAIL PROT
Barring malicious users, could these op codes have happened in
production code?
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
And there is probably such a bug with Pentium II that will be "leaked" as soon
as ITS replacement is widely available to spur upgrades.
Sorry if I seem so cynical. (Four systems 1-AMD, 1-Cyrix, 1-486, 1-Intel
Pentium.) The only Intel Pentium is an old P60 that is due for replacement
anyhow.
On 08
A slightly edited version of what a friend sent me:
Did you hear the latest buzz on the internet? A four
byte instruction will lock any true Pentium solid.
Try this c program:
char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
main () { void (*f)() = x; f(); }
So much for using Pentia for robust mu
17 matches
Mail list logo
