Re: [linuxsh-dev] SH5 kernel

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

Folks

On Wed, 27 Feb 2002 20:23:42 -0800
le...@Ch... wrote:

> On Wed, Feb 27, 2002 at 11:54:02PM +0000, Stuart Menefy wrote:
> > Following the release of an SH5 compiler and associated tools last week,
> > I pleased to be able to say that we are also almost ready to release
> > an SH5 Linux kernel.
> > 
> Good to hear. Any idea when the SH8000's will be readily available?

Short answer, I've no idea. SH8000 is Hitachi's part (and as fasr as I know
is the only chip with an SH5 core at the moment).

> Speaking of the kernel, what's the status of your guys kgdb work? Are there
> only SH5 specific hacks and stubs in your tree?

The kgdb stuff on www.linuxsh.st.com is for SH4 only. There is is currently
no kgdb support in the SH5 tree.

> > This work has been going for some time, in another group within ST, but
> > it is only now that the tools are available, and the architecture is
> > public, that we are able to release it.
> > 
> Does this mean that any code that was developed using the NDA'd documentation
> can be pushed into CVS now? Also, are there any updates to the documentation?
> If so, are these available without NDA?

Yep, all the docs which were used are now available without NDA. Boyd
posted a note on how to get them a few months ago:
http://sourceforge.net/mailarchive/forum.php?thread_id=261311&forum_id=5348

Unfortunatly SuperH still haven't posted them on their web site.

> > I say almost ready, because there are some last minute details to tidy
> > up, but mainly because I'd like to get people's suggestions on where we
> > should be putting this.
> > 
> Since you're looking for comments and suggestions on how the source tree is
> done presently, is there some place where we can take a look at the tree the
> way it is now, so that more accurate feedback can be offered?

No. I'm just waiting for a couple of key updates from the developers, which
they tell me will be available early next week.

> > First a bit of background:
> > 
> > As far as a kernel is concerned, SH5 is not a variant of the current SH
> > architecture, in the way that SH3 and SH4 are. It is a 64 bit processor,
> > with more and wider registers, different caches, MMU, interrupt controller
> > etc.
> > 
> > The CPU supports two instruction sets, the new instruction set
> > (called SH-Media) gives access to all the new facilities of the machine,
> > however it also supports a second instruction set (SH-Compact) which
> > is a subset of the SH4 instruction set, sufficient to support native
> > execution of SH4 _user_ _mode_ binaries. This means that a new kernel
> > must, at least in part, be written in SH-Media instructions. It could
> > also use SH-Compact if desired, but we've chosen not to do this at the
> > moment. And yes, Linux could support the native execution of SH4 binaries
> > if somebody felt like doing the necessary work in the kernel.
> > 
> I suppose the use of SH-Media extensively makes the most sense for the initial
> port, but in the long run, doing as much as possibly in SH-Compact would
> probably be faster and cut down on the overall object/resultant kernel size ..
> especially considering the differences in instruction sizes (and with -g
> turned on, saving as much space as possible is always a plus..). While this
> may not be worth thinking about right now, it still seems like something worth
> looking into in the future..

Unfortunatly it's not so clear cut. Yes, the instructions are twice as big,
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.

In summary, using SH-Media instructions should be faster than SH-Compact,
but may be slightly larger.  

> > So for this reason we decided not to merge the SH5 code with the current
> > SH3/4 kernel. We have created a new architecture called "sh5" in the kernel
> > source code, which is completely separate from the current "sh"
> > architecture. However it does share device drivers with the other SH
> > devices, such as the SCIF.
> > 
> > It could have been called sh64, but we decided against that as it
> > is not really a 64 bit port - pointers and longs are still 32 bits.
> > A full 64 bit port is still a possibility for the future.
> > 
> I'm not so sure that this is a good idea.. in the tradition of architecture
> naming schemes under linux things always follow the arch/arch64 approach.
> If the system is capable of sanely mapping things to 64-bit addresses without
> the system choking, then the arch64 thing seems to make more sense. If on the
> other hand, the system has issues with this, then it doesn't have much place
> in an arch64-type layout. From your indication of pointers being 32 bits, this
> would certainly seem to indicate that it's not ready for an sh64 convention.

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

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 will
be needed in the kernel to support it.

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.

> On the other hand, adding "sh5" completely goes against the natural order of
> things and should try to be avoided as vigorously as possible. While the SH5
> might not follow typical SH3/4 convention, that hardly warrants the creation
> of a new arch directory. Under MIPS, many systems have completely different
> caches, MMU's, TLB handling, etc, etc. all of these things are dealt with in a
> rather sane fashion -- of which I'm trying to achieve the same goal with the
> SH tree for 2.5, though I'm still working on restructuring things.
> 
> As long as the majority of things are done in SH-Compact, changes to things
> like entry.S should be rather minimalistic.. but it's hard to determine what
> the severity of the changes are without having any code to look at.

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 you
need to access to handle traps, caches etc are only available in SH-Media.

A lot depends on your point of view. Personally, I feel that the SH5 effectivly
a new CPU, which just happens to be able to run SH4 executables. In a similar
way the ia64 is new CPU, which is capable of running i386 binaries (maybe..).

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.

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.

> > So, the proposal:
> > 
> > I'd like to get this code checked into a CVS repository on SourceForge
> > as soon as possible. There are already several groups here who want
> > access to the sources, so this is easier than just putting it up for
> > FTP somewhere. Plus it allows other developers to join in as things
> > develop.
> > 
> > At the moment I think it may be better to create a new SourceForge
> > project for this, rather than use the current LinuxSH one.
> > 
> > This is mainly:
> 
> >  - the kernel is currently only of interest to kernel hackers, its
> >    not ready for general consumption.
> 
> The 2.5 restructuring tree for the LinuxSH isn't suitable for mere mortals
> either, and shouldn't even be approached by anyone other then kernel hackers.
> Yet it sits in CVS just fine. 
> 
> >  - because the current SH5 code is based around the old kernel, and is
> >    still fairly immature, it doesn't make sense to put it in the
> >    "linux" directory in CVS. It could go in a separate directory in
> >    CVS though.
> 
> In my opinion, there isn't enough reason to divide this stuff out into a
> completely seperate project.. putting SH5 under its own module for the time
> being would be fine, but it would be nice to forward port this stuff to
> current 2.4, and merge it into the 2.4 branch of the drop-in tree, where it
> can then be used by everybody and the other module could be removed in its
> entirety.
> 
> If there's interest in this, I'd have no problems taking care of updating the
> SH5 tree and merging it into the existing drop-in, if there are no other
> takers.

Its pretty high on our TODO list, but how long it will take to happen remains
to be seen. I may need to take you up on that!

> 
> >  - things are still very changable. Its quite possible major
> >    restructuring may still happen (renaming the architacture for example!),
> >    and we don't know at the moment how things will turn out.
> 
> I'd say concentrate on stable changes under the 2.4 branch if that's where
> this ends up going.. or just leave it in HEAD.. I'd prefer if  major
> restructuring would  be postponed until I'm done with the 2.5 restructuring of
> the tree, otherwise we might end up duplicating efforts. Plus, it should make
> assimilating SH5 in a sane fashion a lot easier..
> 
> > and then at some point in the future when the kernel is more mature,
> > and we know better what it will look like, we can think about merging
> > it into the LinuxSH project.
> > 
> If you start maintaining it independantly of the LinuxSH project from the
> beginning, it's just going to be more of a nuisance when you try and do the
> merge later. At present, the code is in its infancy, things can still be
> changed, etc, etc. with these things in mind, it's the best time to merge this
> into the LinuxSH project and beat it into submission..
> 
> 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 similar
> insight on the matter, that could be helpful too.
> 
> Regards,
> 
> -- 
> Paul Mundt <le...@ch...>

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?

Stuart

-- 
Stuart Menefy                                        stu...@st...
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com