Re: Status of m32c target?

[Jeff Law <law at redhat dot com>]

On 01/15/2018 11:11 AM, Joel Sherrill wrote:
> 
> 
> On 1/15/2018 11:31 AM, Segher Boessenkool wrote:
>> On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote:
>>> On 13/01/18 00:16, Jeff Law wrote:
>>>> On 01/12/2018 04:07 PM, Joseph Myers wrote:
>>>>> On Fri, 12 Jan 2018, Jeff Law wrote:
>>>>>
>>>>>> I was going to suggest deprecation for gcc-8 given how badly it was
>>>>>> broken in gcc-7 and the lack of maintenance on the target.
>>>>> While we're considering deprecations, what happened to the idea of
>>>>> setting
>>>>> a timescale by which cc0 targets need to be converted away from cc0
>>>>> or be
>>>>> removed?
>>>> I don't think we ever really hashed through what that might look like.
>>>>
>>>> I'd be comfortable saying gcc-8 is the deprecation point.  I know some
>>>> folks won't like that (someone already said so WRT the m68k, but didn't
>>>> step up to do the conversion), but I think that unless we set a point
>>>> nothing is likely to happen.
>>>
>>> How much work is it to convert the m68k to LRA. Is this person days,
>>> weeks, months or years?
>>
>> Converting m68k to cc0 is a daunting task.  This is a prerequisite to
>> enabling LRA, as mentioned.
> 
> I don't know if the Coldfire changes things but my recollection is that
> all the m68xxx instructions you expect to modify %sr do so. That
> doesn't make the task smaller but at least the m68k proper is simpler
> CISC as described in the linked page.
Coldfire doesn't change anything in a significant way from an
architectural standpoint WRT cc0.  THe only impact was that there's more
patterns that have to be audited and converted.


> 
> I know the m68k is an ugly beast with many years of architectural
> evolution from m68000 to m68060 and then all the Coldfire variants.
> It is one of the machine description files[1]. And I don't think there
> are free simulators already in use for testing it.
I've actually wondered if starting from scratch with an eye towards just
the 060, Coldfires and an emulated target would be easier.  Drop the
68000, 010, 020, 030, 040, and some of the old embedded mmu-less parts
I've forgotten.

The reason I mention an emulated target is aranym which does system
level simulation of the m68k -- enough you can boot debian, bootstrap
gcc and do all the usual things -- and on a reasonably modern system
it's faster than any m68k hardware that was ever built.  For that target
I strongly suspect you'd throw away all the micro-architectural crap and
optimize strictly for # of instructions that have to be fetched -- the
fetch & dispatch loop likely dominates over actual simulation of the
instruction from a performance standpoint.

> 
> But I **think** Sebastian is trying to figure out if this is something
> he can do or if we (RTEMS, GCC, etc communities) can fund from m68k
> and Coldfire users. Assuming this discussion isn't enough to chase
> the embedded users to another architecture. Old school folks keeping
> Amiga alive are a different animal
> 
> Is cc0 conversion enough to get m68k off the chopping block?
I would think so for this round.  I suspect there'd be another round in
the future to convert to LRA, but I suspect that'd be *much* smaller.

> 
> [1] Interestingly, the sparc, arm, powerpcspe, rs6000, and i386 are
> all larger .md files. The i386 is 2.5 times larger
:-)

Jeff