Re: master 3ed79cd: Separate bytecode stack

[Eli Zaretskii <eliz@gnu.org>]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Mon, 14 Mar 2022 16:56:20 +0100
> Cc: emacs-devel@gnu.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.

I don't think you answered my questions, or did I miss something?

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:

  INLINE void
  sf_set_ptr (Lisp_Object *fp, enum stack_frame_index index, void *value)
  {
    fp[index] = XIL ((uintptr_t)value);
  }
  INLINE void
  sf_set_lisp_ptr (Lisp_Object *fp, enum stack_frame_index index,
		   Lisp_Object *value)
  {
    sf_set_ptr (fp, index, value);
  }

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?

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?

> 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.