Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264491AbTFTTNc (ORCPT ); Fri, 20 Jun 2003 15:13:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264494AbTFTTNc (ORCPT ); Fri, 20 Jun 2003 15:13:32 -0400 Received: from 81-2-122-30.bradfords.org.uk ([81.2.122.30]:30593 "EHLO 81-2-122-30.bradfords.org.uk") by vger.kernel.org with ESMTP id S264491AbTFTTNa (ORCPT ); Fri, 20 Jun 2003 15:13:30 -0400 Date: Fri, 20 Jun 2003 20:35:12 +0100 From: John Bradford Message-Id: <200306201935.h5KJZCvc001455@81-2-122-30.bradfords.org.uk> To: eli.carter@inet.com, john@grabjohn.com Subject: Re: Crusoe's persistent translation on linux? Cc: linux-kernel@vger.kernel.org, nuno.silva@vgertech.com, samphan@thai.com, torvalds@transmeta.com, vojtech@suse.cz Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3239 Lines: 71 > From eli.carter@inet.com Fri Jun 20 20:22:12 2003 > Envelope-To: john@bradfords.org.uk > Date: Fri, 20 Jun 2003 11:49:22 -0500 > From: Eli Carter > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 > X-Accept-Language: en-us, en > MIME-Version: 1.0 > To: John Bradford > CC: nuno.silva@vgertech.com, torvalds@transmeta.com, > linux-kernel@vger.kernel.org, samphan@thai.com, vojtech@suse.cz > Subject: Re: Crusoe's persistent translation on linux? > References: <200306201040.h5KAerPK000431@81-2-122-30.bradfords.org.uk> > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > X-Scanned-By: MIMEDefang 2.29 (www . roaringpenguin . com / mimedefang) > > John Bradford wrote: > >>The translations are usually _better_ than statically compiled native > >>code (because the whole CPU is designed for speculation, and the static > >>compilers don't know how to do that), and thus going to native mode is not > >>necessarily a performance improvement. > > > > > > Would it be possible, (with relevant documentation), to tune the code > > morphing software for optimum performance of code generated by a > > specific compiler, though? > > > > If a particular version of GCC favours certain constructs and uses > > particular sets of registers for a given piece of code, couldn't we > > optimise for those cases, at the expense of others? Maybe a > > particular compiler doesn't use certain X86 instructions at all, and > > these could be eliminated altogether? > > > > It's not unlikely that an entirely open source system could have all > > code compiled with the same compiler, and so maybe we can use this to > > avoid implementing expensive corner cases in the CPU, because we're > > never going to trigger them. > > Hmm... basically you want to trim the x86 instruction set to get closer > to RISC mentality. Yep, that's what I was thinking. > Interesting. gcc may already do that to some extent > by not using the really complex instructions. If that is the case, > dropping those instructions might give some room for testing some of its > possible benefits. > I doubt restricting the registers used by some > instructions would help... I've heard comments that the x86 is > register-starved enough already. Ah, no what I meant was something along the lines of the z80, (yeah, it's been a while since I did assembler :-) ), where you had an 'accumulator', which you did all the complex operations in, and used the BC, DE, HL, (you just have to love the name, it helped you remember the endianness of the CPU), registers to do basic operations in. I was just thinking that if gcc favoured register BAR for operation FOO, the CPU could do likewise, and if their was a performance hit for using another register, we'd avoid it. Probably less applicable to a software based CPU like Cruesoe, though, and like you mentioned, X86 is register starved anyway. John. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/