SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?


To: Jurgen who wrote (39907)11/10/1997 10:32:00 PM
From: Gary Ng  Read Replies (1) | Respond to of 186894
 
5speed, Re: 1. error message: your program cause ...

Now if you see this, it would be no problem. The problem
is that it is not catched and there is no chance to see
what so ever error message.

Gary



To: Jurgen who wrote (39907)11/11/1997 2:09:00 AM
From: Uncle Mikey  Read Replies (2) | Respond to of 186894
 
On six attempts : I have found that if I tie the laces of my shoes together and then run full speed ahead at a brick wall while blindfolded I:

1. Smashed into the wall 2 times (once requiring stiches)
2. Missed the wall entirely once.
3. Fell to the ground well short of the wall 3 times.

My shoes are obviously defective.

Nike needs to do a costly recall.

Uncle Mikey



To: Jurgen who wrote (39907)11/11/1997 6:26:00 AM
From: ed  Read Replies (1) | Respond to of 186894
 
Mr. nospeed:

If you are a real expert in computer, both hardware and software, you will realize that that are many many ways to crash a computer by writting certain binary codes in certain registers at certain time during the
operation. To me, this what you called a bug is really no bug at all, only one of the many ways you can use to crash your computer on purpose.



To: Jurgen who wrote (39907)11/11/1997 8:47:00 AM
From: Barry A. Watzman  Read Replies (1) | Respond to of 186894
 
Giving a "g" (go) command from the debugger with the ip (instruction pointer) pointing to anything other than a valid code sequence with a normal termination at the end will and should crash any system not running in protected mode, be it a Pentium (with the bug) or a Pentium Pro or Pentium II (both of which do not have the bug). The difference here, which is difficult to fully explain unless you are moderately knowledgeable, depends on your operating system and whether it uses protected (WinNT) or unprotected (Win95) mode.

Under Windows 95, even if the "bug" did not exist, the system would be expected to crash most of the time, because even though the processor was not locked up, it would be executing random memory contents, and this would result in a crash the vast majority of the time.

Under Windows NT, the same thing would happen to the active task (process, user [VERY loosely]), however if the processor itself was not locked up it should "catch" the wayward process and terminate it, with other tasks/processes/users not being adversely effected. If, however, the processor itself "locks up", then EVERYTHING on that computer will stop cold until it is rebooted.

Since I presume that you are running Windows 95, it's not surprising that your system appeared to crash even though it is a PII, which does not have the bug. The reason is that it can be very difficult to distinguish between a "software crash", in which the system becomes totally non-responsive even though the processor is still running, and a processor lockup, in which the processor actually stops running. That's why this bug is completely and totally irrelevant to anyone who is not running a protected mode operating system (Windows NT, for example). It requires the execution of invalid opcodes, which would be EXPECTED to send the running task/user/process "off into the weeds". What is not expected is that other processes (essentially, other users) would be impacted as well.

Barry Watzman