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

[Stuart M. <stu...@st...>]

On Fri, 15 Mar 2002 18:40:28 +0000
dav...@st... wrote:

> mr...@0x... wrote:
> > 
> > Paul and I have been trying to determine the best fit for the SH-5 port for
> > 2.5.  The problem lies in the SH-5's (and SH-6's) addressing - it's 32-bit
> > versus 64-bit, so the standard kernel convention for a 64-bit port doesn't
> > necessarily qualify it as "sh64" (but hey, we're kernel hackers, we can
> > bend the rules :P).
> 
> Well, I don't see any problem calling it a 64 bit. For me, the
> fundamental criteria
> for calling it a 64 bit port is that a pointer is 64 bits. This is
> supported by the 
> gcc toolchain (I've never tried it though), and all the internal
> registers are quite 
> happy with 64 bits. Yes, it is true that at the moment on the SH5 you
> can't address more 
> than 32 bits of physical, but I would view this as an implementation
> detail, not an architecture 
> restriction.  I agree that is a pain that the 64bitness is implemented
> by sign extension
> rather than real bits, but it is possible to build a kernel that would
> work with this way 
> of doing things and "real" 64 bits without too much pain I think.

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.

> Anyway, the current port isn't 64 bit, which is why it is an sh5
> directory rather than
> sh64. It should really be called shmedia in retrospect I suppose.

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.

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.

> > Moving the SH-5 port in with the sh/ arch is a challenge
> 
> Absolutely. What I do not understand is what benefit you see from doing
> it this way. 
> As far as I can see it will simply make a mess of the current SH
> support, as it is 
> a different machine from an OS point of view.  Every arch specific file
> will be duplicated, 
> and will create an unholy mess for no benefit. Please explain what you
> see as the benefits.
> 
> 
> > is trying to plan for structuring future SH processors.  Will the SH-7 and
> > SH-8 retain the SHmedia instructions and 32-bit addressing?  Or will
> > Hitachi have a change of mind and switch to 64-bit addressing if the market
> > calls for it?
> > 
> 
> Rememeber that the architecture of future SH processors is controlled by
> SuperH Inc,
> not Hitachi. However, Hitachi and ourselves at ST can be safely
> described as major customers 
> of SuperH. I also think you have answered your own question, if somebody
> wants a real 64 machine
> I'm sure SuperH will be more than happy to oblige, given that the
> architecture is already 64 bit 
> so a 64 bit everywhere machine would be very easy for them to build. I
> do not think they will
> categorically state that they will never build a full 64 bit machine.
> Anybody at superh care to 
> comment?
> 
> As to SHmedia, I think that it is here to stay. It is the main
> instructions set of 
> the machine. A more pertinant question would be how long  SHcompact
> stays around for.
> Backward compatibilty costs both in terms of silicon area and
> verification, so it is 
> not beyond the realms of possibility that SuperH would produce a future
> processor that 
> is SHmedia only.  I can't speak for SuperH here, but it must be regarded
> as a possibility.
> Again I suspect that you will not get a statement saying SuperH will
> always support
> SHcompact in hardware indefinately for all future machines. Comments
> from SuperH are invited.

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.

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.

I think the question becomes whether is it worth SuperH maintaining
support for SHcompact in future SHmedia based devices.

SHcompact has two attributes:
 - it has a certain level of binary compatibility with SH4
 - it is compact (!)

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.

The compact nature of SHmedia is still of interest, in areas where code
density is more important than performance. However I think it is
unfortunate that SuperH decided to get compact encoding in this way,
as it is partly for this reason that the SH5 is still limited to 32 bits
in some areas. Remember you can inter-call SHmedia and SHcompact functions,
so imagine a function call from code written in SHmedia to a function in
SHcompact code, which takes a pointer as a parameter. That parameter is
passed in a 64 bit register, but the called code can only see 32 bits of
it. While you have to support this scenario, there is probably no point
in going to more than 32 bit addressing.

So my guess would be that in future SHx variants, SHcompact has to be
under threat. It will start to get in the way either when they push up
the clock rate, or try to go true 64 bit. So at one extreme it could
be dropped, or it may start to become slower relative to SHmedia
(because it is being emulated at some level), or at the very least,
mixed mode programs will be restricted to 32 bit virtual addresses
only, and if you want to use 64 bit addressing the code must be pure
SHmedia.

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!

However, I reiterate, this is personal opinion only, based on no facts
whatsoever.

> > If future SH processors are "true" 64-bit machines (well addressing at
> > least), then it makes sense for the SH-5 and SH-6 to live with the SH-3 and
> > SH-4 code, but if the SH-7 and SH-8 retain current SHmedia and 32-bit
> > addressing (e.g. they won't differ "externally" from the SH-5 or SH-6), then
> > it makes sense for all SHmedia capable processors to live in "sh64".  This is
> > why we need a bit of clarification (if at all possible) of the plans to stick
> > with 32-bit addressing, so it'll potentially save us some work down the road.

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!).

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.

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.

So my vote would be to put treat the SH5 as a new architecture, called:
  First choice:  shmedia
  Second choice: sh5
  Third choice:  sh64

Stuart