From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 3ed79cd: Separate bytecode stack Date: Mon, 14 Mar 2022 19:15:05 +0200 Message-ID: <83a6dsjw12.fsf@gnu.org> References: <83lexdlpjy.fsf@gnu.org> <447E1D53-FA02-4776-9730-507BCA1993FA@acm.org> <83h781lma9.fsf@gnu.org> <1EB42282-A67C-4C20-8E5D-BA8DA9A21E9C@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36943"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 14 18:16:21 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nToIu-0009R0-JS for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Mar 2022 18:16:20 +0100 Original-Received: from localhost ([::1]:54868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nToIt-00075m-9Q for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Mar 2022 13:16:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35048) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nToI7-0005sa-4m for emacs-devel@gnu.org; Mon, 14 Mar 2022 13:15:32 -0400 Original-Received: from [2001:470:142:3::e] (port=47140 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nToI6-0004eO-Pi; Mon, 14 Mar 2022 13:15:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=R8J9tY2rkG2iL6p03yMYOiR7PPEmez7oZrqu0cNQYhQ=; b=pGWP14Lj/aNXN9hHZ9zO 6vYSY1/otTDmPDqNe72uqIocsFqeR9psvDtZdxgmQenYh/YmOLlT+0UIuHxYa3z3dU2n1NzL1QLEh 5kFv4f7kMlYySNypRcHk7m0WGg1ZGYDdHZ+XqX8nApMrEF0kqwDe4MDmfv/WyXmhlQkNgr2kDBHow NLQ54jg48ymgmCkA5cj4DQOJ45vOegM946B/0ca2DQtKxqgeEicfiCq0my0Eb3xtSzfeJFL8r8fTW a4/O71hPtzabmLihoZNWNvhzta4da3PdROHdf71uBPXL5eHapZQrIE6M9QRE4tgK/O96VsrFWfVl6 pBKRlgF89NZyeA==; Original-Received: from [87.69.77.57] (port=4608 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nToHt-0001l7-1T; Mon, 14 Mar 2022 13:15:29 -0400 In-Reply-To: <1EB42282-A67C-4C20-8E5D-BA8DA9A21E9C@acm.org> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Mon, 14 Mar 2022 16:56:20 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:287158 Archived-At: > From: Mattias Engdegård > Date: Mon, 14 Mar 2022 16:56:20 +0100 > Cc: emacs-devel@gnu.org > > 13 mars 2022 kl. 19.50 skrev Eli Zaretskii : > > > 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.