Re: m68k bootstrapping broken

[Bernardo Innocenti <bernie@develer.com>]

Peter Barada wrote:

>>>It won't be that hard to make it work for a 5206e/5272/528x/5249, at
>>>least from the core perspective(just need to add the div/mod
>>>instructions and the extra v2 insn for the 528x).  Adding in the v4
>>>instructions shouldn't be too hard either.
>>
>>Yes, but I think the emulator also lacks the required infrastructure
>>to select multiple CPUs at run-time.
> 
> Yes, it does.  Its all trade;  do you add ColdFire bits to UAE and then
> go through the hassle of getting uClinux to boot, or do you add the
> other bits to the emulator at lightbox.  I understand that performance
> of the emulator at lightbox can be improved, and I see ways to speed
> it up, or do we take all ot the above and produce one frm scratch that
> has the benifit of being usable as a simulator by GDB?

Do we really need to start from scratch?  Can't we massage existing
code until it fits into GDB's simulator infrastructure?

Even though in the end you'll have rewritten every single line of the
emulator, usually the time you save in design and debug are worth it.

I tend to avoid starting projects from scratch when there's even the
smallest chance to use existing code, as ugly, buggy or limited as it
may be :-)

By the way, all the projects we're talking about GPLed, so there are
no legal issues.


> I'm happy to go in any direction, I just want to know its the right
> one :-)  As a side note, I've already started on building a UAE style
> instruction decoder for ColdFire, and have a decoder that produces a
> full table for V4. It should be pretty trivial to have it genreate the
> table at startup based on which CPU model you want...

That's great news!  UAE's cpugen also has some questionable x86
optimizations done by post-processing GCC's assembly output.  Of course
it breaks on every new GCC release, so I don't think I'd want to maintain
such a thing ;-)


Another thing.  I'm playing with libffi to see if I can get it to work
on plain 68000.   Do you know a simple instruction sequence to replace
this bit-field operation?

   bfins   %d0,(%a1){#0,%d2}


I was thinking of something like this (in pseudo-C):

   mask = (1 << (d2 & 0x1f)) - 1;
   *a1 = (*a2 & ~mask) | (d0 & mask);

This should work like bfins for any value of d2,
but the code as produced by GCC is quite longwinded:

        moveq   #31,%d1
        and.l   %d1,%d0
        move.b  #1,%d1
        lsl.l   %d0,%d1
        subq.l  #1,%d1
        move.l  %d1,%d0
        not.l   %d0
        and.l   (%a1),%d0
        and.l   %d1,%d2
        or.l    %d2,%d0
        move.l  %d0,(%a1)

Is there a more efficient way?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/