Re: master 3ed79cd: Separate bytecode stack

[Eli Zaretskii]

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