> So you can compile a i386 or i486 kernel with a 'C' compiler that was
> built on a i686 machine. It took me a week to find the reason why
> a kernel, configured to run on a 486 (or even 386) would crash on
> the boot of a 486.
> The only built-in I found used was abs(). It was the '486 killer.
the builtin abs() was a known issue, but I assumed it was harmless.
Are you saying gcc generates 686 instructions (cmov i guess) even
when configured for a 486? I'd like to reproduce this -- which gcc
version, cflags, file? Does '-march=i486' (or ..=i386) solve this?
Do you have the offending abs dissassembly? Have you compared the
code generated for the builtin vs proper define (ie one which can
take args w/ side effects (the one i saw posted didn't)).
[it sounds like a gcc bug affecting more than just the kernel, hence
i'd like to identify it before working it around... I never looked
at gcc2.95 generated code for pre686 so it's possible i never saw
this, but i did look at the 686 code and chose not to "fix" abs();
right now i don't remember exactly why, but it must have been either
(1) builtin_abs() generated better code or (2) there was no difference]
> The memcpy and other routines are in the architecture-specific directories
> in cases where processors offer certain advantages.
gcc should pick the best sequence for the builtin ones depending on
the target cpu. unfortunately currently this only seems to work for
certain cases (and even then not always). for the 686 cases i looked
at the builtins were better than the asm inlines.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/