From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26647 invoked by alias); 26 Sep 2009 02:50:27 -0000 Received: (qmail 26638 invoked by uid 22791); 26 Sep 2009 02:50:26 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Sep 2009 02:50:20 +0000 Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id n8Q2oIo2016677 for ; Fri, 25 Sep 2009 19:50:18 -0700 Received: from ywh38 (ywh38.prod.google.com [10.192.8.38]) by spaceape7.eur.corp.google.com with ESMTP id n8Q2oFOP013122 for ; Fri, 25 Sep 2009 19:50:15 -0700 Received: by ywh38 with SMTP id 38so14120381ywh.6 for ; Fri, 25 Sep 2009 19:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.22.2 with SMTP id 2mr3631574ybv.293.1253933414758; Fri, 25 Sep 2009 19:50:14 -0700 (PDT) In-Reply-To: <20090926013727.GI27227@redhat.com> References: <20090926005044.1E975843AC@ruffy.mtv.corp.google.com> <20090926013727.GI27227@redhat.com> Date: Sat, 26 Sep 2009 02:50:00 -0000 Message-ID: Subject: Re: CGEN_WIDE_INT_INSN_P? From: Doug Evans To: "Frank Ch. Eigler" Cc: cgen@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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/msg00104.txt.bz2 On Fri, Sep 25, 2009 at 6:37 PM, Frank Ch. Eigler wrote: > 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. =A0Fetching, 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. No disagreement there. My only intention was to give enough to present the flavor of the change (once that's done the rest readily presents itself for inspection :-)).