From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Thompson Newsgroups: gmane.lisp.guile.devel Subject: Attempting to unbox struct fields Date: Sun, 28 Feb 2016 10:03:48 -0500 Message-ID: <8737scubaj.fsf@izanagi.i-did-not-set--mail-host-address--so-tickle-me> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1456671845 7670 80.91.229.3 (28 Feb 2016 15:04:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Feb 2016 15:04:05 +0000 (UTC) Cc: wingo@pobox.com To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Feb 28 16:03:58 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 1aa2t4-0002LO-13 for guile-devel@m.gmane.org; Sun, 28 Feb 2016 16:03:58 +0100 Original-Received: from localhost ([::1]:59315 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aa2t3-0000u2-9G for guile-devel@m.gmane.org; Sun, 28 Feb 2016 10:03:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aa2t0-0000tq-8o for guile-devel@gnu.org; Sun, 28 Feb 2016 10:03:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aa2sx-0006Az-1w for guile-devel@gnu.org; Sun, 28 Feb 2016 10:03:54 -0500 Original-Received: from mail-qk0-x235.google.com ([2607:f8b0:400d:c09::235]:36343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aa2sw-0006Av-Qd for guile-devel@gnu.org; Sun, 28 Feb 2016 10:03:50 -0500 Original-Received: by mail-qk0-x235.google.com with SMTP id s68so48212348qkh.3 for ; Sun, 28 Feb 2016 07:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=worcester-edu.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:user-agent:date:message-id:mime-version; bh=VJhGbdYENm/twuDNQNl2ONDND+HXj6gPRX6pzZlTPFk=; b=XfZaWLnjwon49NWBe6sRdoS8dkoGJ1ONkDYAGhuC93Ad2hmIQMZxo9RnPPRlD3o/al q13VgOIEXTP5tuRRhGV5RdOdWCLzlibmXv059Sbadn/KF0YthXSUJ8oj5fRZOZfiPOFh 2Do4Uk8xgFElWmEWVToREi+DqPE3VlLRkAB8qSvZ+SguJfy9dN+1j+fWihB6AQtJt42m Tk6zXAe5+xLiunXaS/F8yyz+0Hli23XeiOZjL+H17Us4SsWtiJJWAN5GRGnrN18pRo/P WSKXQuC8MVixjmSOXOV8PCin3wj5kTNg5SL2M6oAcZoTVcc+TASWGljSJEJh+TYWEJTo udMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:user-agent:date:message-id :mime-version; bh=VJhGbdYENm/twuDNQNl2ONDND+HXj6gPRX6pzZlTPFk=; b=iiNIQIX6RspXjMxDJXSKfXnLowiasRsSPAzF9BgKikXWvjLLKksEJak2HJDWvDxrMd w2VCGBgygC2GN21Z7IyFsgpeK4pwvQyD2mR2QDU1/z4ZIQvqvBzb7iubmrGjG5LBlki+ DHWajH8xOnKOrf+JvJd84xQ/Jzv2jp0pwki6a4NKJd3nQUNm2ss1Ox2bH7J0yqkq366E dnFri0qraVK0rj/LP5WQRnd3fYpo2tBo2u7CMM72EF28BEOp8JXBG6Rd2yHOnUkBmHPw UWQiv/9Xy2Y05oS+RNudvSV93T+rWco8eT6NGI/lsgWIX8/wD2O+aRUaGq8dGqmZW7H2 q9sA== X-Gm-Message-State: AD7BkJLhvr9lgTky5+BdiT+wrnlb08a8IjzbxoBDhX7d5feNYUg7zlhTNevTi98VXh5jvw== X-Received: by 10.55.72.135 with SMTP id v129mr13679024qka.72.1456671830100; Sun, 28 Feb 2016 07:03:50 -0800 (PST) Original-Received: from izanagi (209-6-40-86.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com. [209.6.40.86]) by smtp.gmail.com with ESMTPSA id b24sm9140885qkj.31.2016.02.28.07.03.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Feb 2016 07:03:49 -0800 (PST) User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-unknown-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::235 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:18196 Archived-At: Hello wingo and list, A couple days ago on #guile, I started a conversation about optimizing some record types I use for linear algebra to take advantage of unboxed arithmetic in the upcoming Guile 2.2. Andy informed me of a temporary hack I could try, but then said that The Right Thing is for Guile to unbox struct fields. So, I thought since Andy wrote such a nice post on his blog about about Guile compiler tasks [0] that maybe I would give it a try! I have gone about as far as I can on my own (not far), and seek the guiding light of the Guile maintainers to help unblock me. The task is as follows, quoting from the above mentioned blog post: Guile's "structs", on which records are implemented, support unboxed values, but these values are untyped, not really integrated with the record layer, and always boxed in the VM. Your task would be to design a language facility that allows us to declare records with typed fields, and to store unboxed values in those fields, and to cause access to their values to emit boxing/unboxing instructions around them. The optimizer will get rid of those boxing/unboxing instructions if it can. Good luck! I took an exploratory romp around the codebase and here's what I've learned: - Guile indeed supports unboxed fields in the struct implementation. Currently it only supports unboxed unsigned integers, but there's some preprocessor magic that can be removed to enable unboxed signed integers and doubles: switch (field_type) { case 'u': data[p] = SCM_NUM2ULONG (3, val); break; #if 0 case 'i': data[p] = SCM_NUM2LONG (3, val); break; case 'd': *((double *)&(data[p])) = scm_num2dbl (val, (char *)SCM_ARG3); break; #endif ... - It's easy enough to create a vtable with unboxed fields: (define vtable (make-vtable "uwuw")) (define s (make-struct vtable 123 456)) (struct-ref s 0) ;; => 123 - struct-ref/immediate and struct-set!/immediate are the VM operations for reading from/writing to structs - Roughly speaking, in the case of unboxed unsigned integers, one would want to insert a scm->u64 instruction before setting the value of an unboxed field, and one would want to insert a u64->scm instructor after getting the value of an unboxed field. - In TreeIL, struct refs and sets are primcalls, and when compiling to CPS they receive some special treatment to unbox the index component of the respective operations. This might be the procedure that will insert the boxing/unboxing instructions for the struct fields, but I'm not sure. Now that I've learned a little bit, I have a bunch of questions that I cannot yet answer: - Is it possible to know the layout of a vtable at compile time? - If so, where is that information stored? - If not, does this mean that TreeIL needs to be changed to be able to store typed struct field data in order to generate the correct CPS? - Can the TreeIL format even be reasonably changed since its a public interface that people target when writing their own language implementations? Basically, how could I possibly get my hands on the vtable information at compile time? Help would be very much appreciated! Thanks, -- David Thompson GPG Key: 0FF1D807 [0] http://wingolog.org/archives/2016/02/04/guile-compiler-tasks