[fpc-devel] i8086 huge pointers

[Nikolay Nikolov]

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