Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site stl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!ukc!stc!stl!dww
From: dww@stl.UUCP (David Wright)
Newsgroups: net.bugs,net.micro,net.micro.pc
Subject: Re: 8086 family CPU bug
Message-ID: <190@stl.UUCP>
Date: Wed, 10-Jul-85 16:10:50 EDT
Article-I.D.: stl.190
Posted: Wed Jul 10 16:10:50 1985
Date-Received: Sat, 13-Jul-85 11:02:47 EDT
References: <1190@hcrvx1.UUCP>
Reply-To: dww@stl.UUCP (David Wright)
Organization: STL,Harlow,UK.
Lines: 18
Xref: watmath net.bugs:654 net.micro:10983 net.micro.pc:4520
Xpath: stc stc-a

In article <1190@hcrvx1.UUCP> hugh@hcrvx1.UUCP (Hugh Redelmeier) writes:
>All 8086 manuals I have read say that shift instructions set
>the flags to reflect the value of the result.  All the chips
>that I have tested (8086, 8088, 80186) do not set the flags
>if the shift count is zero. 

1 - If I remember rightly, the 8086 (et al) Users Guides say that for count of
0 "the result is undefined" - in practice you seem to have discovered that the
result is  (not even set flags).   I think it is very bad to have
undefined results unnecessarily, but at least it's a "feature" not a bug
(a "feature" is a bug that you documented .... ).  I guess the C manual you're
using didn't get round to documenting it - not Intel's fault if their "feature"
wasn't recognised!

2 - I guess one reason Intel haven't bothered to fix this "feature" is that 
their PL/M-86 compiler isn't (usually) upset by such things, because it can
almost always optimise out shift 0 anyway, and the C example you gave is pretty
unlikely to appear in PL/M.