[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] MiNT lib 55



On 2000-5-13, Guido Flohr <gufl0000@stud.uni-sb.de> wrote:

> > Since most pacakges appear to be compiled using that -m68020-60
> > option, (including the 030 kernel and the RPM binary), it might
> > be a good idea to specify that SpareMiNT has a "68020 + FPU"
> > minimal base, on the SpareMiNT homepage.
> 
> The 030 kernel is really compiled with -m68020-60.  

I would really prefer the 030 kernel to be compiled with
-m68030, but Frank's specs thins it down to 68000 ASM....

> The main benefit from the 030 kernel is however not improved
> performance but the extended instruction set which is needed
> for the memory management.

Indeed.

> I don't think that an 030 kernel is a lot faster than a plain
> 68000 kernel.

It definitely _is_ faster, as my previous experiences show.
Because of that, -m68030 optimization should _never_ be thined
down to 68000 code.


> The RPM binary is only by accident compiled with -m68020-60

Which was never fixed, thus preventing people without a 020+FPU
or better from using it.

> default flags for Sparemint packages are "-O2 -fomit-frame-pointer".

Noted.  Btw, what is the advantage of using -fomit-frame-pointer?

> > > I doubt that you will gain a lot by only giving -m68020-60.  

Well, Frank's specs transform that into 020-040 plus FPU.

> > > The big difference in performance is between FPU and non-FPU
> > > code.
> > 
> > Interresting.  People _do_ change. ;-)
> 
> Does that mean that you have decided to become the darling of
> this list and be a nice guy with everybody?

Nope.  Only that, after stating so many times that you don't see
the point in my using FPU optimization, you and Frank nonetheless
ended up hacking to the specs to generate FPU-enabled code when
-m68020-60 is used.

> P.S.: In a previous posting you have mentioned that you
> compile your kernel yourself because you prefer to optimize
> with -O3.  That can be an explanation for the astonishing
> amount of unreproducable bugs you report.  Exaggerating
> optimization is a common source of errors, especially in
> "sensitive" software like the kernel.
> 
> You should always keep a kernel compiled with the default
> flags and test if it shows the same behavior as your
> self-built kernel.

Clean code always compiles well with -O3.  The resulting binary
is often slightly larger than those produced with -O2 or lesser
optimization, but the speed increase is noticable.

-- 
Martin-Éric Racine  http://funkyware.atari.org/  Atari TT030 FAQ
Lappeenranta, Finland.  Surfing on a Intel/Microsoft-free GEM OS