Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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: Paul Engel who wrote (39555)	11/8/1997 1:36:00 AM
From: Buy Low Sell Hi	Read Replies (1) \| Respond to of 186894

Paul, I disagree again. It is certainly possible the processor can attempt to execute code (or data) from a "bogus" location if the stack is messed up. Two things will happen: 1) execution of unintended valid instructions or 2) an attempt to execute an invalid instruction. Valid instructions could potentially trash memory, write to I/O, etc., but the use of segment descriptor tables for each task can prevent that. Invalid instruction should generate a processor exception and be trapped by the OS. The whole point of a protected mode operating system is to prevent bad code in a user task from crashing the system. This bug circumvents that by locking up the processor from a user task. BLSH

To: Paul Engel who wrote (39555)	11/8/1997 1:50:00 AM
From: Ali Chen	Respond to of 186894

Paul, <If a program intentionally places a bogus memory address on the stack, and then pops that value into the Code Segment Register, the processor will crash - attempting to execute code from some bogus location.> Paul, you are sadly mistaken here. Have you ever heard of "system space" and "user space" on 386 and above processors? Ring "0", Ring "3"? Does it rings something to you? Apparently not. Here is the point you are uncapable to comprehend due to your ancient computer knowledge: a code executed in "user space" should NEVER crush a multiuser system if the CPU CORRECTLY reports user attempts to execute invalid and privileged codes. These "exception" interrupts were specifically invented to prevent the scenario you described. This scenario happens thousand of times everywhere and everytime, and those multiuser systems are working for months and not crushing. Do not confuse these advanced architectures with 8080 toy you studied at school. The discovery of F00FC7C8 bug changes this. Although it is probably true that none of the current compilers would generate this weird code, some people will use it intentionally from now. All Pentums do not trigger the exception interrupt in this case. This is the ugliest bug ever observed in computer industry. There is no workaround except to redesign the microcode and replace the chip. There is no excuse for Intel for not testing all possible 4-byte opcode combinations, it is not too much for a computer today. Processors are machines - not bullet proof automatons. Normal processors are state machines and could be bullet-proof if properly validated against clear specifications.

To: Paul Engel who wrote (39555)	11/8/1997 10:33:00 AM
From: steve h	Read Replies (2) \| Respond to of 186894

Paul, Ali, and anyone else who would like to comment, Re:>>Pentium BUG<< If illegal code can be generated to crash a pentium system, what is the general impact to PC use? and can you comment on the following perspective. I don't know and would never claim to know, but, if illegal code exists that can crash pentium CPUs, isn't it possible that illegal code exists that can crash CPUs manufactured by AMD, Cyrix, Motorola and any other mfgr? If the above statement is true, or could be true. What would you do? You certainly can't assume that replacing all Intel cpus with AMD processors would solve the problem. You may just introduce a different problem. Also, there are 2 perspectives I don't buy into. First, Intel knew this all along and left it as a means to increase conversion to PII. It's just too risky, especially if you're "paranoid". Second, Intel is the biggest and makes the most so this should have never happened. I have never purchased or built a perfect product. I do expect due diligence and devices should perform within their expected or specified limits. If the pentium bug is real, can software (or OS) be written to ensure these types of commands are not executed? Does it open up another business opportunity like virus protection? All comments are welcome. And if it isn't inherently obvious to the most casual observer,these are my very humble observations and opinions. I am not a hw or sw expert and don't even play one on tv. thanks, steve h