From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9703 invoked by alias); 26 Sep 2009 01:37:42 -0000 Received: (qmail 9692 invoked by uid 22791); 26 Sep 2009 01:37:42 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Sep 2009 01:37:33 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8Q1bSt1012203; Fri, 25 Sep 2009 21:37:28 -0400 Received: from fche.csb (vpn-240-19.phx2.redhat.com [10.3.240.19]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8Q1bR03029238; Fri, 25 Sep 2009 21:37:28 -0400 Received: by fche.csb (Postfix, from userid 2569) id 5C0B45845D; Fri, 25 Sep 2009 21:37:27 -0400 (EDT) Date: Sat, 26 Sep 2009 01:37:00 -0000 From: "Frank Ch. Eigler" To: Doug Evans Cc: cgen@sourceware.org Subject: Re: CGEN_WIDE_INT_INSN_P? Message-ID: <20090926013727.GI27227@redhat.com> References: <20090926005044.1E975843AC@ruffy.mtv.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090926005044.1E975843AC@ruffy.mtv.corp.google.com> User-Agent: Mutt/1.4.2.2i X-IsSubscribed: yes Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00103.txt.bz2 Hi - On Fri, Sep 25, 2009 at 05:50:44PM -0700, Doug Evans wrote: > On the opcodes-like size of things, > I remember ages ago talk of not having a choice between representing > instructions as an int or as a byte stream, > and just having a byte stream. > > I kinda like using an int for targets where it feels like the > obvious choice (e.g. sparc, etc.). > Wrappers could fold CGEN_INT_INSN_P targets into byte streams. > [...] The hard part seems to be not the representation typedefs, but the operations thereupon. Fetching, masking, printing, comparing, constitute a little API that hand-written (e.g. simulator) code needs to be aware of, and perhaps flexible with regards to. - FChE