From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19121 invoked by alias); 11 May 2006 20:52:29 -0000 Received: (qmail 19112 invoked by uid 22791); 11 May 2006 20:52:28 -0000 X-Spam-Check-By: sourceware.org Received: from neon-gw-l3.transmeta.com (HELO neon-gw.transmeta.com) (63.209.4.196) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 20:52:26 +0000 Received: from victor.transmeta.com (victor.transmeta.com [10.0.2.120]) by neon-gw.transmeta.com (Postfix) with ESMTP id 547DB5F8062; Thu, 11 May 2006 13:52:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.transmeta.com (Postfix) with ESMTP id 7C7CF4F802C; Thu, 11 May 2006 13:52:24 -0700 (PDT) Received: from victor.transmeta.com ([127.0.0.1]) by localhost (victor [127.0.0.1]) (amavisd-new, port 10022) with LMTP id 17524-01-89; Thu, 11 May 2006 13:52:24 -0700 (PDT) Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by victor.transmeta.com (Postfix) with ESMTP id 6A3464F8003; Thu, 11 May 2006 13:52:24 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.11.6/8.11.6) id k4BKqNh16495; Thu, 11 May 2006 13:52:23 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17507.41991.445233.121586@casey.transmeta.com> Date: Thu, 11 May 2006 20:52:00 -0000 To: "Jim Blandy" Cc: "Dave Brolley" , ttn@glug.org, cgen@sources.redhat.com Subject: Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input In-Reply-To: <8f2776cb0605110945i75d9402bp6743ae22da38d0cb@mail.gmail.com> References: <44622986.3090309@redhat.com> <17506.11439.818364.259602@casey.transmeta.com> <44634659.60508@redhat.com> <8f2776cb0605110945i75d9402bp6743ae22da38d0cb@mail.gmail.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid X-IsSubscribed: yes Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00030.txt.bz2 Jim Blandy writes: > The larger question is, why aren't CGEN machine description files just > arbitrary Scheme code that happens to call some functions to register > machine description pieces? Then you'd have the full Scheme language > at your disposal, not just pmacros. I can explain why things are the way they are today. The powers that be can of course change things however they please. I didn't (and still don't) want (arbitrary) Scheme in .cpu files. Maybe CGEN will be written in multiple language some day (once one has a .cpu database reader, the choice of language for file generators and such is less important). I'd hate to have to rewrite all the .cpu files, or maintain multiple versions, or etc.; or implement all of Scheme just to read the .cpu file in. I look at .cpu files as a description of the cpu, and I don't want the reading of that description to be excessively complicated. Another consequence in allowing arbitrary Scheme is that .cpu files would become harder to read and maintain. [ One can quibble of course over whether and how much of Scheme is already in .cpu files :-). I think there's even some places where I provided too much of an escape hatch in order to get something done (e.g. .eval). But I think one would be hardpressed to argue that using a different language would be no harder after N years of allowing arbitrary Scheme to appear in .cpu files. As things stand today, reading the database is rather simple compared with being required to understand all of Scheme. I can even imagine having just one database reader in C(/C++) and then having all generators use it, regardless of language. Of course, if one wants to stick with just Scheme then there is less reason for not allowing it in .cpu files. ] Having said that, I wouldn't switch from Scheme myself. But the point is others can for a particular file generator once the database reader is written. I WOULD switch from Guile to something better. One dream I have is to have a Scheme implementation that does dynamic compilation using a framework built from CGEN. > None of this would complicate the interesting parts of CGEN --- the > code for producing encoders, decoders, and simulators. They would > operate on the same data structures they do now. You'd just have a > lot more flexibility in how those structures are produced. IMO (and this is just my opinion) I'd rather restrict the description of the cpu, and make it easier to use that description. [Hmmm, One could have a generator that read in a .cpu with arbitrary Scheme and spit out a copy ready for consumption by a different language, but it feels like the wrong way to go.]