Re: Future of m68k - Etch and beyond
On Sun, Feb 25, 2007 at 05:29:02PM +0100, Roman Zippel wrote:
> On Sat, 24 Feb 2007, Wouter Verhelst wrote:
> > At this point, though, I'm still convinced that it's possible to create
> > a port which will work on both coldfire and "classic" m68k; and with a
> > glibc that has TLS support (which we still need as well), it doesn't
> > even have to slow down things too much (since you can compile optimized
> > libraries where it makes sense, and have the dynamic linker select the
> > right one at runtime).
>
> It's probably not impossible, but I highly question whether it's really
> desirable. The instructions sets are already quite different
This is not true. The ColdFire V4e instruction set is a near-strict
subset of the m68k one. The only instruction in the core set that does
not yet exist on classic m68k is FF1, for "find first one" in a
bitfield; and as far as I can see, the only cases where the ColdFire
behaves significantly different from classic m68k are in FMOVEM (which
can be worked around by allocating two more bytes per copied register
than would be necessary on ColdFire) and when addressing using address
register postincrement or predecrement mode on A7 in byte context (which
can be rather easily avoided).
There are of course things like the EMAC and the likes, but those are
not part of the core ColdFire V4e instruction set, and there exist
indeed CF V4e CPUs that don't support it.
In any case, before switching debian/m68k to be a hybrid port, I do
intend to compare the speed of an older machine against the speed of a
"current" machine, and see what happens. It is my intention to provide a
valid alternative, not to come up with something which would be so
severly crippled that it would not make any sense for classic m68k
machines (I could just avoid all this hard work and get us a
coldfire-only port instead).
> and reducing it to the smallest common set, does no favour for neither
> port, as you barely can use any advantage either has to offer.
If we get TLS support (which we will need for glibc 2.5 to be usable
anyway), then it'll be easily possible to have a libc package for
classic m68k and one for coldfire CPUs; and we could do the same for
other libraries when where it would make sense (say, an 060-optimized
libssl. SSH connection setup anyone?)
> If this is seriously the only option left for Debian/m68k to survive,
> I will not support it.
I understand you wouldn't want to support something if the result really
turns out to be much worse than what we set out with. But could you at
least give it the benefit of the doubt?
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: