Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!gatech!uflorida!usfvax2!codas!ateng!chip
From: chip@ateng.UUCP (Chip Salzenberg)
Newsgroups: comp.lang.c
Subject: Address arithmetic on the '286 (was: Is &a[NTHINGS] legal)
Message-ID: <274@ateng.UUCP>
Date: 17 May 88 19:59:54 GMT
References: <4554@ico.ISC.COM>
Reply-To: chip@ateng.UUCP (Chip Salzenberg)
Organization: A T Engineering, Tampa, FL
Lines: 36

Note:  this article is specific to the Intel 8086 and '286.

In article <4554@ico.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>[on the '286]
>...you might like to declare, say
>	char stuff[65536];
>
>[The compiler] can form an address &stuff[65536] which is usable for
>comparison--and address arithmetic--even though it's not a valid address
>(nor even a valid segment, for that matter).
>
>However--here, 286 compiler folks take note--it does require treating
>pointer comparison as a 32-bit operation for <, <=, >, >= (not just == and
>!=).

Your idea would work, but only if all pointer _arithmetic_ were done in
32 bits as well.  Take for example:

	static  char    foo[65536];
	main()
	{
		char *p = &foo[65536];
		p[-1] = 'a';
	}

However -- doing all pointer arithmetic in 32 bits would slow down _all_
pointer operations, even though the vast majority of them do not need it.
I'd rather just declare individual arrays as "huge" and leave 16-bit
pointer arithmetic as the default.

I know it's not fully conformant to dpANS.  Too bad.

I'd rather lose conformance than performance.
-- 
Chip Salzenberg                "chip@ateng.UU.NET" or "codas!ateng!chip"
A T Engineering                My employer may or may not agree with me.
  "I must create a system or be enslaved by another man's." -- Blake