[Texmacs-dev] Re: TeXmacs 1.0-1 -ffloat-store [Q]

[Richard Zidlicky]

On Thu, Jul 25, 2002 at 08:16:47PM +0200, Joris van der Hoeven wrote:
> 
> > >     CONFIG_CXXFLAGS="-m68020-60"
> > 
> > how about "-fno-exceptions -fno-rtti -fno-implicit-templates" ? 
> > They should be the same like on any other Linux machine and
> > afaics make sense.
> 
> We do not longer use "-fno-rtti -fno-implicit-templates" since
> version 1.0.0.10 and "-fno-exceptions" will be added automatically.

any pros/cons of rtti? I would imagine it just wastes memory if
you aren't using it.

> > -m68020-60 is not strictly needed and as long configure does
> > honour normal CFLAGS its better let the user specify the
> > CPU variant.
> 
> OK, so I will leave it out.
> 
> > >     CONFIX_CXXOPTIMIZE="-O2 -ffloat-store"
> > 
> > I think '-ffloat-store' is definitively not needed.
> 
> Why did someone put it in the TeXmacs.spec then...?
> What is it supposed to do?
> Did you do some benchmarking in order to find out?

<<gcc manual>>
`-ffloat-store'
     Do not store floating point variables in registers, and inhibit
     other options that might change whether a floating point value is
     taken from a register or memory.

     This option prevents undesirable excess precision on machines such
     as the 68000 where the floating registers (of the 68881) keep more
     precision than a `double' is supposed to have.  Similarly for the
     x86 architecture.  For most programs, the excess precision does
     only good, but a few programs rely on the precise definition of
     IEEE floating point.  Use `-ffloat-store' for such programs, after
     modifying them to store all pertinent intermediate computations
     into variables.

I can hardly believe TeXmacs would rely on something like this
and so far it works fine without it, the speed impact would be 
certainly noticeable for heavy fp oriented programs, esp on older
CPUs with less than perfect caching.

> We do not use libtool for the moment and it seems that -fPIC
> produces slower code and that it fails on certain architectures...

no problem, on linux-m68k not much happens if you omit -fPIC
for shared libs.

> Should I use
> 
>       m68k-*-linux*

this one.

> 
> or rather
> 
>       m68k-*-linux-gnu*


> > What is annoying:
> >   - toolbar generation switching from/to math mode is very slow, 
> >     apparently you generate map events after every single icon.
> >     Perhaps the toolbar widgets could be cached and reused instead
> >     of creating them anew?
> 
> They *are* cached! Anyone has an idea what might cause the slowdown?

you are right, this happens only upon the first invocation of the math 
mode.

> >   - toolbar and maybe complete window gets redrawn after every cursor 
> >     movement etc. Mostly not really noticeable except some extra
> >     flicker.
> 
> Yes, we probably should use some backing store here.

no need for backing store when there is nothing to redraw?

> >   - no tear-away menus or tool-boxes?? Generation of the boxes
> >     with math and greek symbols etc is slow, again these should be
> >     at least cached.
> 
> That again is done. When clicking on the menu a second time,
> they should show up much quicklier.

that is right but tear-off menus would still be very handy.

Richard