Path: utzoo!attcan!uunet!husc6!im4u!ut-sally!ico!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.lang.c
Subject: Re: Address arithmetic on the '286 (was: Is &a[NTHINGS] legal)
Summary: "huge" won't solve it all
Message-ID: <5272@ico.ISC.COM>
Date: 20 May 88 22:42:39 GMT
References: <4554@ico.ISC.COM> <274@ateng.UUCP>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 37

...> > is me; > is Chip Salzenberg
> >[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).

Actually, I should have said "a compiler could form an address..." since I
don't know of any that do, in anything less than "huge" model...
> Your idea would work, but only if all pointer _arithmetic_ were done in
> 32 bits as well...
Chip is pretty much right; there are some cases where you could optimize it
to 16 bit operations if you wanted to spend the effort.

> 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.
True.

> I'd rather just declare individual arrays as "huge" and leave 16-bit
> pointer arithmetic as the default.
This doesn't quite solve the original problem.  If you're going to have a C
that conforms, you DO have to use huge model for a 64K array.  However, you
also need a shim at the end of a segment, or somehow you need to keep all
arrays away from the end of segments.  Even if the array only has ten bytes
in it, if it ends up jammed against the end of the segment (which is likely
to be a linker decision, not a compiler decision, BTW) you won't be able to
form an address one beyond the end.

> I'd rather lose conformance than performance.

I'd rather have it right before it's efficient.  (Not entirely at variance
with Chip's view, just a different emphasis.)
-- 
Dick Dunn      UUCP: {ncar,cbosgd,nbires}!ico!rcd       (303)449-2870
   ...Never attribute to malice what can be adequately explained by stupidity.