linuxsh-dev

[linuxsh-dev] SH-5 integration issues

[M. R. B. <mr...@0x...>]

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

Moving the SH-5 port in with the sh/ arch is a challenge, but the problem
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?

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.

Is this making sense to people?  We need your insights and suggestions
before we can make the formal proposal of SH-5 inclusion :).

Thanks,

M. R.

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

[David M. <dav...@st...>]

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.

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.

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


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

Again, I don't understand why you want to include sh5 code in
with the SH3/4 stuff. It will be a maintenance nightmare. If we think a
64 bit port
is a good idea, then lets create an sh64 directory and be done with it.
Otherwise lets 
stick to sh5 as a new 32 architecture (since it is effectively a new
machine). 

> Is this making sense to people?  We need your insights and suggestions
> before we can make the formal proposal of SH-5 inclusion :).
> 

Sort of, but I don't agree with you:-) I don't see the benefits, and I
can see the problems.

And also, I confess I am confused to exactly who you are going to make
this formal proposal to. Could you explain this further?

Cheers!

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

[Jeremy S. <js...@mv...>]

I'm far from knowledgeable about the SH5, but it sure sounds to me like it should
be a different arch... not least because the people who've been working most
closely with it (doing the port) seem to feel that way.  Maybe call it "shm" or
"shx" if the longer "shmedia" that was suggested is unacceptable for some reason.

And if there's already a sparc and sparc64, and mips and mips64, why not an shnew
and shnew64?  (Is it because the other have major system architecture changes
between 32-bit and 64-bit implementations, while the SH5 has already incorporated
all such major changes?)

--Jeremy Siegel


David McKay 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.
>
> 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.
>
> > 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.
>
> > 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.
> >
>
> Again, I don't understand why you want to include sh5 code in
> with the SH3/4 stuff. It will be a maintenance nightmare. If we think a
> 64 bit port
> is a good idea, then lets create an sh64 directory and be done with it.
> Otherwise lets
> stick to sh5 as a new 32 architecture (since it is effectively a new
> machine).
>
> > Is this making sense to people?  We need your insights and suggestions
> > before we can make the formal proposal of SH-5 inclusion :).
> >
>
> Sort of, but I don't agree with you:-) I don't see the benefits, and I
> can see the problems.
>
> And also, I confess I am confused to exactly who you are going to make
> this formal proposal to. Could you explain this further?
>
> Cheers!
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev

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

[David W. <dw...@in...>]

js...@mv... said:
>  And if there's already a sparc and sparc64, and mips and mips64, why
> not an shnew and shnew64?  (Is it because the other have major system
> architecture changes between 32-bit and 64-bit implementations, while
> the SH5 has already incorporated all such major changes?)

Due to lots of duplicated code, there's work under way to merge mips and 
mips64. 

--
dwmw2

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

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