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

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: