rcd@ico.ISC.COM (Dick Dunn) (05/25/89)
In article <970@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes: > Here lies the rub; they are descriptors, not pointers. In particular, the > rings are in the middle of the descriptor, and this makes reinterpreting > the descriptor as a pointer hard, because pointer arithmetic is not easy... > ...It is not impossible, and indeed > you have large/huge "models", etc..., but not pleasant. A "pointer" on the 286 in small model is the same as the 8086--it's a 16-bit value...which, as Grandi explained, is no big deal. In the larger models, a pointer is a 32-bit value, and there's really no problem with that; it just doesn't look like an integer. (But it doesn't need to.) For large model, the pointer arithmetic in C really isn't bad because ==>You do NOT need to do inter-segment calculation. If you take a good look at how C's pointer arithmetic is defined, you'll see it doesn't allow you to go about subtracting two arbitrary pointers. They have to point within the same object--and the rule for large model is that no object exceed a segment. Therefore, pointer arithmetic only affects the offset part of a pointer. The one nasty about large model is that if you do it truly correctly, you either can't have a 64 Kb object in a C program, or pointer-increment becomes expensive. Reason: C allows calculation of a pointer one object beyond the end of an array. If you just increment the offset part, it will wrap to zero and a comparison will fail. It IS possible to increment the offset and propagate the carry into the segment part. Because (as Grandi noted) there are funny bits in the bottom of the segment value, you'll end up constructing an invalid pointer. However, it will give correct ordering comparisons if you use a 32-bit compare, and it doesn't matter that it's an invalid address because you can't dereference it anyway. These changes, while appreciably increasing the cost of common pointer operations, are nowhere near as costly as implementing full 32-bit pointer arithmetic (as in huge model). Huge model--which allows arrays to be larger than a segment--is seriously ugly. Maybe I'm lazy, but I wouldn't even want to contemplate implement- ing it. It would hardly be worth the effort in the compiler, given (a) how slow it would be, of necessity, and (b) the limited usefulness, given the existence of the 386. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...CAUTION: I get mean when my blood-capsaicin level gets low.