Re: master 3ed79cd: Separate bytecode stack

["Mattias Engdegård" <mattiase@acm.org>]

13 mars 2022 kl. 19.50 skrev Eli Zaretskii <eliz@gnu.org>:

> The warning is gone

Excellent, thank you for testing!

>  What kind of pointers do you need to store in the
> fp array, why, and for what purpose?  And if you do need to do that,
> why not use a union?

Let's look at what we are doing. We switch to an explicit representation of the bytecode interpreter stack. Each stack frame is composed of two parts: a fixed-sized metadata record containing information such as where to continue execution after the function has terminated, and a variable-sized private data stack for the function. The size of that data stack is specified in the bytecode object.

Like most other interpreters and CPU hardware, we use the standard solution: reserve a block of memory for a stack and carve out stack frames from it as needed, with their two parts next to one another in each frame. The data stack part must be an array of Lisp_Object; here we have little choice. The metadata record consists of a few members each of which fits into the space of a Lisp_Object, which makes the current implementation fairly natural: store those in designated array slots.

There are alternatives, several of which have been tried. One which is basically an equivalent formulation of the same code is to use a C struct for the metadata, then allocate it and the local data stack out from a big untyped stack. This makes metadata access simpler and more type-safe, and eliminates the previously needed accessor functions (sf_get_lisp_ptr etc). The drawback is more casts between pointer types which is slightly more risky than the straightforward XLP etc conversions in the current code. On the other hand, it could actually be faster depending on how friendly the compiler is.

The latter alternative would become a little more palatable if we could use flexible array struct members on all platforms. Given that we assume C99, can we do that now?