Hi Bart,

> sbrk is a little deceiving here since it just administrates a
> high-water mark and does not allocate memory from DOS:
> old:
> https://github.com/tkchia/newlib-ia16/blob/e7c08882834a41d848698a19deae49089c2dab17/libgloss/ia16/dos-sbrk.c
> which only returned NULL if heap ptr went beyond 64K (the libc for
> ia16-elf-gcc started very bare bones in this respect!)
that should be fine then.
however IIRC MSC sbrk() would (try to) expand the allocated DOS
memory to grow the stack; this would not work well with command
XMS-SWAP.

> new (just changed by TK Chia)
> https://github.com/tkchia/newlib-ia16/blob/newlib-2_4_0-ia16-tkchia/libgloss/ia16/dos-sbrk.c
> malloc returns NULL when the end of the heap is reached but this is
> not always checked properly in freecom, but at least it does not grow
> into the stack any more.

> One could easily swap heap and stack in ia16-elf-gcc though I think we
> would just see different memory corruption, stack can then go corrupt
> other data or even code.

possibly a misunderstanding by me: if the stack and heap have clearly
defined, separate areas, you are absolutely right. (it made debugging
somewhat easier that REN destroyed always the same data, but that's a
minor detail).

I had understood 'heap grows up toward stack' as some sort of
optimization so that the heap can grow at the cost of stack and vice
versa.

> (that still leaves Turbo C which also grows heap to stack.. and of
> course protected mode OSes do it but with virtual memory protection
virtual memory stack protection is really cool (at least in the MSVC
implementation which happens to be the only one that I am
knowledgeable in); all stack checking without any cost.

Tom




_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to