chip@ateng.UUCP (Chip Salzenberg) (05/18/88)
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
rcd@ico.ISC.COM (Dick Dunn) (05/21/88)
...> > 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.