From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Imporved cons representatoin in guile Date: Fri, 10 Jul 2015 13:20:11 +0200 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b339bb125c06e051a838e57 X-Trace: ger.gmane.org 1436527220 5438 80.91.229.3 (10 Jul 2015 11:20:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jul 2015 11:20:20 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 10 13:20:19 2015 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 1ZDWLq-000227-IA for guile-devel@m.gmane.org; Fri, 10 Jul 2015 13:20:18 +0200 Original-Received: from localhost ([::1]:44125 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDWLp-0004Vo-O2 for guile-devel@m.gmane.org; Fri, 10 Jul 2015 07:20:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDWLm-0004Vj-Hw for guile-devel@gnu.org; Fri, 10 Jul 2015 07:20:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDWLl-000750-Bx for guile-devel@gnu.org; Fri, 10 Jul 2015 07:20:14 -0400 Original-Received: from mail-pd0-x22b.google.com ([2607:f8b0:400e:c02::22b]:34699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDWLl-00071T-3P for guile-devel@gnu.org; Fri, 10 Jul 2015 07:20:13 -0400 Original-Received: by pdbep18 with SMTP id ep18so182966768pdb.1 for ; Fri, 10 Jul 2015 04:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=++6fQSwSP8i1FIjM5kaCKmiqtzYWoGlrmjbMfEM3G8M=; b=DUoTxFY5sLPkofiu4cRs2YxjEbVdV3AGe+/fdkEBlDxEAlPLxicdFxLKCZirqDikio 0lx+kXijKA1TooRID03Q96muT4XtEKpPaE+1Ya6dWxZyl8spf0OiTkM6yQz03xLD7HzZ JKQhRlui/HCjXsa5Y6z4n3pYbXYlzeo4DGK+J92g59i1vNRjBbMXlprqTAyvY5VEz+IP 31poM7tIsf8/WUEDtOIQ6YMJoTVhuFeh2Si1RI8cR04dYAI1a2+jpTfn8ScqzmfvTzGR dimsyHuMRhf4YcXSvDOghZsMfUlzFkq8g3oGmTS5pLGZ2qOMWtmbVCkdWh6WM0Z8d0f7 trug== X-Received: by 10.68.229.200 with SMTP id ss8mr41366847pbc.150.1436527211427; Fri, 10 Jul 2015 04:20:11 -0700 (PDT) Original-Received: by 10.70.78.132 with HTTP; Fri, 10 Jul 2015 04:20:11 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c02::22b 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:17757 Archived-At: --047d7b339bb125c06e051a838e57 Content-Type: text/plain; charset=UTF-8 Hi, I was complentating the cons cells in guile an was wondering if we could pack our cons cells better than today. So this is some notes about this. Currently if x is a cons cell we have the relation x -> [SCMCAR,SCMCDR] This is really neat and makes guiles conses quite compact e.g. a vector y of two elements is y -> [SCMTAG,SCMV1,SCMV2], where SCMTAG containes the datatype tag and length of the vector. To compress even further we need a way to could use x ->[SCM/2/SCM/2], witt SCM/2 the same tagging half the size as the normal SCM with the interpretation that if SCM/2 is a non emediate then it starts with 00 and is then interpreted as a signed integer i and the real adress is x + i, e.g. a relative adress regarding. We of cause must also add a fat cons cell of the form x -> [Tag,X,Y] for the case when SCM/2 is not fitting. Currently I can't see this beeing common. But if we later makes floating point represented via nan boxing e.g. stored directly in a 64bit value then the cons cell will be mostly fat and there would be a speed reduction using cons cells. On the other hand there has been a considerable speed. There is a final sematic case that needs to be fixed. if we do a setcar on a thin cons cell and the cell then becomes fat, we need to create the following x -> oldthin -> newfat e.g. we need to add a pointer type with the meaning of automatically follow the pointer if we encounter it. then oldthin is also tagging a variant of a cons cell. It is possible to keep it slim in the code that all fat cons cells is represented like that. How would a SCM_CAR be like? SCM SCM_CAR(SCM x) if(THIN(x)) { } --047d7b339bb125c06e051a838e57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I was complentating the cons cells = in guile an was wondering if we could pack our cons cells better than today= . So this is some notes about this.

Currently if x= is a cons cell we have the relation
x -> [SCMCAR,SCMCDR]

This is really neat and makes guiles conses quite comp= act e.g. a vector y of two elements is
y -> [SCMTAG,SCMV1,SCMV= 2], where SCMTAG containes the datatype tag and length of the
vec= tor.

To compress even further we need a way to cou= ld use
x ->[SCM/2/SCM/2], witt SCM/2 the same tagging half the= size as the normal SCM with the interpretation that if
SCM/2 is = a non emediate then it starts with 00 and is then interpreted as a signed i= nteger i and the real adress is x + i, e.g. a relative adress regarding.

We of cause must also add a fat cons cell of the for= m
x -> [Tag,X,Y] for the case when SCM/2 is not fitting. Curre= ntly I can't see this beeing common. But
if we later makes fl= oating point represented via nan boxing e.g. stored directly in a 64bit val= ue then
the cons cell will be mostly fat and there would be a spe= ed reduction using cons cells. On the other hand there has been a considera= ble speed.

There is a final sematic case that need= s to be fixed. if we do a setcar on a thin cons cell and the cell
then becomes fat, we need to create the following

x -> oldthin -> newfat

e.g. we need to add = a pointer type with the meaning of automatically follow the pointer if we e= ncounter it. then oldthin is also tagging a variant of a cons cell. It is p= ossible to keep it slim
in the code that all fat cons cells is re= presented like that.

How would a SCM_CAR be like?<= /div>

SCM SCM_CAR(SCM x)
=C2=A0 =C2=A0if(THIN(= x))
=C2=A0 =C2=A0 =C2=A0 {

=C2=A0 =C2=A0= =C2=A0 }




=


--047d7b339bb125c06e051a838e57--