Am 25.12.2016 um 11:50 schrieb Mark Morgan Lloyd:
On 25/12/16 10:00, Alexander Stohr wrote:
Am 2016-12-24 um 15:20 schrieb Bernd Oppolzer:

The first answer for such operators often is: use the right container
for the value you are in need and avoid all those operators.

Bear in mind that this is very old code that Bernd is maintaining, and long predates any concept of objects or of containers other than Pascal records.

Is the your lower end of those module touching on a system API level for
that?
(e.g. the Linux ABI, OS/2 system peronality, WIN32 api - rather than
malloc()/free() as a C standard library provides it)

Again, bear in mind that one of his major targets is a late-70s vintage IBM CMS, which predates most APIs as we know them (in fact, long predates the terms API and ABI themselves :-)

Thank you for your feedback.

I'm aware of all the concerns you have.
That why I wrote about "pandora's box".
Indeed I'd prefer to use the pointer arithmetic facilities only in certain
restricted circumstances, when this seems the best way to go and all
other (more indirect) ways to get the work done are still more clumsy
and more difficult to understand.

Anyway, it's now possible - for example - to access an array by moving
a pointer over the elements, but I, too, believe, that that's not how it should
be done, regularly. 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.

For your second question regarding the system API:

on the mainframe, the lower end of the LE storage management consists
of the GETMAIN and FREEMAIN macros; that is, the storage management
provided by the operating system. I provided for test purposes two
functions ALLOCX and FREEX which map directly to GETMAIN and FREEMAIN;
this worked, but was very slow. The LE storage management is optimized
for C and C++ and tries to support many small areas of storage, minimizes
fragmentation and optimizes performance. See this IBM presentation, which
is mirrored on my web site:

http://bernd-oppolzer.de/stackheap.pdf

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.

ALLOCX/FREEX goes directly to GETMAIN/FREEMAIN (which is slow), but
ALLOC/FREE implements the LE solution for malloc/free, which is
significantly faster.

The port of ALLOC/FREE to WIndows etc. still has to be done; maybe there
is no need to re-implement the LE solution, because the normal malloc/free
which is available to the interpreter may be acceptable regarding performance;
so ALLOCX / FREEX could simply be the same as ALLOC / FREE on the PC.

You can find the source of PASLIBX, which implements the LE solution in
Pascal, here:

http://bernd-oppolzer.de/paslibx.pas

See resources paragraph of my Stanford Pascal related web site:

http://bernd-oppolzer.de/job9.htm

Feel free to ask if you have more questions or suggestions.

Kind regards
and good christmas times to you, too

Bernd

_______________________________________________
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Reply via email to