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

Re: FOSDEM thoughts

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.

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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: