On 04/07/2014 03:51 AM, Max Nazhalov wrote:
Sunday, April 6, 2014, Nikolay Nikolov wrote:
NN> Back in the old days, I never used huge pointers, because I wrote in Turbo
Pascal,
NN> which didn't have them, so I don't have an opinion which way is better.
NN> So, which way should FPC for i8086 follow?
BP7 does not normalize pointers, since it targets DPMI16, where such
normalization is senseless.
Moreover, it uses special typed const "system.SelectorInc" to handle offset
overflows.
Under real mode, SelectorInc is barely $1000.
Under DPMI16 environment SelectorInc can be obtained by DPMI function
INT31h/AX=0003h (usually, it returns 8).
With this approach the whole pointer arithmetics is similar between real and
protected modes.
Ok, I just added this constant to the msdos rtl (r27497). However, as
far as BP7 compatibility is concerned, it doesn't really matter which
huge pointer model we use, because BP7 doesn't have a huge pointer type
and in fact, it doesn't even offer any kind of pointer arithmetic as far
as I know. But it's a good point that the pointer normalization, used in
Borland C works in real mode only. This means that if we follow that
way, huge pointers must be either entirely disallowed or behave
differently (i.e. like Microsoft and Watcom C, but by using
System.SelectorInc) in 16-bit protected mode. However, the Borland C
way, IMHO, does have some really nice advantages:
- If you pass a huge pointer to a function or interrupt routine that
expects only a far (not huge) pointer, it'll always be able to access at
least the next (64K-15) bytes of the object
- Free Pascal often generates code using [base + index + offset]
references to access record/object/class fields or array elements. This
will work nicely with normalized huge pointers, as long as the structure
itself does not exceed 64kb (which is currently not allowed in the
compiler). With MS/Watcom-style huge pointers, you could end up, after
some pointer arithmetic at Ptr($1234:$FFFF) and then when you
dereference the pointer and try to access some record member, you're
screwed.
Nikolay
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
