🚀 go-pugleaf

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

--- Comment #1 from Joel Sherrill <joel at gcc dot gnu.org> 2011-01-24 21:06:15 UTC ---
Created attachment 23108
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id#108
Hacks to disable problem areas

This patch is a hack to conditionally disable the parts of the code which cause
issues in various multilib configurations.  I see a few general areas:

+ mc68000 does not appear to be able to tst.l an address register
+ presence of FPU -- probably need to have conditionally selected alternative
for when soft FP is in use
+ At least one Coldfire (5206) does not appear to have long double so the
switch statement for all the return types in ffi.c has a duplicate case error.
I think my fix is adequate for this.

For the assembly file, I am unsure as to how to properly fix them.

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> 2011-01-24 21:36:52 UTC ---
This is the wrong way to fix that.  The m68k SYSV ABI requires 68020+ w/
68881/2.  If you use a different ABI you should write a proper implementation.

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

--- Comment #3 from Joel Sherrill <joel at gcc dot gnu.org> 2011-01-24 21:53:28 UTC ---
I didn't intend to disable them permanently.  Just identify them to implement
alternatives.

If the sysv abi cannot be used on 68000, 680x0 w/o HW FP, or at least some
Coldfire, then what is the alternative ABI?  GCC has rules on the ABI on those
targets.  Is it radically different or just slightly modified to accommodate
the differences?

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> 2011-01-25 06:18:47 UTC ---
The alternative ABI is just slightly different.  When using the 68881, floating
point values are returned in %fp0.  When not using it, floating point values
are returned in %d0 or %d0/%d1.

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

--- Comment #5 from Joel Sherrill <joel at gcc dot gnu.org> 2011-01-25 18:15:41 UTC ---
(In reply to comment #4)
> The alternative ABI is just slightly different.  When using the 68881, floating
> point values are returned in %fp0.  When not using it, floating point values
> are returned in %d0 or %d0/%d1.

I think I have implemented single and double precision soft float support.
How is extended float returned?

#if defined(__MC68681__)
    fmove.x    %fp0,(%a1)
#endif

The only other issue in sysv.S is using tst.l %aX which is not supported on a
mc68000.  I just used a cmp.l %aX,#0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

Joel Sherrill <joel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23108|0                           |1
        is obsolete|                            |

--- Comment #6 from Joel Sherrill <joel at gcc dot gnu.org> 2011-01-25 18:47:36 UTC ---
Created attachment 23123
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id#123
Second try at multilib and m68k-*-rtems* support

There aren't a lot of changes to compile for all variants.  I have taken a shot
at the changes. The issues are:

+ tst.l %aX not supported on mc68000
+ soft float changes the returns from %fpX to %d0, %d0/%d1, or (I think)
%d0-%d2
+ Coldfire 5206 does NOT have long double.

The other change is to not use the syscall in ffi.c.  It conditionally now
supports the RTEMS Cache API.

How does this patch look?

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

--- Comment #7 from Ian Lance Taylor <ian at airs dot com> 2011-01-25 19:17:49 UTC ---
The patch looks reasonable to me, though I would like to hear Andreas's
opinion.

Technically this patch should go to the libffi maintainers, as libffi is
maintained in a separate repository.  According to
http://sourceware.org/libffi/ the right address is
libffi-discuss@sourceware.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47442

--- Comment #8 from Andreas Schwab <schwab@linux-m68k.org> 2011-01-25 20:05:54 UTC ---
>+#ifdef __rtems__
>+void rtems_cache_flush_multiple_data_lines( const void *, size_t );
>+#else

Include the header that declares it.

>+	cmp.l	#0, %a1

        cmp.w    #0, %a1

>+	move.l	%d0,(%a1)
>+	move.l	%d1,4(%a1)

    move.l    %d0,(%a1)+
    move.l    %d1,(%a1)

>+	move.l	%d0,(%a1)
>+	move.l	%d1,4(%a1)
>+	move.l	%d2,8(%a1)

    move.l    %d0,(%a1)+
    move.l    %d1,(%a1)+
    move.l    %d2,(%a1)

>+	move.l	(%a0),%d0
>+	move.l	4(%a0),%d1

    move.l    (%a0)+,%d0
    move.l    (%a0),%d1

>+	move.l	(%a0),%d0
>+	move.l	4(%a0),%d1
>+	move.l	8(%a0),%d2

    move.l    (%a0)+,%d0
    move.l    (%a0)+,%d1
    move.l    (%a0),%d2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47442

--- Comment #9 from joel.sherrill at oarcorp dot com 2011-01-25 20:34:03 UTC ---
On 01/25/2011 02:06 PM, schwab@linux-m68k.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47442
>
> --- Comment #8 from Andreas Schwab<schwab@linux-m68k.org>  2011-01-25 20:05:54 UTC ---
>> +#ifdef __rtems__
>> +void rtems_cache_flush_multiple_data_lines( const void *, size_t );
>> +#else
> Include the header that declares it.
>
It isn't available when this library is built.

OK on the other suggestions.
>> +	cmp.l	#0, %a1
>          cmp.w    #0, %a1
>
>> +	move.l	%d0,(%a1)
>> +	move.l	%d1,4(%a1)
>      move.l    %d0,(%a1)+
>      move.l    %d1,(%a1)
>
>> +	move.l	%d0,(%a1)
>> +	move.l	%d1,4(%a1)
>> +	move.l	%d2,8(%a1)
>      move.l    %d0,(%a1)+
>      move.l    %d1,(%a1)+
>      move.l    %d2,(%a1)
>
>> +	move.l	(%a0),%d0
>> +	move.l	4(%a0),%d1
>      move.l    (%a0)+,%d0
>      move.l    (%a0),%d1
>
>> +	move.l	(%a0),%d0
>> +	move.l	4(%a0),%d1
>> +	move.l	8(%a0),%d2
>      move.l    (%a0)+,%d0
>      move.l    (%a0)+,%d1
>      move.l    (%a0),%d2
>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47442

--- Comment #10 from Joel Sherrill <joel at gcc dot gnu.org> 2011-01-25 20:42:19 UTC ---
(In reply to comment #8)
> >+#ifdef __rtems__
> >+void rtems_cache_flush_multiple_data_lines( const void *, size_t );
> >+#else
> 
> Include the header that declares it.
> 
> >+	cmp.l	#0, %a1
> 
>         cmp.w    #0, %a1
> 

Why cmp.w when it is tst.l?

--joel

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

--- Comment #11 from Andreas Schwab <schwab@linux-m68k.org> 2011-01-25 20:53:37 UTC ---
"joel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:

> Why cmp.w when it is tst.l?

Because it is smaller.

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG442

Joel Sherrill <joel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23123|0                           |1
        is obsolete|                            |

--- Comment #12 from Joel Sherrill <joel at gcc dot gnu.org> 2011-01-25 20:58:37 UTC ---
Created attachment 23125
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id#125
Third try at multilib and m68k-rtems* support

This should address the comments.

"joel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:

> Why cmp.w when it is tst.l?

Because it is smaller.