From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: guile 3 update: better reasoning about fixnums Date: Mon, 13 Nov 2017 15:54:23 +0100 Message-ID: <87fu9itejk.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510584885 15111 195.159.176.226 (13 Nov 2017 14:54:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 14:54:45 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Nov 13 15:54:39 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEG8C-0003Oo-B3 for guile-devel@m.gmane.org; Mon, 13 Nov 2017 15:54:36 +0100 Original-Received: from localhost ([::1]:54841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEG8I-00025j-AC for guile-devel@m.gmane.org; Mon, 13 Nov 2017 09:54:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEG8A-00024j-CM for guile-devel@gnu.org; Mon, 13 Nov 2017 09:54:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEG87-00075b-Pt for guile-devel@gnu.org; Mon, 13 Nov 2017 09:54:34 -0500 Original-Received: from pb-sasl2.pobox.com ([64.147.108.67]:52890 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eEG87-00075T-Lh for guile-devel@gnu.org; Mon, 13 Nov 2017 09:54:31 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id E3C958DF62 for ; Mon, 13 Nov 2017 09:54:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:date:message-id:mime-version:content-type; s=sasl; bh=J fXKuLq370y6K5jWs4EZ7HMCNB8=; b=j6veCzasrD6y/TwvVaNiF9hRnT04W78A/ UoFUjBGfEYVugnPnEvc/idGWy2DhOk8q/eWPpk90Sf8jn5I79M0bTyhdiBP88Yl2 YDCl1MdQ1eoHdkR0KVoloXaWESePwmsTTEYQRsY2p50dQqEnR887ZGqbErKRzWeX jOem0uzfTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :date:message-id:mime-version:content-type; q=dns; s=sasl; b=Smt //mP73Bl/IyectP7w7NoMIw1OfcF/6WBsXqy8wEM9dM8+NUC4O1Lp6XlQr4Xg4jP rcZlw9EakVJnaayRMLGOStDfZeDgOiQgXbPFhj2AbZFt1NfixDQGDuGz4g0dDK/W mQn3o0+9/qHvxVGNXexQh3ZQimOD6v65auRsegNE= Original-Received: from pb-sasl2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id C85F88DF61 for ; Mon, 13 Nov 2017 09:54:30 -0500 (EST) Original-Received: from sparrow (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl2.pobox.com (Postfix) with ESMTPSA id F03DB8DF60 for ; Mon, 13 Nov 2017 09:54:29 -0500 (EST) X-Pobox-Relay-ID: 8D5D7070-C882-11E7-A648-EA54894C8D7C-02397024!pb-sasl2.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.67 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.lisp.guile.devel:19384 Archived-At: Hi, An update on Guile 3 hackings over the past couple weeks. Firstly I made a change to the CPS language. Before, "primcalls" -- invocations of primitives known to the compiler, some of which ultimately compile to instructions/bytecode -- took all arguments as CPS values. This was even the case for primcalls that took known constant arguments, for example a primcall that does a vector-ref of a known index. I made a change so that all primcalls now have an additional slot, which is for some constant data associated with the primcall. (If you need two pieces of constant data, just cons up a data structure.) The idea is that constants used by primcalls as immediates don't need to participate in optimizations in any way -- they should not participate in CSE, have the same lifetime as the primcall so not part of DCE either, and don't need slot allocation. Indirecting them through a named $const binding is complication for no benefit. This change should improve compilation time and memory usage, as the number of labels and variables goes down. I didn't measure much though. I built on that to add set of "throw" primcalls to which all throws and errors compile, with corresponding VM support. This reduces the code size for error branches in functions that do a lot of type checking using e.g. srfi-9 accessors; for example in Guile 2.2, an internal procedure in the assembler (encode-X8_S8_S8_S8) compiles to 158 32-bit words, whereas in 3.0 it is currently 126 words, even after a bit of instruction explosion, and indeed it's a precondition for facilitating more instruction explosion. I also changed the compilation of "ash" to compile to "lsh", "rsh", or a branch between the two. This simplifies things later in the compiler. There are new "tag-fixnum" and "untag-fixnum" instructions, that convert between uint64_t and SCM values without branches. Many instances of scm->u64 etc now compile to these instead. Some unboxed operations and comparisons now operate in the signed range, as it's more convenient to check for fixnums using the fixnum? primcall (which compiles to an instance of the immediate-tag=? instruction) than it is to e.g. check ranges of generic integers, and there is now better support throughout the compiler for s64 values. I removed the <=, >=, and > comparison operators; they can all be expressed in terms of <, though looking back on this now I see that I messed up the behavior with NaN and <= or >=. Damn. Will fix. I added some signed right shift instructions, to do sign-extending right shifts over unboxed values; and that's about it. In summary, a lot of internal plumbing, for what appears to be preparatory work for future stuff. My to-do list in the near term has a few more plumbing-type tasks: * Remove u64=?, as we can just use s64=? polymorphism * Add s64-imm=?, imm-u64= with NaN values * Continue with instruction explosion, starting with vector-ref Cheers, Andy