On Sun, Feb 25, 2007 at 05:29:02PM +0100, Roman Zippel wrote: > On Sat, 24 Feb 2007, Wouter Verhelst wrote: > > At this point, though, I'm still convinced that it's possible to create > > a port which will work on both coldfire and "classic" m68k; and with a > > glibc that has TLS support (which we still need as well), it doesn't > > even have to slow down things too much (since you can compile optimized > > libraries where it makes sense, and have the dynamic linker select the > > right one at runtime). > > 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. 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). > and reducing it to the smallest common set, does no favour for neither > port, as you barely can use any advantage either has to offer. If we get TLS support (which we will need for glibc 2.5 to be usable anyway), then it'll be easily possible to have a libc package for classic m68k and one for coldfire CPUs; and we could do the same for other libraries when where it would make sense (say, an 060-optimized libssl. SSH connection setup anyone?) > 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? -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
