Am 2016-12-25 um 21:42 schrieb Bernd Oppolzer:
Thank you for your feedback.
Thank you for your kind andswers.
BTW, I had to remove some sort of self check from the
Stanford Pascal runtime; it checked (before), that pointers only pointed
to the valid range of heap addresses; because the "traditional" heap
consisted
of one contiguous segment, this was very easy to implement. But I had to
remove this check, because pointers now can point to auto variables,
static variables, "new" alloc areas etc. as well.
It would still work for some applications. But they would be few.
The vast majority of real use projects probably tend to break those box.
So if it was an option with an enable switch, most would disable it.
Probably for that reason it would never be worth keeping it at all.
The problem, why I had to add this to the Pascal runtime, was: the
original
Stanford Pascal runtime only had functions new, mark, and release.
Release
releases all storage which was required since the last mark call - but
there
is no invidual "free" of areas. But I wanted to port an application to
Stanford
Pascal which required invidiual allocs and frees (like C malloc/free).
I decided
to add alloc/free and leave new/mark/release untouched for the moment,
because it is used in the compiler.
So it was created more like a stack allocator. The allocations were
local to the
functions or context they were allocated in and at some waypoint
(exit/return)
all of them were released. Thats not a generic universal heap design but
rather
goes to the level where gaps of sometimes named but then unused items
increase over time
and on persistent would need some garbage collection (time loss!) any
now and then.
But for that design as above growth and shrinkage is determined by the
code path.
Under some conditions the growth might be very determined
but the shrinkage is always very fixed whilst beeing much rarer.
(I feel a little similarity to older stack rewinding concepts in C
exception/resume features.)
I see you did wise to keep those items out of yournew codes for the project
whilst keeping it untouched for the moment in the existing codes that
dont interfere.
Do you see a good chance to use some larger existing code bases and test
suites for verifying the compiler?
Do you have some heap tracking functionality inside so that e.g. "1234
heap Bytes lost" it printed at exit?
Is there a some debug option for stack max size tracking?
Is there something for stack/heap object out of bounds writes/access?
(thinking of magic word fences in between, and of heap sanity checking)
Regards, Alex.
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
