Re: Future of m68k - Etch and beyond
On Mon, Feb 26, 2007 at 02:53:52PM +0100, Roman Zippel wrote:
> On Mon, 26 Feb 2007, Wouter Verhelst wrote:
> > > 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.
>
> Linux doesn't just use the classic m68k instructions, it always required
> at least a 68020,
This is a confusion in wording on my part, I'm afraid. When I say
"classic m68k", I mean "non-coldfire m68k processors supported by
Linux", i.e., at least the 68020 :)
> so this had to go (this means e.g. less addressing
> modes and no bitfield instructions).
> Most CF instructions only have the 32bit variant, which makes 8/16 bit
> value handling more complex and you couldn't use the additions like
> mvz/mvs either to compensate for it.
True; there will be cases where the speed of compilation will suffer.
However, currently I'm of the opinion that most of this will be barely
noticeable, if at all. If this turns out to be false, however, I agree
with you that it would be madness to go on.
> 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.
[...]
> Sorry to sound so pessimistic, but the point I don't like is if this is
> only alternative allowed and everything else is not even up for discussion
> anymore.
That's not the case at all. It's just that I'm pessimistic about our
chances if we do _not_ use ColdFire, but do go for emulators and similar
stuff only.
I might turn out to be wrong, however, and I'll happily admit that if
this is where we eventually go.
[...]
> At this point I more see it as a experiment
At this point, an experiment is exactly what it is.
> (interesting though I admit)
Great! :)
> 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,
* Discontinue the port,
* Go with ColdFire support only for Debian, and *perhaps* provide some
Debian derivative somewhere that will support "classic" m68k
processors.
But that discussion will have to be based in data and with the option
there for the taking.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: