[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Future of m68k - Etch and beyond

Roman Zippel wrote:
> 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).

BTW, it's the reason why we cant' use qemu-m68k to create virtual m68k build
machine : qemu supports only coldfire and thus is not able to run 68020 objects.


Reply to: