From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24743 invoked by alias); 16 Jun 2005 16:04:15 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 24215 invoked by uid 22791); 16 Jun 2005 16:04:03 -0000 Received: from neon-gw-l3.transmeta.com (HELO neon-gw.transmeta.com) (63.209.4.196) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 16 Jun 2005 16:04:03 +0000 Received: from victor.transmeta.com (victor.transmeta.com [10.0.2.120]) by neon-gw.transmeta.com (Postfix) with ESMTP id 2A2945F8041; Thu, 16 Jun 2005 09:04:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.transmeta.com (Postfix) with ESMTP id 898DC4F802C; Thu, 16 Jun 2005 09:04:01 -0700 (PDT) Received: from victor.transmeta.com ([127.0.0.1]) by localhost (victor [127.0.0.1]) (amavisd-new, port 10022) with LMTP id 29033-04-89; Thu, 16 Jun 2005 09:04:01 -0700 (PDT) Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by victor.transmeta.com (Postfix) with ESMTP id 70F604F8003; Thu, 16 Jun 2005 09:04:01 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.11.6/8.11.6) id j5GG40w09959; Thu, 16 Jun 2005 09:04:00 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17073.41712.920235.625815@casey.transmeta.com> Date: Thu, 16 Jun 2005 16:04:00 -0000 To: "Frank Ch. Eigler" Cc: cgen@sources.redhat.com, sid@sources.redhat.com Subject: Re: [RFC] New cpu --- Morpho ms1 In-Reply-To: <20050616154855.GF27067@redhat.com> References: <42A752B2.8090407@rogers.com> <20050613145452.GE18930@redhat.com> <42B09F6F.7020302@redhat.com> <17072.41406.147361.75051@casey.transmeta.com> <20050616152212.GC27067@redhat.com> <17073.40390.435362.400645@casey.transmeta.com> <20050616154855.GF27067@redhat.com> X-SW-Source: 2005-q2/txt/msg00042.txt.bz2 Frank Ch. Eigler writes: > These are reasonable concerns in the abstract. Let's not insist on > extra maintenance work on this old code until there is an indication > that another of those 20 different apps shows up, or that gdb/sim will > model delayed writes too. I disagree. There is value in avoiding obviously bad code, especially instances that set a bad precedent. I seriously doubt a reasonable solution is non-trivial.