From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_Paulo_Labegalini_de_Carvalho?= Newsgroups: gmane.emacs.devel Subject: Contributing to Emacs Date: Wed, 7 Sep 2022 14:01:06 -0600 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009f02d105e81bc663" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40275"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 07 22:02:51 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 1oW1G6-000AFc-Om for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Sep 2022 22:02:50 +0200 Original-Received: from localhost ([::1]:45292 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oW1G5-00030A-Rl for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Sep 2022 16:02:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oW1Ef-0001Oc-Ep for emacs-devel@gnu.org; Wed, 07 Sep 2022 16:01:21 -0400 Original-Received: from mail-ot1-x333.google.com ([2607:f8b0:4864:20::333]:40621) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oW1Ed-0001hN-DU for emacs-devel@gnu.org; Wed, 07 Sep 2022 16:01:21 -0400 Original-Received: by mail-ot1-x333.google.com with SMTP id z22-20020a056830129600b0063711f456ceso10983420otp.7 for ; Wed, 07 Sep 2022 13:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=7md1rZE2ESsYNUPeJCVCt18uGZAxLSDnUx3tzg3Tdx4=; b=iv6zXYeeMBKGYFYlziwRF3gs7vhiTijsKPMnMzWgFHwK3PefRGHD1cYb/8t5lMpYs8 0Su2f5zCd0Kl/YknrrZ7f2jvOV6XM4nHXyydcc5yPrbanbHq150npSflcsgX/b+TODzf 5FdbLLcApeERCo05MfHU17x58gvRFkh+vHcC9M/OoWzuXDg8m8S9jPmVTygKuD5I54in oBifTBqTPpWsIL5zWCCF/IQH7lBz+B7ZlSFkXjSsPon/wXgnBmjHen4Zlf64WdcOYcZR /EW2Rqhx1n+xCxS7zA61BVIqnjlXtw2vgdgeKaEis816aDOX7Gc/yMpcvpRV7VDmGrrf xtIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=7md1rZE2ESsYNUPeJCVCt18uGZAxLSDnUx3tzg3Tdx4=; b=4775YqhvsIDudMHgGjJ4ARoP2TYkUwoNc0U3PtJWOJ5f9qLe7FjWcAd9uqOu+MIb9G H27CxB+yKcNyid5kKP2Dq1i1LmCU3bp3hVedLGAOhlEd8mFhUqIllcGtMRbHfoL83bKH pxmHTjSjePfCtC28ZCjbE91DsaZOl2pZd4YM06afcrjLcbXnyUjIAuCTRIAUX9nGBpCz 6tdAQxvPC3hqe3d1OxeZCJb0lRh/oibsch0NqTxTnbhDKtlR2g6nmhvjN5aCaZR1oeiF bC6Lukd9n0uSf/7T3bnEQ3oM34gQ5ejYXxxumpoCCRYmxcbri6uUHRBIYnolB0cfXOPS hx0A== X-Gm-Message-State: ACgBeo2WGnarxpMqQCnexe0S3XzPI8Mxcb80ZdOyB9y1wjVrE6x9L8kv nENlVmWnDTmv54r7tFXyAwSyNGyIhmt7boeS+SPJ4LkaQW8= X-Google-Smtp-Source: AA6agR4PUiZfHcnfRNrcvFo+1kJfdVqb+WJ+018Ik/gsP4ZsoNfseRgSLiwzDdPk1yU8Q5TojZQ7DnTCa5d35eIpNkk= X-Received: by 2002:a05:6830:1482:b0:637:742:c083 with SMTP id s2-20020a056830148200b006370742c083mr2073242otq.102.1662580877622; Wed, 07 Sep 2022 13:01:17 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::333; envelope-from=jaopaulolc@gmail.com; helo=mail-ot1-x333.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:294876 Archived-At: --0000000000009f02d105e81bc663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I started using Emacs about 2 months ago. Now that I am comfortable with customizing Emacs, getting help, and Elisp, I would like to contribute to the project. I was looking at the file etc/TODO in the repo, and some items there caught my attention. For example, under 'Important Features' I found 'Add an "indirect goto" byte-code'. Is this still a desired feature or is it not required due to recent efforts towards native compilation? (In the negative case, please feel free to suggest another item for me to work on) If it is still desired I would like to work on it and would appreciate guidance. After taking a look at lisp/emacs-lisp/bytecomp.el,it seems that forms such as (let ((foo (lambda (x) bar))) (dosomething (funcall foo toto) (blabla (funcall foo titi)))) are compiled by calling byte-compile-let. Before generating the binding for foo, #'(lambda (x) bar) is compiled by calling byte-compile-push-binding-init, which in turn compiles the lambda to bytecode and pushes it to the stack. So to make it more concrete for my sake, I wrote the following form (let ((foo (lambda (x) (- x 1)))) (* (funcall foo 2) (- (funcall foo 3) 2))) and with disassemble inspected the generated bytecode by Emacs 28.1 byte code: args: nil 0 constant args: (x) 0 varref x 1 sub1 2 return 1 dup 2 varbind foo 3 constant 2 4 call 1 5 varref foo 6 constant 3 7 call 1 8 constant 2 9 diff 10 mult 11 unbind 1 12 return As far as I understood, the idea of the "indirect goto" here is to eliminate the calls on lines 4 and 7 and replace them with an indirect goto. And as per the TODO entry, the return in line 2 of the compiled lambda would also need to be replaced by a jump back. So here is where I am a bit lost. Currently, the compiled lambda bytecode lives in the *constant vector* and a reference(?) to it is pushed into the *evaluation stack* in line 0 (constant ). Thus, for the indirect goto idea to work, the bytecode of the lambda would need to be part of the bytecode of the let's body**. That way, a computed branch can branch into the lambdas code and it is possible to branch out of it when returning. Aside from guidance on implementing this, I would appreciate any pointers on how to adequately test it. Regards, --=20 Jo=C3=A3o Paulo L. de Carvalho Ph.D Computer Science | IC-UNICAMP | Campinas , SP - Brazil Postdoctoral Research Fellow | University of Alberta | Edmonton, AB - Canad= a joao.carvalho@ic.unicamp.br joao.carvalho@ualberta.ca ** Forgive me for the lack/miss use of terminology. --0000000000009f02d105e81bc663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I started using Emacs about 2 months ago. Now t= hat I am comfortable=C2=A0with customizing Emacs, getting help, and Elisp, = I would like to contribute to the project.

=C2=A0I was looking at th= e file etc/TODO in the repo, and some items there caught=C2=A0my attention.= For example, under 'Important Features'=C2=A0 I found 'Add an "indirect goto&qu= ot; byte-code'. Is this still a desired=C2=A0feature or is it not requi= red due to recent efforts towards native compilation? (In the negative case= , please feel free to suggest another item for me to work on)
If it is still desired I would like to work on it and would appreciate gui= dance. After taking a look at lisp/emacs-lisp/bytecomp.el,it seems that for= ms such as

=C2=A0(let ((foo (lambda (x= ) bar)))
=C2=A0 =C2=A0 =C2=A0(dosomething
=C2=A0 =C2=A0 =C2=A0 =C2=A0= (funcall foo toto)
=C2=A0 =C2=A0 =C2=A0 =C2=A0(blabla (funcall foo titi)= )))

are compiled by calling byte-com= pile-let. Before generating the bin= ding for foo, #'(lambda (x) bar) is compiled by calling=C2=A0byte-compile-push-binding-init, which in turn compiles the lambda to bytecode and pushes it to= the stack.

So to make it more concrete for my sake, I wrote = the following form

(let ((foo (lambda (x) (= - x 1))))
=C2=A0 (* (funcall foo 2)
=C2=A0 =C2=A0 =C2=A0(- (funcall f= oo 3) 2)))

and with disassemble inspected the generated bytec= ode by Emacs 28.1

byte code:
=C2=A0 args= : nil
0 =C2=A0 =C2=A0 =C2=A0 constant =C2=A0<compiled-function>=C2=A0 =C2=A0 =C2=A0 args: (x)
=C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 var= ref =C2=A0 =C2=A0x
=C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 sub1 =C2=A0 =C2= =A0 =C2=A0
=C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 return =C2=A0 =C2=A0
=
1 =C2=A0 =C2=A0 =C2=A0 dup =C2=A0 =C2=A0 =C2=A0
2 =C2=A0 =C2=A0 =C2= =A0 varbind =C2=A0 foo
3 =C2=A0 =C2=A0 =C2=A0 constant =C2=A02
4 =C2= =A0 =C2=A0 =C2=A0 call =C2=A0 =C2=A0 =C2=A01
5 =C2=A0 =C2=A0 =C2=A0 varr= ef =C2=A0 =C2=A0foo
6 =C2=A0 =C2=A0 =C2=A0 constant =C2=A03
7 =C2=A0 = =C2=A0 =C2=A0 call =C2=A0 =C2=A0 =C2=A01
8 =C2=A0 =C2=A0 =C2=A0 constant= =C2=A02
9 =C2=A0 =C2=A0 =C2=A0 diff =C2=A0 =C2=A0 =C2=A0
10 =C2=A0 = =C2=A0 =C2=A0mult =C2=A0 =C2=A0 =C2=A0
11 =C2=A0 =C2=A0 =C2=A0unbind =C2= =A0 =C2=A01
12 =C2=A0 =C2=A0 =C2=A0return=C2=A0 =C2=A0=C2=A0
<= br>As far as I understood,=C2=A0 the idea of the "indirect goto" = here is to eliminate the calls on lines 4 and 7 and replace them with an in= direct goto. And as per the TODO entry, the return in line 2 of the compile= d lambda would also need to be replaced by a jump back.

So here is w= here I am a bit lost. Currently, the compiled lambda bytecode lives in the = constant vector and a reference(?) to it is pushed into the evaluation stack in line 0 (constant <compiled-function>). Thus, for the = indirect goto idea to work, the bytecode of the lambda would need to be par= t of the bytecode of the let's body**. That way, a computed branch can = branch into the lambdas code and it is possible to branch out of it when re= turning.

Aside from guidance on implementing this, I would appreciat= e any pointers on how to adequately test it.

Regards,
--
Jo=C3=A3o Paulo L. de Carvalho
Ph.D Computer Sc= ience | =C2=A0IC-UNICAMP | Campinas , SP - Brazil
Postdoctoral Research = Fellow | University of Alberta | Edmonton, AB - Canada
joao.carvalho@ic.unicamp.br
joao.carvalho@ualberta.ca
** Forgive me for the lack/miss us= e of terminology.
--0000000000009f02d105e81bc663--