unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Aemon Cannon <aemoncannon@gmail.com>
To: Aidan Kehoe <kehoea@parhasard.net>
Cc: emacs-devel@gnu.org, Miles Bader <miles@gnu.org>
Subject: Re: Difficulties byte-compiling very large .el file
Date: Tue, 25 Aug 2009 11:04:37 -0400	[thread overview]
Message-ID: <794057160908250804j2eb49424md39f1c71f403516@mail.gmail.com> (raw)
In-Reply-To: <19091.53277.453695.888871@parhasard.net>

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

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=4251
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 = 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 body
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 <kehoea@parhasard.net> wrote:

>
>  Ar an cúigiú lá is fiche de mí Lúnasa, scríobh Miles Bader:
>
>  > Aidan Kehoe <kehoea@parhasard.net> 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’s problem remains, though, independent of
> that. Is there a good reason you don’t error on encountering integers the
> emacs binary can’t represent? Portable code needs to be prepared for that
> anyway.
>
> --
> ¿Dónde estará ahora mi sobrino Yoghurtu Nghe, que tuvo que huir
> precipitadamente de la aldea por culpa de la escasez de rinocerontes?
>

[-- Attachment #2: Type: text/html, Size: 3580 bytes --]

  reply	other threads:[~2009-08-25 15:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-19 21:49 Difficulties byte-compiling very large .el file Aemon Cannon
2009-08-20  8:27 ` Andreas Schwab
2009-08-20 13:07   ` Aemon Cannon
2009-08-20 13:23     ` Andreas Schwab
2009-08-20 14:29       ` Aemon Cannon
2009-08-20 18:30     ` Eli Zaretskii
2009-08-25 10:16 ` Aidan Kehoe
2009-08-25 11:07   ` Miles Bader
2009-08-25 11:50     ` Aidan Kehoe
2009-08-25 15:04       ` Aemon Cannon [this message]
2009-09-01 22:41         ` Aemon Cannon
2009-08-29  0:37   ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=794057160908250804j2eb49424md39f1c71f403516@mail.gmail.com \
    --to=aemoncannon@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=kehoea@parhasard.net \
    --cc=miles@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).