Re: [linuxsh-dev] SH5 kernel

[Paul M. <le...@Ch...>]

On Thu, Feb 28, 2002 at 09:59:58PM +0000, Stuart Menefy wrote:
> Short answer, I've no idea. SH8000 is Hitachi's part (and as fasr as I kn=
ow
> is the only chip with an SH5 core at the moment).
>=20
So how does this relate to reference hardware? Does everyone have to go
through Hitachi for reference hardware? And what about ST50, is there anyth=
ing
special about that? or hardware?

> Unfortunatly it's not so clear cut. Yes, the instructions are twice as bi=
g,
> but you shouldn't need as many do do the same thing:
>  - the SH-Media instructions are three address (as opposed to SH3/4's two
>    address)
>  - you have access to a lot more general purpose registers
>  - the instruction set handles branches better (less pipeline stalls)
>  - the instruction set handles loading constants better (most are now
>    encoded directly in the instruction).
> Plus loading instructions can be easily predicted, so you should rarely
> still the pipe for an I fetch, but data fetches are less predictable, and
> tend to result in stalls, so should be avoided as far as possible,
> especially on embedded devices which tend to have smaller caches. So even
> if you fetch more instructions, you should fetch less data, resulting in
> a net performance gain.
>=20
> In summary, using SH-Media instructions should be faster than SH-Compact,
> but may be slightly larger. =20
>=20
That puts a slightly different spin on things.. it no doubt would probably =
be
faster from what you've described, but the object/binary size will also be
considerably larger .. much in the way that mips32 is considerably larger in
comparison to SH4 right now (since mips uses 32bit instructions as well).
But, if you can get more done with less instructions, that seems to be a
considerable win as well.. I guess we'll have to wait and see how things wo=
rk
out.

> The 64 bit issue has several aspects:
>  - the compiler - gcc should support both 64 and 32 bit modes, but 64 bit=
 hasn't
>    been tested much (here at least)
>  - the architecture - this has been designed for 64 bit
>  - the implementation - this is 32 bit. Many registers only have 32 bits
>    implemented (eg PC)
>  - the OS
>=20
> Again, its a difficult question. The decision was made that as the current
> implementaion of SH5 is 32 bit, there was no benefit in making the OS 64 =
bit,
> and probably a performance and memory size penalty in doing so. If an
> implementation with more then 32 bits is ever produced, then some work wi=
ll
> be needed in the kernel to support it.
>=20
There rarely are any advantages to running the OS 64-bit. Even mips64 and
friends still usually get away with a 32-bit userland .. much in the same w=
ay
that IRIX64 wasn't run on the majority of 64-bit platforms. There's usually
more drawbacks then there are benefits with going this route..

> It hasn't been forgotten about, and there are plenty of places in the code
> where typedef's and macros have been used to make moving to 64 bit easier.
> Whether this makes it a 64 bit port though, I'm not sure.
>=20
With the code structured the way it is, it would be interesting to play with
doing things as a 64-bit port and still permit it running 32-bit.. mips64
duplicates some things around in this fashion, though things are usually
preferrably running in 32-bit.

> Things like entry.S have to be in SH_Media. When the CPU takes a trap, it
> always reverts to SH-Media. Plus many of the registers and instructions y=
ou
> need to access to handle traps, caches etc are only available in SH-Media.
>=20
That's what I was afraid of..

> A lot depends on your point of view. Personally, I feel that the SH5 effe=
ctivly
> a new CPU, which just happens to be able to run SH4 executables. In a sim=
ilar
> way the ia64 is new CPU, which is capable of running i386 binaries (maybe=
..).
>=20
> I understand marketing people have a slightly different opinion, because =
they
> want to preserve the appearence of a SuperH family line, from SH1 through
> to SH5 and beyond.
>=20
> Its not an obvious decision either way. This is partly why I proposed the
> new project. We can get the code out in the open, thrash out issues like =
this,
> before comitting to a naming scheme and possibly merge, and ditch the sh5
> project.
>=20
That might not be a bad idea for initial work.. though keeping it in the
LinuxSH CVS under its own module would still seem to be the more useful
answer, since it can be scrapped later when its obsoleted. Plus, if no one =
is
interested in cleaning up the website the way it is now, it's still not hard
to add a link to some SH5 space and toss all information regarding the state
of the tree and such there.

> > If there's interest in this, I'd have no problems taking care of updati=
ng the
> > SH5 tree and merging it into the existing drop-in, if there are no other
> > takers.
>=20
> Its pretty high on our TODO list, but how long it will take to happen rem=
ains
> to be seen. I may need to take you up on that!
>=20
Lack of hardware makes testing a bit of a peculiarity, but as long as someo=
ne
else is willing to do testing, I'm more then willing to do the kernel work.

> > Either way.. lets have a look at the tree first, and then we can figure=
 out
> > what the best course of action might be. Or if anyone else has any simi=
lar
> > insight on the matter, that could be helpful too.
> >=20
>=20
> OK, so how about before we go any further I post it on an FTP server
> first, and then we can have a more informed discussion?
>=20
Sounds like a plan.

Regards,

--=20
Paul Mundt <le...@ch...>