I personally agree that combining the ports together is a bad idea; no arguement towards the other has managed to sway me; FreeMiNT OS required an emualator layer running under its kernel and still required patching to be usable on Coldfire.
I also disagree that coldfire as a seperate port would kill m68k; go look at the three(?!) arm ports; they all use a single list and patches. We're even better off because to the compiler, coldfire and classic m68k are almost identical (a few different opcodes, and high preferences of some instructions). If I had coldfire equipment that could run a standard linux kernel, I'd already have bootstrapped the basic debian packages and started a buildd (and then deal with the trillions upon trillions of dep-wait emails that would soon follow :-P) (if anyone has a coldfire board and is willing to put Linux on it with a basic userland (busybox and dropbear would be enough; I can cross-compile a compiler and the basic userland, and APT), I'd do it right now. Michael On Fri, 2008-02-29 at 18:18 +0100, Roman Zippel wrote: > Hi, > > On Tue, 26 Feb 2008, Finn Thain wrote: > > > On Mon, 25 Feb 2008, Christian T. Steigies wrote: > > > > > > Getting the coldfire port working would be nice, yes... I believe that > > > > would bring in fresh blood and a general boost for debian-68k/cf... > > > > > > We had a discussion with Aurelien, Geert and Sven about coldfire. The > > > consensus was that we should not make cf a separate port, since we would > > > probably loose all m68k developers in that case. I personally am > > > interested in cf only if it can help m68k, > > > > That is my interest too. But surely that argues against your first > > statement about losing developers? > > As much as I understand to keep as much as possible common, I don't have > much hope if I look at it from the technical perspective. IMO a common > port would have too much restrictions and neither could use any of the > advantages either architecture has to offer. > > > What concerns me is that both 680x0 and CF code would be compromised if > > one port were to try to support both. > > > > I don't know if anyone can confirm this example, but it looks like no-one > > gets to use div without adding compatibility code, > > > > http://acp.atari.org/articles/mcf5407eval/mcf5407eval.html#Modifications%20of%20the%20MiNT%20kernel > > CF doesn't have the divul.l instruction, it has a remu.l instruction, > which unfortuately has the same opcode as divul.l (so the some machine > instruction will return quotient/remainder on m68k, but only the > remainder on CF). > The trick used there produces a signed and an unsigned divide, so that gcc > won't merge both operations into a single instruction. > > bye, Roman > >
signature.asc
Description: This is a digitally signed message part
