From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21982 invoked by alias); 14 Jul 2009 05:59:08 -0000 Received: (qmail 21970 invoked by uid 22791); 14 Jul 2009 05:59:08 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX X-Spam-Check-By: sourceware.org Received: from sebabeach.org (HELO sebabeach.org) (64.165.110.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Jul 2009 05:59:02 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id 8921A6E3CE; Mon, 13 Jul 2009 22:59:00 -0700 (PDT) Message-ID: <4A5C1EA4.8070005@sebabeach.org> Date: Tue, 14 Jul 2009 05:59:00 -0000 From: Doug Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Dave Korn CC: cgen@sources.redhat.com Subject: Re: unable to find precise mode to match cpu word-bitsize 24 References: <4A3E86AA.2080002@gmail.com> <4A3EBD0E.5080109@sebabeach.org> <4A3ECDBB.1000806@gmail.com> <4A3FB9D5.9070103@sebabeach.org> <4A4FEA13.1090104@gmail.com> In-Reply-To: <4A4FEA13.1090104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00024.txt.bz2 Dave Korn wrote: > Doug Evans wrote: > >> Dave Korn wrote: >> >>> Doug Evans wrote: >>> >>> >>> >>>> This is new ground so we can decide how we want things to look, and then >>>> make it work. >>>> >>>> >>> Well, what I'd particularly like in this case would be for my pc to >>> increment by one for each 24-bit insn, rather than have the model >>> pretend to >>> be an 8-bit CISC machine processing all 3-byte instructions, if you >>> see what I >>> mean. >>> >>> >> Righto. That should be doable regardless. >> > > I hope so. Should I just take the blunt sledgehammer approach, and define > setters and getters for hardware units h-addr and h-iaddr that multiply/divide > by 3 on the fly, and let the underlying framework pretend it's a CISC machine > that uses 3-byte operands and data? Or is there a cleaner way to go? > > Sorry for the slow reply. Regarding "and let the underlying framework pretend ...", I think it depends on the framework. If you want to run a simulator on linux, say, what would you *want* it to look like? I think it should be possible to define things as you want in the description file, and then have the app source generators deal with the mapping from the architecture description to the app's implementation of that description. We'll probably need to extend the opcodes and simulator generators, but if it's the right thing to do, let's do it. IOW I'm not sure I'd add hardware setters/getters to do the mapping. Instead I'd like to see if the appropriate information could be passed to the simulator generator and it would generate its own getters/setters (or just make calls to something that is then provided by the underlying framework).