Xref: utzoo comp.sys.ibm.pc:22830 comp.sys.intel:644 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!oliveb!olivej!rap From: rap@olivej.olivetti.com (Robert A. Pease) Newsgroups: comp.sys.ibm.pc,comp.sys.intel Subject: Re: correct code for pointer subtraction Message-ID: <35614@oliveb.olivetti.com> Date: 6 Jan 89 03:40:51 GMT References: <597@mks.UUCP> <3845@pt.cs.cmu.edu> <18123@santra.UUCP> <142@bms-at.UUCP> <6604@killer.DALLAS.TX.US> <51@rpi.edu> <35495@oliveb.olivetti.com> <64@rpi.edu> Sender: news@oliveb.olivetti.com Reply-To: rap@olivej.UUCP (Robert A. Pease) Organization: Olivetti ATC; Cupertino, Ca Lines: 31 In article <64@rpi.edu> kyriazis@turing.cs.rpi.edu (George Kyriazis) writes: | |>The code generated by MSC 5.1 is shown below. |> |> [ .. some additional code .. ] |> |>mov ax,_ind3 ; diff = &b[ind3] - b; /* ind3 = 30000 */ |>shl ax,1 |>add ax,OFFSET DGROUP:_b |>sub ax,OFFSET DGROUP:_b |>sar ax,1 |>mov WORD PTR _diff,ax |> |> | |The SAR is the bug I was talking about. It should've been SLR (assuming |that SAR means Shift Arithmetic Right, SLR would mean Shift Locical Right), |shifting a 0 from the left (if such an instruction exists). Or they could |equally well put an AND ax, 0x7fff (excuse me if my 8088 is wrong) after |the SAR. This is not where the problem is. The problem is not with the SAR but that the overflow flag is not checked after the SHL instruction. In this case, with the index of 20000 or 30000, the SHL changes the sign bit. Because the sign bit changed, the overflow flag is set. Exception processing should have been included after the SHL to check for overflow and deal with it properly. Robert A. Pease {hplabs|fortune|microsoft|amdahal|piramid|tolerant|sun|aimes}!oliveb!rap