From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28378 invoked by alias); 7 Jan 2004 03:25:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28371 invoked from network); 7 Jan 2004 03:25:18 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 7 Jan 2004 03:25:18 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.24) id 1Ae4Jf-00017c-K8 for gcc@gnu.org; Tue, 06 Jan 2004 22:25:07 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ae5Gn-0000MV-KJ for gcc@gnu.org; Tue, 06 Jan 2004 23:26:44 -0500 Received: from [66.166.225.55] (helo=baradas.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ae5Gn-0000ML-3K for gcc@gnu.org; Tue, 06 Jan 2004 23:26:13 -0500 Received: by baradas.org (Postfix, from userid 500) id 4428D989A3; Tue, 6 Jan 2004 22:24:43 -0500 (EST) From: Peter Barada To: bernie@develer.com Cc: rz@linux-m68k.org, gcc@gnu.org In-reply-to: <3FFB6CA9.2090906@develer.com> (message from Bernardo Innocenti on Wed, 07 Jan 2004 03:19:21 +0100) Subject: Re: m68k bootstrapping broken References: <20040104215932.GC1714@linux-m68k.org> <3FF8E2B3.1090106@develer.com> <20040105122028.GA14266@linux-m68k.org> <3FFA0A3E.6000507@develer.com> <20040106085137.GA1610@linux-m68k.org> <3FFA9AB6.6070403@develer.com> <20040106155836.88F25989A5@baradas.org> <3FFB4129.9000002@develer.com> <20040107002517.4D089989A3@baradas.org> <3FFB5630.1080307@develer.com> <20040107004958.721B4989A3@baradas.org> <3FFB6CA9.2090906@develer.com> Message-Id: <20040107032443.4428D989A3@baradas.org> Date: Wed, 07 Jan 2004 03:25:00 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-SW-Source: 2004-01/txt/msg00403.txt.bz2 >>>>It won't be that hard to make it work for a 5206e/5272/528x/5249, at >>>>least from the core perspective(just need to add the div/mod >>>>instructions and the extra v2 insn for the 528x). Adding in the v4 >>>>instructions shouldn't be too hard either. >>> >>>Yes, but I think the emulator also lacks the required infrastructure >>>to select multiple CPUs at run-time. >> >> Yes, it does. Its all trade; do you add ColdFire bits to UAE and then >> go through the hassle of getting uClinux to boot, or do you add the >> other bits to the emulator at lightbox. I understand that performance >> of the emulator at lightbox can be improved, and I see ways to speed >> it up, or do we take all ot the above and produce one frm scratch that >> has the benifit of being usable as a simulator by GDB? > >Do we really need to start from scratch? Can't we massage existing >code until it fits into GDB's simulator infrastructure? > >Even though in the end you'll have rewritten every single line of the >emulator, usually the time you save in design and debug are worth it. > >I tend to avoid starting projects from scratch when there's even the >smallest chance to use existing code, as ugly, buggy or limited as it >may be :-) If you're tryong to make a McLaren F1 car, you surely don't want to start with a Model T. It all depends on what you're starting with and what you're trying to make. I do agree with ripping off as much so the reinvention of the wheel is limited, but sometimes starting with a clean slate is easier. >By the way, all the projects we're talking about GPLed, so there are >no legal issues. Yes, there is that. That's why I've been looking at both(in my copious spare time of course). >> I'm happy to go in any direction, I just want to know its the right >> one :-) As a side note, I've already started on building a UAE style >> instruction decoder for ColdFire, and have a decoder that produces a >> full table for V4. It should be pretty trivial to have it genreate the >> table at startup based on which CPU model you want... > >That's great news! UAE's cpugen also has some questionable x86 >optimizations done by post-processing GCC's assembly output. Of course >it breaks on every new GCC release, so I don't think I'd want to maintain >such a thing ;-) I'll look at having it encode instructions with a model selector in the first filed so we can have it produce different decode selectors. >Another thing. I'm playing with libffi to see if I can get it to work >on plain 68000. Do you know a simple instruction sequence to replace >this bit-field operation? > > bfins %d0,(%a1){#0,%d2} > > >I was thinking of something like this (in pseudo-C): > > mask = (1 << (d2 & 0x1f)) - 1; > *a1 = (*a2 & ~mask) | (d0 & mask); > >This should work like bfins for any value of d2, >but the code as produced by GCC is quite longwinded: > > moveq #31,%d1 > and.l %d1,%d0 > move.b #1,%d1 > lsl.l %d0,%d1 > subq.l #1,%d1 > move.l %d1,%d0 > not.l %d0 > and.l (%a1),%d0 > and.l %d1,%d2 > or.l %d2,%d0 > move.l %d0,(%a1) > >Is there a more efficient way? Let me think for a bit. Perhaps I'll code it up for superopt to crunch over for a while... -- Peter Barada peter@the-baradas.com