From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11389 invoked by alias); 26 Sep 2009 00:50:54 -0000 Received: (qmail 11378 invoked by uid 22791); 26 Sep 2009 00:50:53 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Sep 2009 00:50:50 +0000 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n8Q0okpe025626 for ; Sat, 26 Sep 2009 01:50:47 +0100 Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.18.118.116]) by zps19.corp.google.com with ESMTP id n8Q0oi0w027751 for ; Fri, 25 Sep 2009 17:50:44 -0700 Received: by ruffy.mtv.corp.google.com (Postfix, from userid 67641) id 1E975843AC; Fri, 25 Sep 2009 17:50:44 -0700 (PDT) To: cgen@sourceware.org Subject: CGEN_WIDE_INT_INSN_P? Message-Id: <20090926005044.1E975843AC@ruffy.mtv.corp.google.com> Date: Sat, 26 Sep 2009 00:50:00 -0000 From: dje@google.com (Doug Evans) 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/msg00102.txt.bz2 Hi. 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. Well, there are targets that would like to use an int but 32 bits isn't enough and 64 is enough. Should we add CGEN_WIDE_INSN_INT (or some such) and allow targets to use that? [I don't have a strong opinion. The topic will come up, so I'd like us to start thinking about it.] I wouldn't necessarily specify it the following way, but to illustrate: [from include/opcodes/cgen.h] typedef unsigned int CGEN_INSN_INT; typedef mumble_wide_int_mumble CGEN_WIDE_INSN_INT; #if CGEN_WIDE_INT_INSN_P typedef CGEN_WIDE_INSN_INT CGEN_INSN_BYTES; typedef CGEN_WIDE_INSN_INT *CGEN_INSN_BYTES_PTR; #elif CGEN_INT_INSN_P typedef CGEN_INSN_INT CGEN_INSN_BYTES; typedef CGEN_INSN_INT *CGEN_INSN_BYTES_PTR; #else typedef unsigned char *CGEN_INSN_BYTES; typedef unsigned char *CGEN_INSN_BYTES_PTR; #endif There'd be ramifications throughout binutils. Eventually I'd like to rework cgen.h and opcodes support anyway. Maybe this could be part of that. [One thing I'd like to do is at least split cgen.h into two (possibly more) pieces: the parts that are target independent, and the parts that are target dependent.] [btw, I don't like the names CGEN_INSN_BYTES{,_PTR} much, I'd love to change them if a better ones came along.]