Matthew Fortune writes:
> All,
>
> Imagination Technologies would like to introduce the design of an O32
> ABI extension for MIPS to allow it to be used in conjunction with MIPS
> FPUs having 64-bit floating-point registers. This is a wide-reaching
> design that involves changes to all components
Richard Sandiford writes
> Matthew Fortune writes:
> > All,
> >
> > Imagination Technologies would like to introduce the design of an O32
> > ABI extension for MIPS to allow it to be used in conjunction with MIPS
> > FPUs having 64-bit floating-point registers. This is a wide-reaching
> > design
Matthew Fortune writes:
> Richard Sandiford writes
>> I understand the need to deprecate the current -mgp32 -mfp64 behaviour.
>> I don't think we should deprecate -mfp64 itself though. Instead, why
>> not keep -mfp32 as meaning FR0, -mfp64 meaning FR1 and add -mfpxx for
>> modeless? So rather t
On 02/24/2014 10:42 AM, Richard Sandiford wrote:
>...
>> AIUI the old form never really worked reliably due to things like
>> newlib's setjmp not preserving the odd-numbered registers, so it doesn't
>>> seem worth keeping around. Also, the old form is identified by the GNU
>>> attribute (4, 4) so
Richard Sandiford writes
> >> AIUI the old form never really worked reliably due to things like
> >> newlib's setjmp not preserving the odd-numbered registers, so it
> >> doesn't seem worth keeping around. Also, the old form is identified
> >> by the GNU attribute (4, 4) so it'd be easy for the l
Doug Gilmore writes:
> On 02/24/2014 10:42 AM, Richard Sandiford wrote:
>>...
>>> AIUI the old form never really worked reliably due to things like
>>> newlib's setjmp not preserving the odd-numbered registers, so it doesn't
seem worth keeping around. Also, the old form is identified by the
Richard Sandiford writes
> Doug Gilmore writes:
> > On 02/24/2014 10:42 AM, Richard Sandiford wrote:
> >>...
> >>> AIUI the old form never really worked reliably due to things like
> >>> newlib's setjmp not preserving the odd-numbered registers, so it
> >>> doesn't
> seem worth keeping aroun
Matthew Fortune writes:
>> >> If we do end up using ELF flags then maybe adding two new EF_MIPS_ABI
>> >> enums would be better. It's more likely to be trapped by old loaders
>> >> and avoids eating up those precious remaining bits.
>> >
>> > Sound's reasonable but I'm still trying to determine h
Matthew Fortune writes:
> That sounds OK to me.
>
> I'm aiming to have an experimental implementation of the calling
> convention changes as soon as possible although I am having difficulties
> getting the frx calling convention working correctly.
>
> The problem is that frx needs to treat registe
> Matthew Fortune writes:
> >> >> If we do end up using ELF flags then maybe adding two new
> >> >> EF_MIPS_ABI enums would be better. It's more likely to be trapped
> >> >> by old loaders and avoids eating up those precious remaining bits.
> >> >
> >> > Sound's reasonable but I'm still trying to
> > Sorry, forgot about that. In that case maybe program headers would be
> > best, like you say. I.e. we could use a combination of GNU attributes
> > and a new program header, with the program header hopefully being more
> > general than for just this case. I suppose this comes back to the
> >
Matthew Fortune writes:
>> > Sorry, forgot about that. In that case maybe program headers would be
>> > best, like you say. I.e. we could use a combination of GNU attributes
>> > and a new program header, with the program header hopefully being more
>> > general than for just this case. I suppo
> Matthew Fortune writes:
> >> > Sorry, forgot about that. In that case maybe program headers would
> >> > be best, like you say. I.e. we could use a combination of GNU
> >> > attributes and a new program header, with the program header
> >> > hopefully being more general than for just this case
Matthew Fortune writes:
>> Matthew Fortune writes:
>> >> > Sorry, forgot about that. In that case maybe program headers would
>> >> > be best, like you say. I.e. we could use a combination of GNU
>> >> > attributes and a new program header, with the program header
>> >> > hopefully being more g
Richard Sandiford writes:
> Matthew Fortune writes:
> >> Matthew Fortune writes:
> >> >> > Sorry, forgot about that. In that case maybe program headers
> >> >> > would be best, like you say. I.e. we could use a combination of
> >> >> > GNU attributes and a new program header, with the program
Matthew Fortune writes:
> Are you're OK with automatically selecting fpxx if no -mfp option, no
> .module and no .gnu_attribute exists? Such code would currently end up
> as FP ABI Any even if FP code was present, I don't suppose anything
> would get worse if this existing behaviour simply continu
Richard Sandiford writes:
> Matthew Fortune writes:
> > Are you're OK with automatically selecting fpxx if no -mfp option, no
> > .module and no .gnu_attribute exists? Such code would currently end up
> > as FP ABI Any even if FP code was present, I don't suppose anything
> > would get worse if t
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Are you're OK with automatically selecting fpxx if no -mfp option, no
>> > .module and no .gnu_attribute exists? Such code would currently end up
>> > as FP ABI Any even if FP code was present, I don't suppose an
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> > Are you're OK with automatically selecting fpxx if no -mfp option,
> >> > no .module and no .gnu_attribute exists? Such code would currently
> >> > end up as FP ABI Any even if
Matthew Fortune writes:
>> I think instead we should have a configuration switch that allows a
>> particular -mfp option to be inserted alongside -mabi=32 if no explicit
>> -mfp is given. This is how most --with options work. Maybe --with-fp-
>> 32={32|64|xx}? Specific triples could set a defau
Hi Richard/all,
The spec on:
https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking has
been updated and attempts to account for all the feedback. Not everything has
been possible to simplify/rework as requested but I believe I have managed to
address many points cleanly.
Se
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> >> I think instead we should have a configuration switch that allows a
>> >> particular -mfp option to be inserted alongside -mabi=32 if no
>> >> explicit -mfp is given. This is how most --with options work. Mayb
Matthew Fortune writes:
> The spec on:
> https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
> has been updated and attempts to account for all the feedback. Not
> everything has been possible to simplify/rework as requested but I
> believe I have managed to address many point
Richard Sandiford writes:
> Matthew Fortune writes:
> > The spec on:
> > https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinki
> > ng has been updated and attempts to account for all the feedback. Not
> > everything has been possible to simplify/rework as requested but I
> > beli
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> >> I think instead we should have a configuration switch that allows
> >> >> a particular -mfp option to be inserted alongside -mabi=32 if no
> >> >> explicit -mfp is given. This
Matthew Fortune writes:
>> > With these defaults, the closest supported ABI is used for each
>> > architecture based on the --with-o32-fp build option. The only one I
>> > really care about is the middle one as it makes full use of the O32
>> > FPXX ABI without a user needing to account for arch r
Richard Sandiford writes:
> Matthew Fortune writes:
> >> > With these defaults, the closest supported ABI is used for each
> >> > architecture based on the --with-o32-fp build option. The only one
> >> > I really care about is the middle one as it makes full use of the
> >> > O32 FPXX ABI without
Matthew Fortune writes:
> As it stands I wasn't planning on supporting .module arch= I was just
> going to add .module fp= and leave it at that. The only thing I need to
> give assembly code writers absolute control over is the overall FP mode
> of the module. I don't currently see any real need t
Richard Sandiford writes:
> Matthew Fortune writes:
> > As it stands I wasn't planning on supporting .module arch= I was just
> > going to add .module fp= and leave it at that. The only thing I need
> > to give assembly code writers absolute control over is the overall FP
> > mode of the module.
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > As it stands I wasn't planning on supporting .module arch= I was just
>> > going to add .module fp= and leave it at that. The only thing I need
>> > to give assembly code writers absolute control over is the over
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> > As it stands I wasn't planning on supporting .module arch= I was
> >> > just going to add .module fp= and leave it at that. The only thing
> >> > I need to give assembly code wr
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Richard Sandiford writes:
>> >> Matthew Fortune writes:
>> >> > As it stands I wasn't planning on supporting .module arch= I was
>> >> > just going to add .module fp= and leave it at that. The only thing
>> >>
32 matches
Mail list logo
