On Fri, 2004-08-20 at 17:08, Gavan Fantom wrote:
> On Fri, 20 Aug 2004, Richard Earnshaw wrote:
> 
> > It's stable enough that I've been able to debug and complete a bootstrap
> > of gcc (trunk) compiling to Thumb code.  The size savings are quite
> > impressive:
> >
> > On my shark the size of the cc1 binary is
> >
> > shark1:egcs [759] $ size gcc/cc1
> >   text    data     bss     dec     hex filename
> > 3677285    6432  330916 4014633  3d4229 gcc/cc1
> >
> > Whereas on the integrator we see
> > integrator:gcc [611] $ size gcc/cc1
> >   text    data     bss     dec     hex filename
> > 2727208    6392  330496 3064096  2ec120 cc1
> >
> > which represents a 30.2% saving in code size.
> 
> Nice.
> 
> Does this space saving come with a performance gain or a performance hit?

It's normally a slight hit.  30% space saving when your instructions are
50% shorter means you must execute more instructions (about 40% more),
but on the other hand you get better I-cache utilization, so it's not
quite as bad as that in practice (in fact, some applications can end up
being faster since the entire critical code can fit in the cache).

However, typically only 10% of code is on the critical path, so you
could end up compiling many applications (or parts of many applications)
in thumb code and hardly notice the difference -- who really cares about
the speed of mount?

R.