Iwas reading this article today on the Microsoft website about the mysterious x86 ENTER instruction. The article states that it's primary purpose is to support Pascal and similar compilers to allow for preserving local variables on the stack when using with nested functions.

Here is the article:

https://devblogs.microsoft.com/oldnewthing/20231211-00/?p=109126

Do any of the compiler devs know if Pascal programs for the x86 instruction set are using ENTER and its second argument to the best possible effect? I am curious.

Op 12-12-2023 om 17:48 schreef Anthony Walter via fpc-pascal:

No, and if they do, they don't do in the way they are meant to. These are very old instructions and the intended use has a nesting limit (of 32 levels iiirc).  Because of that limit, modern compilers don't use them.

Some forms of enter and leave are use as peephole optimizations.

32 static levels is MUCH, IMO.

I have an old compiler here (New Stanford Pascal, originating from Pascal P4), which has only 9 static levels.
Dynamic nesting is unlimited, of course.
This was never a problem for me; every seperately compiled module starts again at level 2.
The only program which comes close to the 9 level limit is the 26.000 lines compiler phase 1.

My compiler copies and restores the addresses of all 9 stack frame levels, but only when passing procedure and function parameters; otherwise the addresses of the stack frames are located at certain (well known) places which can always be found,
and only individual stack frame addresses have to be set and restored when entering or leaving a function.

I had the idea to extend the limit from 9 to 20, but there was no hard requirement so far, so I left , for example, and other "modern" languages, have a static limit of 1.

Kind regards

Bernd

Anthony Walter wrote

Do any of the compiler devs know if Pascal programs for the x86 instruction set are using ENTER and its second argument to the best possible effect? I am curious.

FPC used it in the past, but stopped using it because
1) on modern processors the expanded sequence is much faster than the single enter instruction
2) enter is limited to allocating stack frames of 32kb or 64kb (so we had to support non-enter-based entry code anyway)
3) IIRC the Linux kernel doesn't support the enter instruction (if it requires a new page to be allocated for the stack, I believe it can crash the program)

TP did use it.

Jonas

I wrote a comment on the original Microsoft dev blog (for a non-Pascal community), maybe it's of interest here, too ...

In normal Pascal procedure calls, such a vector of stack frame addresses is not needed. A standard Pascal runtime knows all the time about the current stack frame address of – say – the procedure which is currently active at static level n. This information is called the DISPLAY VECTOR and there is no need to copy the display vector on procedure calls, because it is stored at a well-known location inside the runtime. You only have to replace the stack frame addresses of the current static level, when you enter or leave a procedure (and maybe set the new current static level).

What makes things more complicated, are procedure and function PARAMETERS (in Pascal), that is: procedures that are passed as parameters to other procedures. In this case, it is indeed necessary to COPY THE COMPLETE DISPLAY VECTOR, because it is not possible to predict what static level the procedure (which is passed as a parameter) has. So maybe the ENTER instruction is meant for such use cases.

Some of the old Pascal compilers didn’t allow procedure parameters (or implemented them badly) due to these difficulties. To see, if your (Pascal or Algol) compiler implemented procedure parameters correctly, you can use the “Man or Boy” test: https://en.wikipedia.org/wiki/Man_or_boy_test