From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: gmp issues (long) Date: 25 Feb 2003 23:32:22 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87smuc6lft.fsf@zagadka.ping.de> References: <87d6lhcnyn.fsf@raven.i.defaultvalue.org> <87y9446pyc.fsf@zagadka.ping.de> <87wujoqado.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046212433 15126 80.91.224.249 (25 Feb 2003 22:33:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2003 22:33:53 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18nne4-0003vq-00 for ; Tue, 25 Feb 2003 23:33:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nndp-00052C-05 for guile-devel@m.gmane.org; Tue, 25 Feb 2003 17:33:37 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18nndL-0004lm-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 17:33:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18nnce-0003re-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 17:32:57 -0500 Original-Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nncX-0003Ws-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 17:32:17 -0500 Original-Received: from dialin.speedway43.dip188.dokom.de ([195.138.43.188] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 18nncm-00021o-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 23:32:33 +0100 Original-Received: (qmail 19904 invoked by uid 1000); 25 Feb 2003 22:32:22 -0000 Original-To: Rob Browning In-Reply-To: <87wujoqado.fsf@raven.i.defaultvalue.org> Original-Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1977 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1977 Rob Browning writes: > Marius Vollmer writes: > > > I'm not so much worried about the size of an mpz_t but about the > > fact that it requires an additional malloc. > > OK, though an extra 6 bytes of overhead (actually 8 if you include the > fact that mpzs can't allocate in 2-byte-increments) for a 6 byte > integer still concerns me a bit, but perhaps it's OK -- and not > worrying about it will certainly keep the code simpler. If can reduce the overhead, that would be a good thing of course. But for the immediate performance problem, I wouldn't worry about it. > So is there a way we can memcpy the mpz_t data into the double cell's > three words, or would I need to pass the individual coerced pieces of > the mpz_t to a call to scm_double_cell? The way I understand things, GMP does not allocate the mpz_t's itself, right? Then you should be able to do things like SCM z = scm_double_cell (bignum_tag, 0, 0, 0); mpz_init (SCM_CELL_ADDR_1 (z)); where SCM_CELL_ADDR_1 or something similar needs to be added to gc.h. > i.e. is it OK to presume cell words are guaranteed to be contiguous, Yes. > or are you required to go through the SCM_CELL_N interface? We can make an additional interface (say SCM_CELL_BODY_ADDR) for treating the last three slots of a double cell as one memory block. > > There should be a test somewhere whether mpz_t really fits into this > > space. For now we can just wait for this test to fail, I'd say. > > What would be the correct formulation of this test? Would this be > right? > > sizeof (mpz_t) <= 3 * sizeof (SCM) > > or perhaps given scm_double_cell's prototype > > sizeof (mpz_t) <= 3 * sizeof (scm_t_bits) Hmm, both look good to me... but the latter is probably more right. When we have SCM_CELL_BODY_ADDR we can also have SCM_SIZEOF_DOUBLE_CELL_BODY. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel