🚀 go-pugleaf

In article <19820@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes:
>>Seriously, assuming info on the alleged instruction wasn't freely available,
>>what's the big deal?  From what I've heard, the instruction was intended for
>>the testing of the component and was never intended for general use.  So
>>someone figured out it exists, or some large customer wanted to do their own
>>in-coming testing and the info leaked out.  How does that put an obligation
>>on Intel to provide that info to anyone who asks?
>
> ...
>
>I understand Intel's concern that they don't want to make something a part
>of the architecture that they don't intend to support in future products.
>The solution to this is simple; the documentation just states that this
>is an implementation-specific function, is not part of the architecture, and
>should be used with great care and only after testing for processor type.
>
>Michael Slater, Microprocessor Report


This suggestion has problems in that whether you say `implementation-specific'
or not and add copious disclaimers and warnings,  people will use the feature
and then complain bitterly (repleat with character assasinations) when it
gets removed.  The experience with MS-DOS is instructive here: there are 
undocumented `features' that are impossible to remove because somebody groveled
through the code, figured out what was going on  and took advantage of it
in a popular piece of SW.  If it gets changed they scream loud and long in
public.  I've heard such statements like `you have no right to do this' and
`you are trying to put me out of business' and `typical arrogant SOBs'.  How
does one improve a product with these kind of constraints?.  And, yes, loadall
eats microcode store big time. Intel is doing exactly the right thing in
trying to prevent widespread use of loadall.


Phil Barrett
of course, the above opinions are mine and not those of Microsoft.