From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18441 invoked by alias); 17 Dec 2003 21:49:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18433 invoked from network); 17 Dec 2003 21:49:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 17 Dec 2003 21:49:31 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hBHLnUA23434 for ; Wed, 17 Dec 2003 16:49:30 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBHLnRM00766; Wed, 17 Dec 2003 16:49:28 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hBHLnQO29049; Wed, 17 Dec 2003 13:49:26 -0800 Message-ID: <3FE0CF66.30901@redhat.com> Date: Wed, 17 Dec 2003 21:49:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 MIME-Version: 1.0 To: Joern Rennecke CC: gdb-patches@sources.redhat.com, joern.rennecke@superh.com, andrew.stubbs@superh.com, amylaar@spamcop.net Subject: Re: [RFA] SH4A contribution for sim References: <200312151444.hBFEiX821417@chloe.uk.w2k.superh.com> In-Reply-To: <200312151444.hBFEiX821417@chloe.uk.w2k.superh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00423.txt.bz2 Joern Rennecke wrote: >>Michael Snyder wrote: >> >>>Here are my changes to support simulation of the sh4a. >> >>J"oern? Any comment? > > >>> { >>> int m, mv; >>> >>>+ /* J"orn Rennecke: "Allow variable length n / m fields". >>>+ I'm not sure if I understand these two lines. MVS */ >>> if (s[1] - '0' > 1U || !s[2] || ! s[3]) >>> expand_opcode (shift - 1, val + s[0] - '0', i, s + 1); >>>+ > > > The code above handles a single binary digit if it appears as > one of the last three characters, or in front of a non-binary character > (e.g. the 'i' in 'i8*1....'). This is because handling the three 'n's in > 'nnn0' leaves one extra binary digit. E.g. for fsca, after 'nnn', the > nibbles 0111 and 1110 are processed, leaving '1'. Ah, thanks, I see. So you're basically solving the same problem here that I did by introducing the "ddd0" pattern. Wouldn't it be safer to handle the extra '0' immediately? What if you had a pattern that was like "nnn0GGGG", (for instance)? You'd wind up parsing it as "nnn" plus "0GGG" plus "G". > I didn't want to process single bits all the time because that requires > some changes in patterns that recognize binary/letter combinations. Yeah, that could be ugly. > > On the other hand, you seem to be doing that right now anyway. Processing single bits? Not that I'm aware.... > And > expanding these combinations is making this code ever harder to maintain. > I think the only sane way forward is to handle variable-length binary fields > - i.e. make a loop to see how much we got and build up the number as we go. > The position dependent template fragments where the 'xx' and 'yy' for > movx/movy, which you changed to 'xy' and 'yx'. As a less extreme measure, what if we break some combinations into two-byte fields instead of four? I'm still thinking it through, but I'm thinking that, for instance, "01NN" could be handled in two passes: take the "01" first, then recurse and let the "NN" be handled in the outer switch statement. This might also apply to 01xy and XY01. > We can use this chage to xy/yx to make the detection position-independent, > or check the shift parameter. rather, that should be a count > of bits that remain to be processed - subtracting 4 at the start doesn't > make much sense if you don't process nibbles all the time. > > >>>+ /* 01xy -- 4 way fork across xy. */ >>>+ else if (s[2] == 'x' && s[3] == 'y') >>>+ for (j = 0; j < 4; j++) >>>+ expand_opcode (shift - 4, val | m | (j << shift), i, s + 4); >>>+ /* 01xx -- 2x32 fork across x0 and nopy. */ > > > This does not just go across nopy (that would be pointless), but across > nopy and movy. > By replacing all the 'xx' in movx templates with 'xy' and doing a vanilla > expansion for 'xy' above, you disable generation of case labels for > movx/movy combinations. Then you made tons of other changes to compensate > for this. I see not point in these changes. Please say more. I found this part of the work difficult, and I'm by no means sure that my solution was optimal. Unfortunately I did the work several months ago, and my memory is not fresh (appologies for not getting around to submitting it sooner). >>>+ case 'd': >>>+ /* Double register dr0-dr14 (even numbers only). */ >>>+ /* ddd0 -- 8 way fork. */ >>>+ val |= bton (s) << shift; >>>+ for (j = 0; j < 15; j += 2) >>>+ expand_opcode (shift - 4, val | (j << shift), i, s + 4); >>>+ break; > > > What is that for? I don't see why we should have a separate ddd0 pattern, > where nnn0 works just fine and also makes it much clearer where the number > ends up. It's also more efficient when the simulator doesn't do any > unnecessary runtime checks on the opcodes. The even-numbered registers > generate legal instruction encodings. The odd-numbered ones are left > over for the default case. If you want to make sure that they raise a > SIGILL exception, you can do this by initializing table accordingly. OK, but there's precident -- MMMM, ssss, and GGGG all stand for specific subsets of register numbers. I'm willing to go with your way, but consider that if we do use ddd0, then the problem of handling a single nybble goes away. The nnnn / mmmm code becomes simpler again.