Re: Crusoe's persistent translation on linux?

Re: Crusoe's persistent translation on linux?

[John Bradford]

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

Re: Crusoe's persistent translation on linux?

[Eli Carter]

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

Have fun,

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

Re: Crusoe's persistent translation on linux?

[Jeff Garzik]

On Fri, Jun 20, 2003 at 11:49:22AM -0500, Eli Carter wrote:
> Hmm... basically you want to trim the x86 instruction set to get closer 
> to RISC mentality.  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.

Newer CPUs do register renaming in an attempt to avoid the
register-starved ISA issue.  I presume Xmeta would do something
similar...

	Jeff

Re: Crusoe's persistent translation on linux?

[dean gaudet]

On Fri, 20 Jun 2003, John Bradford wrote:

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

very little of the translation overhead is involed with deocding the x86
instructions... most of the translation overhead is in scheduling and
optimising for the VLIW.

there are some tricks which you can apply at the x86 level which favour
CMS much more than they favour other processors... specifically one
related to what jeff brought up:


On Fri, 20 Jun 2003, Jeff Garzik wrote:

> Newer CPUs do register renaming in an attempt to avoid the
> register-starved ISA issue.  I presume Xmeta would do something
> similar...

yeah CMS does this internally.

one way you can exploit this for performance is within a basic block (or
within a code path that is most likely to be executed with a handful of
rarely/never taken branch outs) you can express every sub-expression
completely without worrying about its schedule -- which gives you access
to all the source x86 registers.  CMS will reschedule it to fit onto the
pipeline for you, and rename to internal registers.

this can be a huge help for floating point code when you also unroll the
code.  for example if you are doing a polynomial expansion, you can simply
write this:

	f0 = a0 + x0*(a1 + x0*(a2 + x0*(a3 + x0*a4)));
	f1 = b0 + x1*(a1 + x1*(a2 + x1*(a3 + x1*a4)));

you don't need to schedule the x87 code at all -- CMS will do it for you.
this example is pretty trivial, but if you have sequences which overflow
the x87 register set and require stack operations when scheduled for
a typical x86 processor you can mostly avoid the stack operations when
"scheduling" for CMS.

think of it as a huge reorder buffer.

-dean

Re: Crusoe's persistent translation on linux?

[John Bradford]

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

Crusoe's persistent translation on linux?

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

Re: Crusoe's persistent translation on linux?

[Vojtech Pavlik]

On Thu, Jun 19, 2003 at 11:37:33PM +0700, Samphan Raruenrom wrote:

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

How much 'not very good' is the performance? I'm considering buying an
Sharp Actius MM10 notebook, and so far I wasn't able to find ANY numbers
on how fast a 1GHz Crusoe actually is, nevermind with Linux running on
it ... and how much running Linux affects the expected battery life.
Can you share your experience?

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Crusoe's persistent translation on linux?

[Samphan Raruenrom]

Vojtech Pavlik wrote:
>>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?).
> How much 'not very good' is the performance? I'm considering buying an
> Sharp Actius MM10 notebook, and so far I wasn't able to find ANY numbers
> on how fast a 1GHz Crusoe actually is, nevermind with Linux running on
> it ... and how much running Linux affects the expected battery life.
> Can you share your experience?

See http://www.tabletpcbuzz.com/forum/topic.asp?TOPIC_ID=4451
The guy make a real world benchmark and conclude that a 1 GHZ TM5800
with latest CMS and PTT should be comparable with 1 GHZ PIIIm.
Normally TM5800 users will say it is comparable to 600-900 MHz PIII.

About running Linux on it. Application launch time is not good
(18 sec. to launch GNOME Help, 7 sec. to relaunch). But after that
it seems like linux GUI apps are more responsive.
Building software projects seem to take longer than it should be.
Building OpenOffice.org take more than 4 days while it take
about 1-2 days on PIII. I guess the CMS has to translate 'gcc'
on every invokation?  If so, can the kernel help in any way?

Battery life and Linux should be Ok. You'll have 'longrun' utility
to control cpu power consumption vs. performance. I understand
that the CPU already control its power consumption itself, even
without the help of the kernel, right?

Re: Crusoe's persistent translation on linux?

[Nuno Silva]

Hi!

Samphan Raruenrom wrote:
> Vojtech Pavlik wrote:
> 
>>> 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?).
>>
>> How much 'not very good' is the performance? I'm considering buying an
>> Sharp Actius MM10 notebook, and so far I wasn't able to find ANY numbers
>> on how fast a 1GHz Crusoe actually is, nevermind with Linux running on
>> it ... and how much running Linux affects the expected battery life.
>> Can you share your experience?
> 
> 
> See http://www.tabletpcbuzz.com/forum/topic.asp?TOPIC_ID=4451
> The guy make a real world benchmark and conclude that a 1 GHZ TM5800
> with latest CMS and PTT should be comparable with 1 GHZ PIIIm.
> Normally TM5800 users will say it is comparable to 600-900 MHz PIII.
> 
> About running Linux on it. Application launch time is not good
> (18 sec. to launch GNOME Help, 7 sec. to relaunch). But after that
> it seems like linux GUI apps are more responsive.
> Building software projects seem to take longer than it should be.
> Building OpenOffice.org take more than 4 days while it take
> about 1-2 days on PIII. I guess the CMS has to translate 'gcc'
> on every invokation?  If so, can the kernel help in any way?
> 


This raises a new question. How about a port of Linux to the "VLIW" so 
that we can skip x86 "code morphing" interelly?

I'm sure that 1GHz would benefit from it. Is it possible, Linus?

After googling a bit i went to
http://216.239.57.100/search?q=cache:GCP2Ecz931UJ:www.icsi.berkeley.edu/~fleiner/research.html+crusoe+linux+native+port&hl=en&ie=UTF-8

...But there isn't many more info. Is there any advantage?

Sorry for the OT... :)

Regards,
Nuno Silva



> Battery life and Linux should be Ok. You'll have 'longrun' utility
> to control cpu power consumption vs. performance. I understand
> that the CPU already control its power consumption itself, even
> without the help of the kernel, right?
> 

Re: Crusoe's persistent translation on linux?

[Linus Torvalds]

On Fri, 20 Jun 2003, Nuno Silva wrote:
> 
> This raises a new question. How about a port of Linux to the "VLIW" so 
> that we can skip x86 "code morphing" interelly?

The native crusoe code - even if it was documented and available - is not 
very conductive to general-purpose OS stuff. It has no notion of memory 
protection, and there's no MMU for code accesses, so things like kernel 
modules simply wouldn't work.

> I'm sure that 1GHz would benefit from it. Is it possible, Linus?

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.

So no, it wouldn't really benefit from it, not to mention that it's not
even an option since Transmeta has never released enough details to do it
anyway. Largely for simple security concerns - if you start giving
interfaces for mucking around with the "microcode", you could do some
really nasty things. 

Process startup is slightly slower due to the translation overhead, but
that doesn't matter for the kernel anyway (so a native kernel wouldn't
much help). And we do cache translations in memory, even across
invocations. I suspect the reason large builds are slower are due to slow
memory and/or occasionally overflowing the translation cache.

			Linus

Re: Crusoe's persistent translation on linux?

[Nuno Silva]

Hi!

Linus Torvalds wrote:
> On Fri, 20 Jun 2003, Nuno Silva wrote:
> 
>>This raises a new question. How about a port of Linux to the "VLIW" so 
>>that we can skip x86 "code morphing" interelly?
> 
> 
> The native crusoe code - even if it was documented and available - is not 
> very conductive to general-purpose OS stuff. It has no notion of memory 
> protection, and there's no MMU for code accesses, so things like kernel 
> modules simply wouldn't work.
> 
> 
>>I'm sure that 1GHz would benefit from it. Is it possible, Linus?
> 
> 
> 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.
> 
> So no, it wouldn't really benefit from it, not to mention that it's not
> even an option since Transmeta has never released enough details to do it
> anyway. Largely for simple security concerns - if you start giving
> interfaces for mucking around with the "microcode", you could do some
> really nasty things. 


Authoritative answer received! :)

Thanks,
Nuno Silva


> 
> Process startup is slightly slower due to the translation overhead, but
> that doesn't matter for the kernel anyway (so a native kernel wouldn't
> much help). And we do cache translations in memory, even across
> invocations. I suspect the reason large builds are slower are due to slow
> memory and/or occasionally overflowing the translation cache.
> 
> 			Linus
> 
> 

Re: Crusoe's persistent translation on linux?

[Xavier Bestel]

Le ven 20/06/2003 à 02:16, Linus Torvalds a écrit :
> So no, it wouldn't really benefit from it, not to mention that it's not
> even an option since Transmeta has never released enough details to do it
> anyway. Largely for simple security concerns - if you start giving
> interfaces for mucking around with the "microcode", you could do some
> really nasty things. 

Did you just write: "the Crusoe has special backdoors built-in which
would allow a userspace program to takeover the machine, and Transmeta
choose security through obscurity to avoid this problem" ?
Nice call for crackers :)

	Xav

Re: Crusoe's persistent translation on linux?

[Nick Piggin]

Xavier Bestel wrote:

>Le ven 20/06/2003 à 02:16, Linus Torvalds a écrit :
>
>>So no, it wouldn't really benefit from it, not to mention that it's not
>>even an option since Transmeta has never released enough details to do it
>>anyway. Largely for simple security concerns - if you start giving
>>interfaces for mucking around with the "microcode", you could do some
>>really nasty things. 
>>
>
>Did you just write: "the Crusoe has special backdoors built-in which
>would allow a userspace program to takeover the machine, and Transmeta
>choose security through obscurity to avoid this problem" ?
>Nice call for crackers :)
>
>

Hmm, did you just write: "Linus, I take you for an imbecile" ? ;)

Re: Crusoe's persistent translation on linux?

[Henning P. Schmiedehausen]

Xavier Bestel <xavier.bestel@free.fr> writes:

>Did you just write: "the Crusoe has special backdoors built-in which
>would allow a userspace program to takeover the machine, and Transmeta
>choose security through obscurity to avoid this problem" ?
>Nice call for crackers :)

God (and the NSA) gave you key signing protocols to avoid that. 

The Microcode upload for the Intel processors is even well documented.

I have yet to see someone putting out "enhanced microcode files for
the P<xxx> processor".

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

Re: Crusoe's persistent translation on linux?

[Linus Torvalds]

On 20 Jun 2003, Xavier Bestel wrote:
> 
> Did you just write: "the Crusoe has special backdoors built-in which
> would allow a userspace program to takeover the machine, and Transmeta
> choose security through obscurity to avoid this problem" ?

No. Quite the reverse. I just effectively wrote "you _cannot_ do that".  
And we won't even tell the details of _how_ you cannot do that.

In fact, even inside transmeta you cannot do that, without having a
specially blessed version of the flash that allows upgrades. If you ever
see a machine with a prominent notice saying "CMS upgraded to development
version", then that's a hint that it's a machine that TMTA developers
could change.

But even then you'd have to know how to change it.

Think of it like the Intel microcode update, except on steroids. Big 
steroids.

		Linus

Re: Crusoe's persistent translation on linux?

[Samphan Raruenrom]

Linus Torvalds wrote:
> Process startup is slightly slower due to the translation overhead, but
> that doesn't matter for the kernel anyway (so a native kernel wouldn't
> much help). And we do cache translations in memory, even across
> invocations. I suspect the reason large builds are slower are due to slow
> memory and/or occasionally overflowing the translation cache.

So how can I increase the size of the translation cache. I read from
Transmeta's whitepaper that both BIOS and OS can do this. This mean
that I should be able to insert a little piece of code in the kernel
somewhere and experiment with the new setting. I guess it might be a PCI
register?

How about the persistent translation service on Linux?
a) Transmeta will write it for us.
b) Transmeta will open enough info. for us to write it our own.
What do you think?