Integer conversions too pedantic in 64-bit
Walter Bright
newshound2 at digitalmars.com
Wed Feb 16 17:52:34 PST 2011
Don wrote:
> Walter Bright wrote:
>> Don wrote:
>>> [1] What was size_t on the 286 ?
>
>>
>> 16 bits
>>
>>> Note that in the small memory model (all pointers 16 bits) it really
>>> was possible to have an object of size 0xFFFF_FFFF, because the code
>>> was in a different address space.
>>
>> Not really. I think the 286 had a hard limit of 16 Mb.
>
> I mean, you can have a 16 bit code pointer, and a 16 bit data pointer.
> So, you can concievably have a 64K data item, using the full size of
> size_t.
> That isn't possible on a modern, linear address space, because the code
> has to go somewhere...
Actually, you can have a segmented model on a 32 bit machine rather than a flat
model, with separate segments for code, data, and stack. The Digital Mars DOS
Extender actually does this. The advantage of it is you cannot execute data on
the stack.
>> There was a so-called "huge" memory model which attempted (badly) to
>> fake a linear address space across the segmented model. It never
>> worked very well (such as having wacky problems when an object
>> straddled a segment boundary), and applications built with it sucked
>> in the performance dept. I never supported it for that reason.
>>
>> A lot of the effort in 16 bit programming went to breaking up data
>> structures so no individual part of it spanned more than 64K.
>
> Yuck.
> I just caught the very last of that era. I wrote a couple of 16-bit
> DLLs. From memory, you couldn't assume the stack was in the data
> segment, and you got horrific memory corruption if you did.
> I've got no nostalgia for those days...
I rather enjoyed it, and the pay was good <g>.
More information about the Digitalmars-d
mailing list