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
>> >>
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:
>> > 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:
> > 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:
> 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:
> >> > 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:
>> > 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:
> > 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
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
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
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
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:
>> 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
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:
> 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:
> > 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:
> 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:
> >> 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:
>> 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
> 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:
>> > 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
> > 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:
> >> >> 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
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 determine h
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
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
> >> 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
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
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
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:
> 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
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 of the MIPS toolchain it is being
33 matches
Mail list logo
