From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-rtl status Date: Mon, 04 Jun 2012 11:03:09 +0200 Message-ID: <87wr3nmotu.fsf@pobox.com> References: <874nqsnken.fsf@pobox.com> <877gvoqb8v.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1338800613 30227 80.91.229.3 (4 Jun 2012 09:03:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 4 Jun 2012 09:03:33 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jun 04 11:03:32 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SbTCE-0007VP-Kq for guile-devel@m.gmane.org; Mon, 04 Jun 2012 11:03:30 +0200 Original-Received: from localhost ([::1]:44479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbTCE-0004MB-Ce for guile-devel@m.gmane.org; Mon, 04 Jun 2012 05:03:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbTC3-0004K2-10 for guile-devel@gnu.org; Mon, 04 Jun 2012 05:03:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbTC0-0006ck-Vs for guile-devel@gnu.org; Mon, 04 Jun 2012 05:03:18 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:56267 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbTC0-0006aL-Mm; Mon, 04 Jun 2012 05:03:16 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 576AD673C; Mon, 4 Jun 2012 05:03:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=dgc7VrbvrXWG 9upHtc2SycReft4=; b=oiBh8VDJHTOH1O2VKyoR8+iQLj2QJd+Fg2BXam+ivRk3 msHVX7cZkpkQqNd4owHl3eQjtO4HgIsqRRJROLznHiYIbst3SWrUoBABmmNryNS5 copIZ+Qs4HHeEbPi2RkBBgpnioEgx54bt7f1K3Xrs3+6YCRnSPF+YoEAU6ZtJw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=QHNg5r 6N7+GrT2DpTEEDvlGWjkMjf4W7+0MPIR6ghpeZ6YRMl2i7EmhlvzV2ZKb264mqAF RuQIFDUIyCgZHkWg2P1g8nGxmQaSiKuvGI1NxpBwpLgBb+76dDshk6sShpNq04XJ bEkosPV7aBFXYoq45aXW4Kjvcl+RhOcbS9BlM= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 4F982673B; Mon, 4 Jun 2012 05:03:13 -0400 (EDT) Original-Received: from badger (unknown [85.50.243.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 81AF6673A; Mon, 4 Jun 2012 05:03:12 -0400 (EDT) In-Reply-To: <877gvoqb8v.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Mon, 04 Jun 2012 00:30:40 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-Pobox-Relay-ID: 1D07981A-AE24-11E1-9BAA-E981AF15ED39-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14554 Archived-At: Hi! On Mon 04 Jun 2012 00:30, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Woow, this is dense. ;-) Yeah, sorry about that ;) It has been difficult to get to a good stopping point, and without that, I don't know how to organize my thoughts :) > Andy Wingo skribis: > > Forget it if it=E2=80=99s too late, but would it make sense to first work= on ELF > as the container format and merge that in =E2=80=98master=E2=80=99, then = merge wip-rtl > on top? It would be easier to digest. ;-) That's possible to do. I don't think I would merge the bits that statically allocate constants though, as it would entail changes to the old VM, and it's probably not worth it. So I would just throw our existing bytecode into one section and link that to ELF, and use the new loaders to load it. Could be a good idea. >> Instructions that take constants take them literally. The various >> emit-foo procedures will add the constant to a table if necessary, and >> link-objects will serialize a constant table if necessary. Not sure if >> this is being too clever or not. > > I suppose the result is the same, whether the constant table is built at > a level equivalent to GLIL or at some lower level. So it may be more a > question of which one is more easily or elegantly implemented? Yeah, that's basically it. >> Currently there are a couple of broken bits. One is that we don't >> currently write an init thunk, to fix up the car and cdr links in static >> pairs, for example. > > Static pairs, as constant pairs stored on-disk? Yes. Consider a constant like '(1 . 2). The car and the cdr are both immediates, so you just allocate some space in the image for two words, aligned on an 8-byte boundary, and you write the `object-address' of the immediates directly in the words. However something like '(1 . (2 . ())) has two pairs: the tail which has two immediates, and the head that has an immediate in the car but a pointer in the cdr. In that case you need to patch up the cdr to point to the tail, after you load the .go (or .so?) file. The RTL text is position-independent, and the ELF linker tries to separate read-only data from read/write data, so as to maximize sharing among different processes. But PIC data does mean that there will be some relocations to initialize the internal pointers of static constants. That's what the init thunk does (or will do). I could have emitted relocations into the ELF and had the loader handle them, but this way we get to do our own kind of initialization, like initializing immutable values as in string->symbol and string->number. Andy --=20 http://wingolog.org/