On Sat, May 9, 2015 at 1:38 PM, <u-vpoa@xxxxxxxx> wrote:
> On Sat, May 09, 2015 at 01:50:44PM -0400, Jody Bruchon wrote:
>> On 5/9/2015 1:47 PM, u-vpoa@xxxxxxxx wrote:
>> >IOW, as much as I can see, the binary is built correctly and it is
>> >the memory allocation by the kernel which looks surprizing.
>
>> It is my understanding that bcc assumes DS=ES=SS and both stack and heap
>> data use the same code segment.
>
> Yes, this is fine.
>
>> How did you determine the memory usage of
>> the program to be 60K? Does that include all usage or only heap usage?
>
> I counted the approximate size of the static and allocated data
> objects and also tested. This includes all the data ("data+bss"+heap+stack).
>
> This worked fine with separate i/d on Venix/86 on IBM PC XT, where DS=SS
> and heap and stack grew from the opposite ends of the segment, heap from
> the bottom up and the stack from the top down (the hole in the middle if
> big enough was used for other processes' data, not wasted iirc).
>
> Venix also had kernel support for ES as extra data of a process so
> f.i. access to the graphic memory was done via ES. The compiler was not
> involved in these tricks, it just did not use ES.
>
> Rl
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Compile with flags
-i -H E000
Flag H controls the size of BSS.
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
