From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31469 invoked by alias); 12 Apr 2003 20:00:20 -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 31462 invoked from network); 12 Apr 2003 20:00:20 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 12 Apr 2003 20:00:20 -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 h3CK0JD07107 for ; Sat, 12 Apr 2003 16:00:19 -0400 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 h3CK0IW30651; Sat, 12 Apr 2003 16:00:18 -0400 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 h3CK0IS31601; Sat, 12 Apr 2003 13:00:18 -0700 Message-ID: <3E987052.4C08F717@redhat.com> Date: Sat, 12 Apr 2003 20:00:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Kazu Hirata CC: gdb-patches@sources.redhat.com, dvenkat@noida.hcltech.com, avolkov@transas.com, cagney@redhat.com Subject: Re: h8/300 sim tests References: <3E917FF6.4699C121@redhat.com> <20030412.143919.126765664.kazu@cs.umass.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00254.txt.bz2 Kazu Hirata wrote: > > Hi Michael, > > > I've been working on some tests for the h8/300 simulator, and I've > > decided they're ready for contribution. I hope this framework will > > make it easy for others to add tests (hint hint file i/o cmdline). > > These are meant to go in a new directory sim/testsuite/sim/h8300. > > I just looked at the patch. This is great! > > But I am a little concerned about its size, though. You've written > this macro. > > + .macro test_cc_clear > + test_carry_clear > + test_ovf_clear > + test_zero_clear > + test_neg_clear > + ; leaves H, I, U, and UI untested > + .endm > > but I still see a lot of > > + test_carry_clear ; H=0 N=0 Z=0 V=0 C=0 > + test_ovf_clear > + test_zero_clear > + test_neg_clear I only use the test_cc_clear when I expect it to always be clear. When it varies from one test to the next (eg. the neg flag may be set one time, clear the next time), I spell them all out. > In and.w.s, or.w.s, and xor.w.s, I see a nest of > > + .if (sim_cpu) ; non-zero means h8300h, s, or sx > > which you probably didn't mean. I did mean it -- but it's short for "if (sim_cpu != 0)", which the assembler seems not to like. Zero happens to be the enum value for the plain vanilla h8/300, so this idiom means "if h8300h or h8300s or h8300sx". > I think we should have more macros that test that registers have not > changed like test_gr_a5a5_0_7 and test_gr_a5a5_1_7. Sure -- feel free to add them! > Having said all these, maybe we can first commit your patch and then > work on CVS. I am willing to help here. Cool - I will commit it by Monday EOB. Thanks for your review, Kazu! Michael