CBFalconer wrote:
Frank Heckenbach wrote:
These are memory and runtime issues, and given that copying pointers is quite common in GPC, these effects must be analyzed precisely.
In Pascal, but not in C, you can force all pointer copying to be done via a subroutine, because there is an essential difference between pointers and VAR parameters. That subroutine will increase the reference count in the actual heap storage area by 1. At the same time you have to make all destruction, including destruction via procedure return and loss of local variables, decrement that reference count. If dispose finds a count greater than 1 it decrements and flags the storage as invalid, so that use by an orphan pointer will bomb. This means that access has also got to be via a routine to check that invalid flag. When anything decrements the ref to 0, the storage is released.
This complicates pointer copying and passing, but leaves the actual derefencing untouched. Note that a WITH statement effectively creates a pointer copy.
Indeed, in Pascal one can make it transparent to the programmer, not so in C. But the memory and runtime overhead is still there. And for GCC/GPC (which is not exactly known as the fastest compiler on earth, anyway), any change that would cause significant slowdown will have to be thought about very carefully ...
Another technique ties in with run-time checks. Any pointer use is validated by a routine, which effectively walks the list of allocated storage. If not found, the use is invalid and the system crashes. This again adds considerable overhead. It was kept disabled in PascalP because of that.
For this purpose, I prefer something like libefence. It's not 100% perfect (i.e., can only detect overruns or underruns at once), but has already found me some pointer bugs in my code.
Whatever you do, from checking to ignoring, Pascal should not have garbage collection. It does not have the wild pointer usage of C (and C++), and so can be controlled. GC brings in things like unexpected pauses which are fatal to any real-time or quasi-real-time use. If you are going to create the overhead for GC then you can better create the overhead for proper run-time checking.
Again, as I noted in another mail, we're talking about the MM used by the compiler itself. We have no intentions to change the runtime MM for GPC compiled programs, and I am aware that GC is not the right thing for every kind of program (in particular real-time programs as you said).
Frank