Re: FOSDEM thoughts
On Fri, Feb 29, 2008 at 06:18:39PM +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.
This is not entirely accurate. AIUI, a working TLS implementation will
allow us to build optimized libraries that will be chosen by the dynamic
linker at run time. If we build, say, a C library optimized for
coldfire, one for 68040, and one for 68060, I think that will greatly
improve performance already. Some more libraries (e.g., libssl, libm,
...) could benefit from this type of multi-identity stuff, too.
Of course any hybrid port will suffer from performance degradation; but
I think having any port which works on classic m68k is, by far,
preferable over not having any port, at all, that would work on classic
m68k, which is what our eventual fate will be if we don't do anything to
prevent that.
> > 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.
A hybrid port would just emit two opcodes in such a case, of course.
This will indeed degrade performance slightly.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: