From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6788 invoked by alias); 30 Jul 2010 00:09:34 -0000 Received: (qmail 6763 invoked by uid 22791); 30 Jul 2010 00:09:23 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Jul 2010 00:09:18 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E1A631B4006; Fri, 30 Jul 2010 00:09:16 +0000 (UTC) From: Mike Frysinger To: DJ Delorie Subject: Re: [rx sim] add decode cache Date: Fri, 30 Jul 2010 00:09:00 -0000 User-Agent: KMail/1.13.1 (Linux/2.6.34; KDE/4.4.5; x86_64; ; ) Cc: gdb-patches@sourceware.org, kevinb@redhat.com References: <201007291841.o6TIfcgn017022@greed.delorie.com> <201007291741.50553.vapier@gentoo.org> <201007292200.o6TM0TlC021758@greed.delorie.com> In-Reply-To: <201007292200.o6TM0TlC021758@greed.delorie.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8224412.h5Gud9p4ng"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007291941.18708.vapier@gentoo.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-07/txt/msg00569.txt.bz2 --nextPart8224412.h5Gud9p4ng Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 2990 On Thursday, July 29, 2010 18:00:29 DJ Delorie wrote: > > ok, so the cached info isnt as generic as i'd like ;). i wonder if > > we could fit a cache in there somewhere though ... >=20 > I don't think the decode is as cpu-intensive as the semantics, though. > It seems to me there are a *lot* of loops in most software, so the > more info you can re-use, the better. Actually, decoding a single > opcode's syntax and semantics doesn't take that long, it's just that > benchmarks tend to run *zillions* of opcodes, so even tiny savings add > up. right ... i'm booting the Linux kernel all the way to userspace with the=20 Blackfin sim. and then running some benchmarks in that. the faster i can= =20 make this the happier i'll be :). sometimes i go even crazier and boot U-Boot in the sim, load a uImage over = the=20 simulated network from a real host (via tun/tap), and then boot the kernel= =20 that way. decompression is the worst part. > > doesnt seem like it's limited to CISC arches though ... in the > > Blackfin decode/sim, we too have a big tree of if/switch/masks to > > pull out arguments ive always been annoyed that we had to copy the > > decode file, gut it, and then fill in the sim pieces to make it > > work. seems like this opc2c might be a way back from that. >=20 > There's no reason why it *wouldn't* work for RISC architectures, of > course, I just never tried it, and don't know how optimal it would be > with it. However, if you have a RISC case where an operand field > isn't fully used, and certain operand patterns mean a whole different > opcode, opc2c can help you there - it will only decode to a specific > opcode if its operands are valid too, which is *really* hard to get > right with simple mask tables. yeah, we've had to do a lot of checks to make sure we dont go decoding inva= lid=20 opcodes as valid insns. we had a lot of this originally, but after putting= =20 together a lot of test cases that basically test the entire opcode space to= =20 make sure we dont revert behavior (only a few ten thousand insns in that on= e=20 test ;x). > For the m32c, I used opc2c for the simulator, and cgen was used for > everything else. For RX, opc2c was pushed to libopcodes, and it's > used for the simulator, disassembler, *and* gdb. Nowhere else are RX > opcodes decoded. Maybe Kevin can comment on how different it was to > use opc2c's decoder for gdb's prolog analyzer? i havent been able to figure out cgen. but from what i can see, with a=20 complete implementation already, i cant say it's worth the effort to move t= o=20 the cgen infrastructure. but it does look like opc2c wouldnt be too much=20 effort to integrate and it'd be worth the work to have our opcodes/sim=20 integrated better. > For the RX assembler, I used bison. The resulting file *looks* like > an opc2c input file - syntax followed by semantics - but I didn't try > to use the same input file for both purposes. yeah, we use lacc/yex too with our parser. -mike --nextPart8224412.h5Gud9p4ng Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAABAgAGBQJMUhGeAAoJEEFjO5/oN/WByT4P+gO/Nyj1YRtMjDE82BkB9H/J g6suq6BcukYmu1JdveHhfs9ZU5RCa934klMWrIsiB1x5Hsdt6g1mzBLQEPVNFNjt Ym8mR+NljbOyVg8CLukpStBWH+55ig2rOhmbUYQ1jdH4nQC5uiWn1yc2ghg6+uEA zzK5UH37a1OQZPjeb771AZMfLLkMyQg74Owu3p9jlau+ugkCWELC9guvz3eoB2vs mAj6omUxS5IbU3AZ9t7Z6dUQmOk/y9G0PIlZX3Q4wPBz+LpherV2ZhEtysWB+F3G +jRzWpl69rimlDqp0wwMOKeA41WSHn6KXOaNrMQDI32bSkV+ZRKpVYqFIkBCg2BC LHhBarZ/a8+D+5PqXyERKvmeb+XvWbzQPf6azQ4YEQEfjwz+XtzrAT/+5pSJkvvH JCzsxR8rxjwAG0e3n8WmToPtl0PsTh24F+pS95F3r9XYYkQRc5OLO+MHWCeagzqP +MxZlpSrODEKcQK51JzJ/fU9UgLai9Ldy6F6S8/LRqUUcy2neSfeIt8d/zTiScEv 0F2Dg7m3XcI/CEnZZdOVcBoQgyNpD1qNeGKiQi8ssdp/ysgao8LCjycKBRdWvTyG 4Wk2t8xNH+sl+dARMiNRuJMgB5p9eYIAOMitoSQbjSXaKwzMjgF6IrGJPgkzB8jw x1mtrFITgYRcrfqToOK5 =Hic4 -----END PGP SIGNATURE----- --nextPart8224412.h5Gud9p4ng--