Re: [buildd] Etch?
Hi,
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.
Last time I checked the cas instruction is also not available, which makes
multithreaded code interesting.
> 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.
How many users would this really add? AFAICT this is pretty much all
embedded.
bye, Roman
Reply to: