Re: m68k bootstrapping broken

[Peter Barada <peter@the-baradas.com>]

>>>>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 :-)

If you're tryong to make a McLaren F1 car, you surely don't want to
start with a Model T.  It all depends on what you're starting with and
what you're trying to make.  I do agree with ripping off as much so
the reinvention of the wheel is limited, but sometimes starting with a
clean slate is easier.

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

Yes, there is that. That's why I've been looking at both(in my copious
spare time of course).

>> 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 ;-)

I'll look at having it encode instructions with a model selector in
the first filed so we can have it produce different decode selectors.

>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?

Let me think for a bit.  Perhaps I'll code it up for superopt to
crunch over for a while...

-- 
Peter Barada
peter@the-baradas.com