Re: master 3ed79cd: Separate bytecode stack

[Mattias Engdegård]

14 mars 2022 kl. 18.15 skrev Eli Zaretskii <eliz@gnu.org>:

> I'm talking about the 'fp' array, where you store values at least some
> of which seem to be pointers to Lisp_Object.  But the storing function
> treats them as integers:

I did try to explain this but evidently without skill. Let me try again:

What you call "the 'fp' array" is the fixed-size part of a stack frame, which 
needs to store a few values of types `Lisp_Object`, `Lisp_Object *` and `const 
unsigned char *` in slots of type `Lisp_Object`. This is nothing unusual: we 
store pointers in Lisp_Object values everywhere in Emacs and use XIL (etc) to 
do so. Don't get yourself hung up on the fact that we take the route via 
integers; that's what we do for Lisp strings, vectors etc as well.

> Why do you need to do that?  Why not store the pointer itself in the
> first place, and make 'fp' be array of pointers to pointer to
> Lisp_Object?

Because we use a part of the overall stack which is an array of Lisp_Object, 
and in C we can't cast between an array of unions and a union of arrays -- or 
rather we could try, but if something as benighn as storing pointers in a 
Lisp_Object makes you squeamish then this stunt would be much worse (as well as 
technically dubious for all sorts of reasons).

> My second question was: if you do need to store sometimes a pointer
> and sometimes a Lisp_Object that is actually an integer, why not use a
> union that will allow you to do both cleanly and safely, in effect
> doing all the type-casting and stuff for you?

There appears to be a misunderstanding here. The data stack of each stack frame 
must be an array of Lisp_Object; it cannot be anything else. That's why the 
overall stack has that type; the frame metadata just uses a few slots between 
each local data stack. Since the data stacks vary in size, the location of the 
frame metadata in the overall stack isn't statically known.

I mentioned another possibility that is cleaner in some respects; I'm attaching 
a tentative patch. It uses a bona fide struct for the metadata and uses 
hand-placement of the data stacks. The generated code should be identical but 
might actually be better with the patch for various reasons.

>> 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?
> 
> What do you mean by "flexible array struct members"?  Please show a
> code snippet.

I'm sure you know it well, it's the ability to put an incomplete array 
declaration as the last member of a struct, as in:

 struct S { int n; float a[]; };

which roughly means the same thing as declaring that array to be of size zero.
It's not required in our case but would make the next_stack function (see 
patch) go away.

stack-metadata-struct.diff
Description: Binary data