From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8881 invoked by alias); 21 Sep 2005 16:03:09 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 8845 invoked by uid 22791); 21 Sep 2005 16:02:58 -0000 Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 21 Sep 2005 16:02:58 +0000 X-SEF-Processed: 5_0_0_812__2005_09_21_17_02_38 Received: from Unknown [192.168.5.239] by multi.imgtec.com - SurfControl E-mail Filter (5.0); Wed, 21 Sep 2005 17:02:38 +0100 Received: from lemail1.le.imgtec.org ([192.168.152.65]) by klmail1.kl.imgtec.org with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 17:02:37 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Constraints between operands Date: Wed, 21 Sep 2005 16:03:00 -0000 Message-ID: <0D107966AF6D79418315B7C5549F4B5104E01B@lemail1.le.imgtec.org> From: "Will Newton" To: "Doug Evans" Cc: "Frank Ch. Eigler" , X-SW-Source: 2005-q3/txt/msg00033.txt.bz2 =20 > I was going to say have either a special "parse" or "insert" handler. > I seem to recall other instances where I needed to validate=20 > two operands against each other, but I can't find one at the moment. > At any rate, you're right, the parse handler isn't passed=20 > sufficient info. >=20 > If I can't find an existing example I think we need to extend cgen. > e.g. pass the fields struct to either or both of the parse=20 > and insert handlers. >=20 > Comments folks? One thing that would seem useful is to be able to parse things easily extending the existing infrastructure. I have come across two minor instances where it could be useful to do this. 1. One of our addressing modes looks like this: GETD Reg1, [Reg2+#0x20++] ; Reg2+offset, post-increment Reg2 It is not possible to parse this using the builtin integer parser, it barfs on the trailing ++. I implemented a parse handler for the integer value and ended up using strtol, it would be nice if I could perhaps pass an end pointer or length argument to cgen_parse_unsigned_integer to tell it where to stop parsing and use that instead. Maybe this isn't possible, it's not that big an issue. 2. To parse a register in a custom handler I ended up doing this: CGEN_OPERAND oper =3D meta_cgen_operand_table[opindex]; int i; CGEN_KEYWORD *reg_names =3D NULL; for (i =3D 0; i < HW_MAX; i++) { if (meta_cgen_hw_table[i].type =3D=3D oper.hw_type) { reg_names =3D (CGEN_KEYWORD *)meta_cgen_hw_table[i].asm_data; } } if (reg_names =3D=3D NULL) return "internal error"; errmsg =3D cgen_parse_keyword (cd, strp, reg_names, valuep); Which is a little bit of a roundabout way to get something that perhaps I should already have.