linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Crusoe's persistent translation on linux?
@ 2003-06-19 16:37 Samphan Raruenrom
  2003-06-19 18:03 ` Vojtech Pavlik
  0 siblings, 1 reply; 57+ messages in thread
From: Samphan Raruenrom @ 2003-06-19 16:37 UTC (permalink / raw)
  To: linux-kernel; +Cc: Samphan Raruenrom

Hi,

I'm using 2.4.21 kernel on TM5800 Crusoe in Compaq TC1000 Tablet PC.
Currently the performance is not very good but the more I learn
about its architecture the more I'm obessesed about it (just like
the days when I use 68000 Amiga). Too bad that there are very little
information about the chip so I can't do anything much to improve
the performance myself (like enlarge the translation cache? how?).

On later versions of CMS (Code Morphing Software), there's a piece
of system software called "Persistent Translation service".
It looks like the purpose of the service is to get the translations
from the translation cache according to each user applications run
during the session and save them as binary files using the same name
with ".SYS.DB" appended, e.g. MOZILLA.EXE.SY.DB, NOTEPAD.EXE.SY.DB

I guess they are the native TM5800 code "essenses (very small part
that really get executed)" of those software. If my linux has the
service, I imagine that after using the system for a week, my system
will be filled by tranlated binaries and the processor will spend more
time with native application code than with the CMS. And no one will ask
for native crusoe compiler anymore. The best compiler is CMS.

Is it possible to have persistent translation on linux?



Regards,
Samphan Rareunrom,
National Electronics and Computer Technology Center,
Thailand.


^ permalink raw reply	[flat|nested] 57+ messages in thread
* Re: Crusoe's persistent translation on linux?
@ 2003-06-20 10:40 John Bradford
  2003-06-20 16:49 ` Eli Carter
  0 siblings, 1 reply; 57+ messages in thread
From: John Bradford @ 2003-06-20 10:40 UTC (permalink / raw)
  To: nuno.silva, torvalds; +Cc: linux-kernel, samphan, vojtech

> 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.

John.

^ permalink raw reply	[flat|nested] 57+ messages in thread
* Re: Crusoe's persistent translation on linux?
@ 2003-06-20 19:35 John Bradford
  0 siblings, 0 replies; 57+ messages in thread
From: John Bradford @ 2003-06-20 19:35 UTC (permalink / raw)
  To: eli.carter, john; +Cc: linux-kernel, nuno.silva, samphan, torvalds, vojtech

> 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 <eli.carter@inet.com>
> 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 <john@grabjohn.com>
> 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.

^ permalink raw reply	[flat|nested] 57+ messages in thread
end of thread, other threads:[~2003-07-23 20:11 UTC | newest]

Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-19 16:37 Crusoe's persistent translation on linux? Samphan Raruenrom
2003-06-19 18:03 ` Vojtech Pavlik
2003-06-19 19:51   ` Samphan Raruenrom
2003-06-20  0:02     ` Nuno Silva
2003-06-20  0:16       ` Linus Torvalds
2003-06-20  2:08         ` Nuno Silva
2003-06-20  9:08         ` Xavier Bestel
2003-06-20  9:33           ` Nick Piggin
2003-06-20 14:08           ` Henning P. Schmiedehausen
2003-06-20 15:38           ` Linus Torvalds
2003-06-20 16:51             ` AMD MP, SMP, Tyan 2466 kernel
2003-06-20 17:08               ` Bart SCHELSTRAETE
2003-06-20 17:09               ` Brian Jackson
2003-06-25 17:37                 ` Artur Jasowicz
2003-06-25 18:51                   ` joe briggs
2003-06-25 18:16                     ` Mike Dresser
2003-07-21 20:52                     ` Artur Jasowicz
2003-07-22  4:02                       ` Jason
2003-07-23 12:19                         ` paterley
2003-07-23 20:03                           ` Joe Briggs
2003-06-25 19:01                   ` joe briggs
2003-06-25 18:56                     ` Edward Tandi
2003-06-25 22:59                       ` Timothy Miller
2003-06-25 23:17                         ` Edward Tandi
2003-06-25 23:26                           ` Timothy Miller
2003-06-25 23:39                             ` Timothy Miller
2003-06-26  0:29                               ` Edward Tandi
2003-06-25 23:40                             ` Edward Tandi
2003-06-26 15:12                               ` Herbert Poetzl
2003-06-25 23:35                           ` Joel Jaeggli
2003-06-26 12:25                           ` AMD MP, SMP, Tyan 2466, REISERFS I/O error joe briggs
2003-06-26 11:55                             ` Oleg Drokin
2003-06-26 13:37                               ` joe briggs
2003-06-26 23:15                               ` Timothy Miller
2003-06-26 23:48                                 ` Joel Jaeggli
2003-06-27 13:01                                 ` joe briggs
2003-06-20 12:05         ` Crusoe's persistent translation on linux? Samphan Raruenrom
     [not found]     ` <20030619221126.B3287@ucw.cz>
2003-06-23  3:58       ` Crusoe's performance " Samphan Raruenrom
2003-06-23  5:22         ` H. Peter Anvin
2003-06-23  5:40         ` Grzegorz Jaskiewicz
2003-06-23  8:10         ` Vojtech Pavlik
2003-06-23  8:26         ` Vojtech Pavlik
2003-06-23 18:58           ` Samphan Raruenrom
2003-06-24  1:43             ` dean gaudet
2003-06-24  4:33               ` dean gaudet
2003-06-24 22:54                 ` Samphan Raruenrom
2003-06-24 23:06                   ` dean gaudet
2003-06-23 23:46           ` H. Peter Anvin
2003-06-24  0:51         ` H. Peter Anvin
2003-06-26  3:39         ` H. Peter Anvin
2003-06-26  4:22           ` H. Peter Anvin
     [not found]         ` <200306240051.RAA12097@cesium.transmeta.com>
2003-06-26 19:09           ` Samphan Raruenrom
2003-06-20 10:40 Crusoe's persistent translation " John Bradford
2003-06-20 16:49 ` Eli Carter
2003-06-20 16:56   ` Jeff Garzik
2003-06-20 17:46     ` dean gaudet
2003-06-20 19:35 John Bradford

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).