Re: master 3ed79cd: Separate bytecode stack

[Mattias Engdegård]

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?