Re: Future of m68k - Etch and beyond
On Mon, 26 Feb 2007, Roman Zippel wrote:
> Hi,
>
> On Mon, 26 Feb 2007, Wouter Verhelst wrote:
>
> > > FP is even worse, the fp registers have different sizes, long double
> > > support is different and the fp return value is different.
> >
> > Floating point is not an exact science anyway; software which assumes
> > it is, is horribly buggy and hardly portable.
> >
> > Hence, rounding differences are not critical, so long as we can define
> > an ABI that adheres to the relevant standards.
>
> The point is that you need an ABI change for this (especially for the fp
> differences) and I'm not exactly looking forward to what would
> practically be a downgrade.
Quite.
If you assume that CF will never proliferate enough to justify a CF-only
port, you only have to worry about a loss of performance on classic m68k
machines.
But if there was a CF-based "ipod equivalent", would a hybrid cut it?
There's a huge gamble investing in a hybrid ABI (kernel, toolchain,
libraries...) with no way of knowing in advance whether the hybrid
sacrifices too much when compared to a CF-native ABI. We don't know which
CF variant will become the next iPod.
If CF devices continue to get bigger and better, then eventually the
hybrid _must_ sooner or later become a dead loss, instead of merely a
performance loss on classic-m68k. The only question is, will a CF-based
"ipod" appear before that happens (does it already exist?)
> > > and I wouldn't mind so much if it were an option, but I really don't
> > > like it if it's forced upon me and the whole survival of the m68k
> > > port is made dependent upon it.
> >
> > Well, at some point we will have to pick one or the other. It would be
> > nice if we could support ColdFire as well as "classic" (in my above
> > definition ;) m68k processors, and it would be desirable to have as
> > little performance degradation as possible.
> >
> > If that turns out to be not feasible, we'll then have to decide where
> > to go; the options as I see them at that point are these:
> > * Go with an emulator on an amd64 machine, and hope other Debian
> > Developers want to support an architecture which from their POV only
> > exists in emulation,
I haven't seen anyone object to emulators. Perhaps the Vancouver Massacre
can be read in part to exclude emulators, but then I thought m68k was
exempt from those parts (again, please correct me if I'm wrong).
> > * Discontinue the port,
> > * Go with ColdFire support only for Debian, and *perhaps* provide some
> > Debian derivative somewhere that will support "classic" m68k
> > processors.
Is there demand for coldfire from users?
> >
> > But that discussion will have to be based in data and with the option
> > there for the taking.
>
> It all depends on the place a port like m68k still has within Debian -
> is Debian willing to accommodate a port like m68k with its wellknown
> limitations. This requires of course compromises on both sides, but
> currently I don't see it. The current conditions (e.g. like required
> build speed) simply don't work for m68k and are basically intended to
> push out smaller and slower ports.
But what is this build speed requirement? Are we talking about the 98% of
the archive? The Aranym and distcc possibilities don't seem to help. So
how does coldfire possibility help WRT build speed?
Seems to me CF merely lets us lay some sort of claim to "relevance", as if
the ability to run a 3D compositing desktop on a handheld was important to
the Debian charter.
-f
> IMO this requires a discussion at large - is Debian a distribution only
> for the latest and fastest hardware or is there room for broader support
> and how could the latter look like.
>
> bye, Roman
>
Reply to: