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

Re: Debian for SuperH bootstrapping



YAEGASHI Takeshi wrote:
 > I still haven't seen a good explaination why sh3/4 need to be separate. I read 
 > that the ABIs were slightly different but I think I heard somewhere that gcc 
 > could be made to generate code that works on both. Can someone please point me 
 > at a good explaination?

It is complicated because there're many SH variants (it's the nature
of embedded system, you know).

Among various variants of SuperH, GNU/Linux (only) supports following
processors (you can check linux/arch/sh/config.in):

   SH-3:
	SH-7707
	SH-7708
	SH-7709, SH-7709A, SH-7709S
   SH-4:
	SH-7750, SH-7750S
	SH-7751
	ST40STB1

Note that we don't support SH-1, SH-2, SH-DSP series, and SH-7718
(SH-3 with single precision FPU) which is obsolete.  There is SH-7729
(SH-3 with DSP), it could be used as SH7709.

GCC for GNU/Linux on SuperH supports SH-3 and SH-4.  ABI is different
in three areas:
	Floating point arithmetic
	Calling convention (of structures on register)
	Instructions which can be placed at jump slot

Major difference of SH-3 binary and SH-4 is for floating point
arithmetic.  SH-3 doesn't have FPU, while SH-4 has.  GCC for SH-3
generates library call for floating point arithmetic, while one for
SH-3 generates machine instructions directly.  This issue could be
solved if SH-3 kernel would supports FPU emulation, but people using
SH-3 don't want to go that direction, because it slows down the
performance.  Here, using SH-3 wants SH-3 ABI.

Calling convention is different (it's defined by Hitachi), perhaps for
performance reason.  Hence, we cannot mix .o for SH-3 and .o for SH-4,
we need to distinguish.

At jump slot, there is constraint which instruction is OK or not.
This is different between SH-3 and SH-4.  For this, we cannot say
SH-4 is upper compatible of SH-3.  We can build the binary which
runs on SH-3 but not on SH-4.

Besides, people using SH-4 want to use SH-4 ABI.
-- 



Reply to: