Path: utzoo!attcan!uunet!lll-winken!ames!killer!rpp386!dalsqnt!usl!ralph!pja
From: pja@ralph.UUCP (Pete Alleman)
Newsgroups: comp.lang.c
Subject: Re: correct code for pointer subtraction
Summary: Works on K&R's compiler
Message-ID: <372@ralph.UUCP>
Date: 8 Jan 89 18:03:12 GMT
References: <597@mks.UUCP> <8377@bloom-beacon.MIT.EDU> <8455@sequent.UUCP> <2237@iscuva.ISCS.COM> <609@mks.UUCP> <2245@iscuva.ISCS.COM> <22 <2254@iscuva.ISCS.COM>
Reply-To: pja@ralph.UUCP (Pete Alleman)
Distribution: na
Organization: Home Sweet Home, Lafayette, LA
Lines: 57

In article <2254@iscuva.ISCS.COM> carlp@iscuva.ISCS.COM (Carl Paukstis) writes:
>In article <22905@watmath.waterloo.edu> rwwetmore@grand.waterloo.edu (Ross Wetmore) writes:
>>In article <2245@iscuva.ISCS.COM> carlp@iscuva (Carl Paukstis) writes:
>>>Eric Gisin at Mortice Kern Systems writes:
>>>>How come I can't find a compiler that generates correct
>>>>code for pointer subtraction in C on 8086s?
>>>>Neither Turbo, Microsoft, or Watcom do it right.
>>>>
>>>>All of the compilers I tried computed a 16 bit difference,
>>>>then sign extended it before dividing.
>>>>This does not work if the pointers differ by more than 32K.
>                                                          ^^^ BYTES!
>>>
>>>(NOTE CRITICAL POINT FOR ERIC'S COMPLAINT:  the difference between s and
>>>s+10000 is 60,000 bytes - easily less that the 64K segment limit)
>
>>  The 64K segment limit has little to do with it. The 16 bit architecture
>>ie 16 bit _int_ is the determining factor.

But on a 16 bit machine you have the 16 bit result AND A CARRY FLAG.  That
gives the full 17 bit representation needed for the signed result!

>Which point was that?  What DOES happen in other 16-bit-int environments?
>Would somebody care to run Eric's example and let me know the outcome? 

I tried this simple program on a PDP-11 running K&R's V7 compiler:

	int a[20000];
	main ()
	{
		printf ("%d\n", &a[20000] - &a[0]);
	}

Sure enough, it gets the right answer! (20000)

Here is an example of the proper code on a 16 bit machine:
	_main:
		jsr	r5,csv
		mov	$-61700+_a,r1
		sub	$_a,r1
		bic	r0,r0
		sbc	r0
		div	$2,r0
		mov	r0,(sp)
		mov	$L4,-(sp)
		jsr	pc,*$_printf
		tst	(sp)+
		jmp	cret

The problem is NOT a limitation of the processor!  Some compilers just
generate WRONG CODE.  (I'm glad such stupidity is usually restricted to
IBM FECES and MESSY-DOS)

-- 
Pete Alleman
	ralph!pja or
	digitran!pja