[fpc-other] Stanford Pascal Compiler successfully ported to Windows, OS/2 and Linux

[Alexander Stohr]

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.