Re: Bootstrapping Debian GNU/Linux distribution on SuperH
At Sat, 22 Sep 2001 11:49:48 +0900 (JST),
NIIBE Yutaka wrote:
> > However, according to Hitachi, the ABI is different between SH3 and
> > SH4. Please check out programming manuals of SH3 and SH4.
> > Instruction set are backward compatible. However, some instructions
> > are allowed in delay-slot for SH3 but not for SH4. I mean, if someone
> > tunes a program for SH3 pipeline, it may not work on SH4. It's easy
> > to write such program, if people use assembler. Current GCC does not
> > emit such a code (this is the reason why almost all code work fine).
> > But it's free to do so in future GCC, because the definition of ABI is
> > different.
>
> This is just a POTENTIAL issue.
IMHO, this situation is easy to reproduct on other archs...
If you use MMX extension on i386, then obsolete processor
cannot run any such instructions :-)
> I forgot to mention *important* CURRENT problem.
>
> The executable is almost compatible, that's true. The object and/or
> shared library are *not* compatible, because the ABI of calling
> convention is different. Hitachi defines that ABI.
>
> When structure is passed to the function with the argument, the order
> is different between SH3 and SH4. The object and/or library compiled
> by -m3 and -m4 should _not_ be linked, or else, it crashes runtime.
>
> In short, if you only have SH3 executable and shared libraries, that's
> fine (not guaranteed in future, though). However, you cannot mix SH3
> binaries with SH4's, as it's not compatible.
It needs ABI interface definition change.
It's problem that only this trivial things (the order of
argument) cause all binaries/libraries incompatibility...
Though I don't know it's difficult or not, but
can we *break the Hitachi's ABI compatibility* ?
The right thing for the future is to unite these ABI
interface into one... Producing many incompatible
binaries/libraries seems uselessness.
Is it acceptable ?
-- gotom
Reply to: