From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Aemon Cannon Newsgroups: gmane.emacs.devel Subject: Re: Difficulties byte-compiling very large .el file Date: Tue, 25 Aug 2009 11:04:37 -0400 Message-ID: <794057160908250804j2eb49424md39f1c71f403516@mail.gmail.com> References: <794057160908191449t4b23080cjf2b85cb0f8e4f589@mail.gmail.com> <19091.47590.276871.440616@parhasard.net> <19091.53277.453695.888871@parhasard.net> Reply-To: aemoncannon@gmail.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016364ee8722e4ec00471f8a76b X-Trace: ger.gmane.org 1251212802 5128 80.91.229.12 (25 Aug 2009 15:06:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Aug 2009 15:06:42 +0000 (UTC) Cc: emacs-devel@gnu.org, Miles Bader To: Aidan Kehoe Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 25 17:06:35 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MfxbW-00033g-9T for ged-emacs-devel@m.gmane.org; Tue, 25 Aug 2009 17:06:34 +0200 Original-Received: from localhost ([127.0.0.1]:36518 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfxbV-0008Js-Oz for ged-emacs-devel@m.gmane.org; Tue, 25 Aug 2009 11:06:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MfxZp-0006y5-Bv for emacs-devel@gnu.org; Tue, 25 Aug 2009 11:04:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MfxZk-0006uf-Bx for emacs-devel@gnu.org; Tue, 25 Aug 2009 11:04:48 -0400 Original-Received: from [199.232.76.173] (port=37856 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfxZk-0006uT-67 for emacs-devel@gnu.org; Tue, 25 Aug 2009 11:04:44 -0400 Original-Received: from mail-qy0-f195.google.com ([209.85.221.195]:37567) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MfxZh-0006Jf-8n; Tue, 25 Aug 2009 11:04:41 -0400 Original-Received: by qyk33 with SMTP id 33so660088qyk.24 for ; Tue, 25 Aug 2009 08:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hmg4Q4846IyNWDVV/po8/vw3FOWSLbage0/6hMYt/YQ=; b=IuLmLBxInIO5zUkIRQ9vGqU3RPdNEIEs4kO/q+FchAR1rvPylSikv57VgxoHXDN6YQ ql43o344OJlCD61liauNTfR2Q0AyQlwO47fV/BFUfBeluT7qmVqqMLKDl2/XiNA+RDir e9OpIBwlLROkpn1pAvBJrlNDoWolavgqwW7r0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=NWqYkDbfWMv3+teJey4/Y3Rx9bOkNeM0P2dLgVE/8L23c+uCIie5mt/QlvibhUa+pi 0tWU9IGOTY4HHnZZAtMKJQDJVnxY/73NOtLirZRYWiGGsA5kaO+G49eT8asykEa80TJu /sbi+N/aixrMboBjZm0Na4iwBsMT+Q6g/sZFk= Original-Received: by 10.229.11.147 with SMTP id t19mr1396477qct.28.1251212677500; Tue, 25 Aug 2009 08:04:37 -0700 (PDT) In-Reply-To: <19091.53277.453695.888871@parhasard.net> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114585 Archived-At: --0016364ee8722e4ec00471f8a76b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Aidan, Thanks for pointing out the overflow issue. As you may have guessed, those constants are both max-value for a signed 32 bit integer, which is what ANTLR spits out in LL* situations (unbounded values for max-k). I may be able to specify the max value for elisp in the ANTLR template.... RE: My original problem, I narrowed it down a bit and submitted a report at: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3D4251 I've since sent a followup with the following code, that also fails: ;;---------------- (defmacro many-forms () (let ((body '())) (dotimes (i 20000) (setq body (cons '(message "more") body))) `(progn ,@body))) (many-forms) (if (eq 1 a) (message "dude") (message "else")) ;;-------------- I had assumed that the goto opcode used a 16 bit relative offset, but this snippet seems to indicate that it's not relative to the conditional itself. I also noticed in bytecode.c that the goto opcodes all use: ..... stack.pc =3D stack.byte_string_start + op; ..... where 'op' is a 16 bit int. This indicates that the jump is measured in relation to the top of the current byte_string, so if the conditional is in its own byte_string, it should work: ;;-------------------- (defmacro many-forms () (let ((body '())) (dotimes (i 20000) (setq body (cons '(message "more") body))) `(progn ,@body))) (many-forms) (defun bar () (if (eq 1 a) (message "dude") (message "else"))) ;; ---------------------------- Which does work. Wrapping in lambda also works. So now I'm thinking that as3_elispParser.el must have a single function bod= y whose bytecode overflows the 16bit limit. As removing chunks of code from the top-level seems to alleviate the error (the lines with (a3el-parser-bitset ..) for instance), I'm guessing that the problematic byte_string corresponds to the top-level of the file. I may be able to wrap this top-level setup code into smaller functions.... On Tue, Aug 25, 2009 at 7:50 AM, Aidan Kehoe wrote: > > Ar an c=FAigi=FA l=E1 is fiche de m=ED L=FAnasa, scr=EDobh Miles Bader: > > > Aidan Kehoe writes: > > > GNU Emacs has (IIRC) 27-bit integers on 32-bit platforms > > > > ``The range of values for integers in Emacs Lisp is -268435456 to > > 268435455 (29 bits; i.e., -2**28 to 2**28 - 1) on most machines.'' > > Thanks for the correction. Aemon=92s problem remains, though, independent= of > that. Is there a good reason you don=92t error on encountering integers t= he > emacs binary can=92t represent? Portable code needs to be prepared for th= at > anyway. > > -- > =BFD=F3nde estar=E1 ahora mi sobrino Yoghurtu Nghe, que tuvo que huir > precipitadamente de la aldea por culpa de la escasez de rinocerontes? > --0016364ee8722e4ec00471f8a76b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Aidan,
Thanks for pointing out the overflow issue. As you may have guess= ed, those constants are both max-value for a signed 32 bit integer, which i= s what ANTLR spits out in LL* situations (unbounded values for max-k). I ma= y be able to specify the max value for elisp in the ANTLR template....

RE: My original problem,
I narrowed it down a bit and submitted a re= port at: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3D= 4251
I've since sent a followup with the following code, that also fails:;;----------------

(defmacro many-forms ()
=A0 (let ((body '= ()))
=A0=A0=A0 (dotimes (i 20000)
=A0=A0=A0=A0=A0 (setq body (cons &#= 39;(message "more") body)))
=A0=A0=A0 `(progn ,@body)))

(many-forms)

(if (eq 1 a)
=A0= =A0=A0 (message "dude")
=A0 (message "else"))
;;--------------

I had assumed that the goto opcode used a 16 bit r= elative offset, but this snippet seems to indicate that it's not relati= ve to the conditional itself. I also noticed in bytecode.c that the goto op= codes all use:
.....
stack.pc =3D stack.byte_string_start + op;
.....
where '= op' is a 16 bit int. This indicates that the jump is measured in relati= on to the top of the current byte_string, so if the conditional is in its o= wn byte_string, it should work:
;;--------------------
(defmacro many-forms ()
=A0 (let ((body '(= )))
=A0=A0=A0 (dotimes (i 20000)
=A0=A0=A0=A0=A0 (setq body (cons = 9;(message "more") body)))
=A0=A0=A0 `(progn ,@body)))

= (many-forms)

(defun bar ()
=A0 (if (eq 1 a)
=A0=A0=A0=A0=A0 (message "dude&qu= ot;)
=A0=A0=A0 (message "else")))

;; ------------------= ----------

Which does work. Wrapping in lambda also works.

So= now I'm thinking that as3_elispParser.el must have a single function b= ody whose bytecode overflows the 16bit limit. As removing chunks of code fr= om the top-level seems to alleviate the error (the lines with (a3el-parser-= bitset ..) for instance), I'm guessing that the problematic byte_string= corresponds to the top-level of the file.

I may be able to wrap this top-level setup code into smaller functions.= ...











On Tue, Aug 25, 2009 at 7:50 AM, Aidan Kehoe <kehoea@parhasard.net> wrote:

=A0Ar an c=FAigi=FA l=E1 is fiche de m=ED L=FAnasa, scr=EDobh Miles Bader:<= br>

=A0> Aidan Kehoe <kehoea@parhasard.net> writes:
=A0> > GNU Emacs has (IIRC) 27-bit integers on 32-bit platforms
=A0>
=A0> ``The range of values for integers in Emacs Lisp is -268435456 to =A0> 268435455 (29 bits; i.e., -2**28 to 2**28 - 1) on most machines.= 9;'

Thanks for the correction. Aemon=92s problem remains, though, indepen= dent of
that. Is there a good reason you don=92t error on encountering integers the=
emacs binary can=92t represent? Portable code needs to be prepared for that=
anyway.

--
=BFD=F3nde estar=E1 ahora mi sobrino Yoghurtu Nghe, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?

--0016364ee8722e4ec00471f8a76b--