Re: [linuxsh-dev] SH-5 integration issues

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

On Sat, Mar 16, 2002 at 04:32:57AM +0000, Stuart Menefy wrote:
> I still can't make up my mind whether we should try and go for a full
> 64 bit port or not, or if it even makes sense with the current
> hardware. However whatever we do about merging or not and naming, we
> should try and define interfaces now which would allow 64 bit support
> in the future - system calls being the most obvious one, but I'm sure
> there are others. Whether we start work on making the current tree
> properly 64 bit now, or wait until a true 64 bit device appears really
> depends on people's time and inclination.
>=20
This is somewhat of a double-edged sword. Really, the SH5 code could be
treated as both .. straight shmedia, and shmedia64. The problem with that
though is that there's endless amounts of duplication between the two, so it
seems to really be more of an "all or nothing" situation. However, if there=
's
enough interest in treating it as a real 64-bit port, that's really the only
sane way to deal with it.

> Having proposed sh5 in the first place, I've now changed my mind! I
> think Dave's suggestion of shmedia (or something similar) might
> actually be a better choice.
>=20
> Given that what we are talking about is actually the architecture of
> the SH5 actually being different from the SH4 (instruction set being
> the obvious example), this seems like a good way to distinguish
> them. And it has the big advantage that when SH6/7/8 or whatever comes
> along (and whether we go for a true 64 it port now, in the future or
> never), we're not left with a misleading name, which both sh5 and sh64
> could be.
>=20
shmedia would indeed not be misleading, but what about when people start
wanting a "real" 64-bit port for SH5/6? or what's if SH7/8 suddenly jump to
64-bit addressing? I suppose in that sense, shmedia64 makes sense, though t=
hen
there's quirkiness to deal with in addressing changes. Treating SH5/6 as
shmedia64 shouldn't be too big of a deal, but as soon as something that uses
true 64-bit addressing comes along, it gets a little bit messy.

> I'm speculating here as well, I don't know what SuperH's plans are for
> anything beyond SH5, and I doubt if they do either. It will all depend
> on what the market demands. So I wouldn't hold my breath waiting for
> an answer to any of these quiestions.
>=20
> However, I do think SHmedia is the future. Its 64 bit, it should be
> quite a bit faster, and it was designed with an eye to future CPU
> directions (superscaler, super-pipelined, high ratio of CPU to memory
> speeds etc). It also has room for expansion (lots of unused
> instruction opcodes) unlike SH4/SHcompact.
>=20
Judging from what SuperH has been saying about SH6 so far, it'll be an
extension to SH5 .. an extension in the sense that it'll be super-scalar as
well as super-pipelined. It'll still retain SHmedia, as well as 32-bit
addressing. (That's all subject to change naturally, though.)

> I think the question becomes whether is it worth SuperH maintaining
> support for SHcompact in future SHmedia based devices.
>=20
> SHcompact has two attributes:
>  - it has a certain level of binary compatibility with SH4
>  - it is compact (!)
>=20
> I suspect compatibility with SH4 was thought to be important in the
> WinCE/HPC market, where the ability to continue to run old binary
> applications might be useful. Unfortunately that market appears to have
> been lost to ARM, so I think that requirement has gone away.
> I know implementing a single CPU which could execute both instruction
> sets efficiently caused lots of problems to the designers, so as clock
> rates go up they will be looking for areas to simplify, and SHcompact
> would be a candidate.
>=20
I suppose this really depends what kind of value people put on backwards
compatability, other then just the buzzword-compliance issue. For the market
that SH5 seems to be after, I don't see too many people caring about backwa=
rds
compatability, especially at the ABI level.

For things like WinCE, that's certainly something that could be potentially
beneficial .. but then again, the majority of the SH-based handhelds that w=
ere
floating around were still using a 7709 of some sort. I can count the number
of SH4 based PPC/HPC's on one hand, and this does certainly seem to be a de=
ad
market now as well (at least for non-ARM, even MIPS is experiencing hurdles,
people are resorting to forking the WinCE code base). PocketPC 2002 has pre=
tty
much obliterated non-ARM from the market anyways.

I don't see SHcompact living on past SH6. Especially when comparing SHcompa=
ct
instructions to some of the SH5 SIMD instructions, the future for SHcompact
looks rather bleak. Instruction size is a bit of a nuisance .. SHmedia will
force SH into the same sizes that people like MIPS play in, which is
unfortunately rather largeish. But at the same time, with SHcompact really
only being useful for non-critical performance applications where binary si=
ze
is more of a concern than speed, you have to kind of stop and wonder what
people are using SH5 for in the first place.

> That is not to say that the current SH4 will not be enhanced. I would
> expect SuperH to continue to enhance the SH4, but if they do that I
> would expect the device to be supported by the current Linux sh
> architecture part of the tree. Although what it will be called in
> anybody's guess, maybe they will have to resort to fractional numbers:
> SH4.1 perhaps!
>=20
The current SH4 is being enhanced. Things like the 7751R for instance. Larg=
er
caches, two-way set associative caches, etc, etc.

> I think the 32/64 bit argument is a bit of blind alley at the
> moment. The issue from my point of view is that the SH3/4 and SH5
> architectures are different (instruction sets, interrupt controllers,
> MMU, caches, PCI, etc.) so there would be very little common code. In
> fact I suspect they would share only slightly more code than sh does
> with i386 (which is actually quite a lot!).
>=20
Interrupt controllers, MMU handling, caches, PCI differences, etc, etc. are
_all_ common differences between any processor. This in itself does not
warrant the creation of a new architecture under linux. MIPS deals with this
all the time.

Things like the instruction set differences start becoming more of an issue
though.. supporting multiple entry.S/head.S's and ifdef'ing inbetween them =
is
ugly, at best.

> As the SH5 architecture is capable of supporting 64 bit operation,
> differences between a 32 or 64 bit implementation should be very
> small, and hopefully constrained to some #ifdefs in header
> files. The one exception to this might be how to handle the PCI
> interface in a 64 bit world, but at least that is constrained to no
> more than a few files.
>=20
Agreed, there shouldn't be too many differences between the two. But as soon
as you start running into things that do "real" 64-bit addressing, things
might start to get a little uglier..=20

> The presence of SHmedia to aid backward compatibility complicates the
> issue, but the approach we have taken with the port is to not use it
> in the kernel. This was done mainly for performance reasons, but also
> to leave to door open for 64 bit support, and some nagging doubts
> about its future.
>=20
Er, I presume you mean SHcompact here?

> So my vote would be to put treat the SH5 as a new architecture, called:
>   First choice:  shmedia
>   Second choice: sh5
>   Third choice:  sh64
>=20
Since SH6 will most likely be folded relatively easily into the SH5 code ba=
se,
I don't see the second choice here as being something to consider. shmedia
sounds fine, but I'm still leaning more towards sh64 simply for cleanliness=
 ..
the problem comes in when you start having true 64-bit platforms (potential=
ly
SH7/8) vs faked 64-bit platforms with 32-bit addressing (SH5/6).

Bearing this in mind, my vote looks something like:

  First choice:  sh64
  Second choice: shmedia

And I'm leaving out the third choice, as I don't really see one that's viab=
le.

Regards,

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