Xref: utzoo comp.sys.ibm.pc:22754 comp.sys.intel:639 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!cornell!batcomputer!sun.soe.clarkson.edu!rpi!rpics!kyriazis From: kyriazis@rpics (George Kyriazis) Newsgroups: comp.sys.ibm.pc,comp.sys.intel Subject: Re: correct code for pointer subtraction Message-ID: <64@rpi.edu> Date: 4 Jan 89 16:45:29 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> Sender: usenet@rpi.edu Reply-To: kyriazis@turing.cs.rpi.edu (George Kyriazis) Organization: RPI CS Dept. Lines: 48 > >In MSC these examples reduce to a constant and the compiler >places the values as immediate data in the instruction.... > Ok, I give up. I didn't know that the compiler produces a constant for it. I just looked at the assembly code that a SUN4 produces and it also uses a constant for it. I guess compilers are smarter than I thought they are :-) >>I am not saying it is correct. Obviously the compiler is doing a signed >>division to get the result instead of the unsigned that it should do. > >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 > > Ok. The SHR is obviously a part of the array indexing (since an int is 2 bytes multiplication by sizeof(int)==2 is a left shift by one place). 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. Now excuse me about the blank lines, but I have to put some so rn accepts the article. Sorry :-) George Kyriazis kyriazis@turing.cs.rpi.edu kyriazis@ss0.cicg.rpi.edu ------------------------------