From z Mon Dec 04 19:09:33 2000 Received: from maguro.epr.com ([198.3.162.27]) by exchange.epr.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WNKA3CGK; Mon, 4 Dec 2000 10:07:12 -0800 Received: from magrathea.epr.com (firewall-user@magrathea.epr.com [198.3.160.1]) by maguro.epr.com (8.9.3/8.9.3) with ESMTP id KAA14513 for ; Mon, 4 Dec 2000 10:11:07 -0800 (PST) Received: (from uucp@localhost) by magrathea.epr.com (8.9.3/8.7.3) id KAA09340 for ; Mon, 4 Dec 2000 10:11:06 -0800 (PST) Received: from nodnsquery(199.222.69.4) by magrathea.epr.com via smap (V5.5) id xma008789; Mon, 4 Dec 00 10:10:12 -0800 Received: from clairv.com (IDENT:root@pc246.edi.nunet.net [199.249.165.246]) by mail.acm.org (8.9.3/8.9.3) with ESMTP id NAA49864 for ; Mon, 4 Dec 2000 13:10:07 -0500 Received: from magrathea.epr.com (firewall-user@magrathea.epr.com [198.3.163.3]) by clairv.com (8.9.3/8.9.3) with ESMTP id MAA31983 for ; Mon, 4 Dec 2000 12:10:07 -0600 Received: (from uucp@localhost) by magrathea.epr.com (8.9.3/8.7.3) id KAA08701 for ; Mon, 4 Dec 2000 10:10:06 -0800 (PST) Received: from unknown(198.3.162.27) by magrathea.epr.com via smap (V5.5) id xma008406; Mon, 4 Dec 00 10:09:34 -0800 Received: from eponym.epr.com (eponym.epr.com [10.1.1.123]) by maguro.epr.com (8.9.3/8.9.3) with ESMTP id KAA14464 for ; Mon, 4 Dec 2000 10:09:33 -0800 (PST) Received: (from sweeks@localhost) by eponym.epr.com (8.9.3/8.9.3) id KAA21617; Mon, 4 Dec 2000 10:09:33 -0800 From: "Stephen Weeks" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14891.56797.721593.839412@eponym.epr.com> Date: Mon, 4 Dec 2000 10:09:33 -0800 (PST) To: MLton@sourcelight.com Reply-to: MLton@sourcelight.com Subject: jump tables and cases In-Reply-To: References: X-Mailer: VM 6.71 under 20.4 "Emerald" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on eponym.sweeks.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=3.0 tests=AWL autolearn=no version=2.60 > Were the changes to preserve big integer case statements ever added to > MLton? Yes. Although I'm not sure they're getting used. It's near the top of my todo list to look into mlyacc and make sure they are. > I went ahead and added support to generate jump tables to the > x86-backend. That was the last feature I really wanted to get into the > backend, and it should also help with compile times (in particular, the > datatype representing x86 instructions has 50 variants, and I crawl over > this a lot). For datatypes, the backend has always generated switch statements. The only new thing is handling of source level integer cases. > I recall that Steve pointed out that mlyacc generated > parsers have big integer case statements, so it might also improve the > parse phase. Yep. > One other point: I know at some point I told Stephen to change the generated > code (in C) for switching over things that had a single tag bit at the bottom > to first shift the quantity right by 1 so that the jump table would be dense. > I don't remember what was being switched over, but it was definitely a win in > my tests. Yes, this was for datatypes which have value and nonvalue carrying variants, where the value carrying variants are represented as odd integers. The right place to do this is the backend. It's still on the todo list. > O.k. We might consider doing the same thing for cases on words. OKOK. It's on the todo list too. I had only done source level integer cases. Now that I've done that, words should be easy.