Re: Bootstrapping Debian GNU/Linux distribution on SuperH

["M. R. Brown" <mrbrown@0xd6.org>]

* ISHIKAWA Mutsumi <ishikawa@linux.or.jp> on Sat, Sep 22, 2001:

> 
>  So, We should migrate from old binary tree (binary-sh) to
> new binary trees (binary-sh3, binary-sh4, binary-sh3eb and
> binary-sh4eb).
> 
>  I want to propose the following prosess for smooth migration.
> 
>  0. Stop to working for binary-sh tree.
>    (I've already stoped autobuilder for binary-sh)
> 
>  1. Please add following binaries in ftp tree and katie database,
>     ftpmasters. 
> 
>     binary-sh3    ... Hitach SuperH SH3 little endian binaries 
>     binary-sh4    ... Hitach SuperH SH4 little endian binaries
>     binary-sh3eb  ... Hitach SuperH SH3 big endian binaries
>     binary-sh4eb  ... Hitach SuperH SH4 big endian binaries
> 

Question: Isn't it possible to build an entire chain based off the SH3E
processor?  gcc makes the distinction for the SH3E processor, so I would
assume that it deserves it's own target, unless the SH3E only differs from
the SH3 in that it includes a FPU.

What I'm trying to say is if someone wanted to target the SH3E they would
hit an ambiguity with the endian convention that Debian uses.  If this is
the way Debian specifies endianess for *all* ports, then it probably needs
to be changed.  Anyway, what I propose is:

	sh3le, sh3be
	sh3ele, sh3ebe
	sh4le, sh4be

to make sure you have *no* ambiguities in the binaries.  Now, you wouldn't
have to necessarily build the SH3E binaries (unless someone needed them)
but the specification is there.  I guess since little endian is the
default, you could skip the *le spec. for the archives (ala MIPS big
endian).

I'm saying this based on what NIIBE said before about ABI incompatibilites
and executable (at the assembly-level) incompatibilities, I would assume
that since the SH3E is a SH3+FPU it would still be ABI/binary incompatible
with the SH4.

M. R.