Re: Future of m68k - Etch and beyond
Hi,
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, 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.
FP is even worse, the fp registers have different sizes, long double
support is different and the fp return value is different.
> 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).
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.
> > 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?
At this point I more see it as a experiment (interesting though I admit)
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.
bye, Roman
Reply to: