Re: [buildd] Etch?
On Fri, Aug 04, 2006 at 05:41:29PM +0200, Roman Zippel wrote:
> On Fri, 4 Aug 2006, Wouter Verhelst wrote:
> > Other than that, there are a number of opcodes that have been removed
> > (those relating to the BCD data format, for instance, and some others),
> > and most of those that remain have lost a number of addressing modes as
> > well, which I guess you already knew. In some cases, this may indeed
> > mean that you have to do things with two opcodes instead of one. The
> > most problematic point where this is true is in PC-relative jumping;
> > this must be done with two instructions on ColdFire, since you can not
> > do postindex or preindex addressing modes for the JMP opcode there
> > (which is what the classic 68k PLT implementation does).
>
> Especially in library code you need a lot of 32bit offsets to access a
> variable, which had to be loaded into a register first.
>
> > > Currently we at least assume an 68020 cpu, but for CF support we had
> > > to go back to the 68000 and then there are still a few instructions
> > > missing (mostly byte/word operations). To be honest I'm not looking
> > > forward to this prospect.
> >
> > First, it's not really true that you must assume a 68000 CPU. It is
> > may be true that the number of available addressing modes per
> > instruction is closer to the 68000 than it is to the 68020 or the 68040;
> > but if you have a look at the instructions that exist, you will see that
> > the ColdFire is far more advanced than the original 68000. That being
> > said, it is certainly true that hybrid code will not be the most optimal
> > code anywhere.
>
> CF added a few instruction to compensate, which we couldn't use either
> (e.g. sign extended move from memory), so some things which take a single
> instruction on m68k and two instruction on CF would need three
> instructions on a hybrid.
Possibly.
> Last time I checked the cas instruction is also not available, which
> makes multithreaded code interesting.
This is an issue I didn't know about yet. It's indeed missing, but I
didn't know that these instructions were that important.
Can you give me an example of how it's actually used in multithreading?
> > As I see it, however, we have two alternatives to a hybrid architecture:
> > the first is that we do nothing, keep things as they are, and have the
> > port face more and more moments like this one as time progresses;
> > eventually, there will be a point where we will simply have to give up.
> > Having the port run on ColdFire hardware as well will slow this
> > evolution down; if not indeterminally, then at the very least by a few
> > years.
>
> A hybrid doesn't automatically fix the toolchain problems and doesn't
> really make the toolchain maintainance any easier, if it worked for CF it
> would also work for m68k.
Of course not; I don't think I ever implied that.
However, it would solve several other outstanding problems which we have
and that have to do with the age of the hardware. This is certainly
important.
> How many users would this really add? AFAICT this is pretty much all
> embedded.
I think you're underestimating the importance of embedded use of Debian.
The arm port is pretty much all embedded, too, but it still has many
users.
I've seen actual embedded developers use Debian systems to base their
embedded file systems on. In fact, I've once been hired to help create a
CD-ROM that would be sold to embedded developers to make the
installation of a cross-toolchain and some base libraries easier. This
was all based on Debian.
I'm being told that this type of things happens rather often; so yeah,
making the port useful for embedded developers would certainly add a lot
of users.
Besides, there are actually amiga upgrades being sold based on ColdFire
processors. See http://elbox.com/faq_dragon.html and
http://elbox.com/news_04_12_17.html. That being said, I don't know how
popular those are, or indeed even if they actually sold any of those
already.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply to: