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.