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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
