From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Attempting to unbox struct fields Date: Mon, 29 Feb 2016 12:43:53 -0500 Message-ID: <87lh6376p2.fsf@netris.org> References: <8737scubaj.fsf@izanagi.i-did-not-set--mail-host-address--so-tickle-me> <87h9gscgpt.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1456767883 17865 80.91.229.3 (29 Feb 2016 17:44:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 17:44:43 +0000 (UTC) Cc: guile-devel To: "Thompson\, David" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Feb 29 18:44:29 2016 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 1aaRrn-0006w4-5k for guile-devel@m.gmane.org; Mon, 29 Feb 2016 18:44:19 +0100 Original-Received: from localhost ([::1]:38107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaRrm-0003mp-HF for guile-devel@m.gmane.org; Mon, 29 Feb 2016 12:44:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaRrj-0003ma-PI for guile-devel@gnu.org; Mon, 29 Feb 2016 12:44:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaRrg-0001jD-HL for guile-devel@gnu.org; Mon, 29 Feb 2016 12:44:15 -0500 Original-Received: from world.peace.net ([50.252.239.5]:58514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaRrg-0001j9-DL for guile-devel@gnu.org; Mon, 29 Feb 2016 12:44:12 -0500 Original-Received: from pool-71-174-32-69.bstnma.east.verizon.net ([71.174.32.69] helo=jojen) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aaRrZ-0003Aa-J4; Mon, 29 Feb 2016 12:44:05 -0500 In-Reply-To: (David Thompson's message of "Mon, 29 Feb 2016 09:26:26 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 50.252.239.5 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:18200 Archived-At: "Thompson, David" writes: >> The first thing I noticed is that the patch assumes that doubles are the >> same size as pointers. Obviously this is not the case on 32-bit >> systems. What's the plan for those systems? > > Yeah, I just hacked this together on my x86_64 system and paid no mind > to portability. I was hoping that you or Andy or Ludovic would have > an idea for how to address portability issues. :) I think the approach we need to take is that for 32-bit systems, doubles will need to use two consecutive slots. Furthermore, those slots will either need to be aligned (i.e. the first slot must have an even index) or else the code that accesses 'double' struct fields will need to perform the access carefully, perhaps by copying each half separately into a local 'union' and then copying the double from there. > My current plan is to keep pressing onward and produce a > proof-of-concept, hacky patch set that allows unboxed struct fields on > x86_64. Then, with some help and guidance, I can sort out the > portability issues, code style issues, unit tests, and documentation > after confirmation that the prototype is on the right track. I think the issue above is fairly fundamental, and might not be easy to address as an after-thought. It would be good to test your preliminary work on 32-bit systems throughout the development process. Fortunately, I know that you run GuixSD which makes this easy :) What do you think? Thanks, Mark