This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking


Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Richard Sandiford <rdsandiford@googlemail.com> writes:
>> Matthew Fortune <Matthew.Fortune@imgtec.com> 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 to increase
>> > the control a user has over architecture level. If we had .module
>> > arch= then having it just set the arch ignorant of FP mode seems fine,
>> > checking for erroneous combinations would be difficult due to some
>> > chicken and egg scenarios. Do you think I need to add .module arch= if
>> > I add .module fp= or can I take the easy option?
>> 
>> Despite the "arch controlling fp" difference, I think .set and .module
>> should use common parsing code.  I.e. we should generalise s_mipsset to
>> handle both of them rather than write a second parsing function for
>> .module.
>> There will be some cases where the function has to check "is this .set?"
>> (e.g. push/pop), but that's good IMO, because it makes the differences
>> obvious.
>> 
>> If we do have a common routine then we should make .module handle
>> everything it can handle rather than just fp=.
>
> Every case would need to look at set vs module as .set writes to
> mips_opts and .module writes to things like file_mips_arch? I suppose I
> could just rework all the global options to be part of a single
> mips_set_options structure to abstract this. Does that sound OK?

Yeah, that's the kind of thing I was thinking of.  FWIW, if this is feeling
like feature creep then I have a go this weekend.

> The push/pop case (and perhaps some others) will still need special
> handling to prohibit them for .module.

Right.  But like I say, that's good IMO, since the differences become
more obvious than they'd be with two different implementations.

> Back to one of your questions discussing things like:
>
> .module fp=xx
> .module arch=mips2
>
> An easy option would be to continue to have the arch options infer fp32
> or fp64 and require the .module fp=xx to come second. Then we just have
> error checking on the .module fp= option to ensure it is suitable for
> use with the previously specified architecture.

I don't think it's a good idea for the order of the .modules to matter.
I think as far as possible, putting .module in the code should be the
same as passing the associated command-line option.

It probably makes sense to prohibit .module after an instruction has
been assembled or after .set has been seen.  We could then handle the
.module-adjusted options at those points (or at the end, if there are
no .sets and no instructions).

> With .module in place like this then I expect the compiler should then
> start to record more information in the assembly text to indicate things
> like arch as well as fp. Obviously this will be tied to a configure time
> assembler feature test.

Agreed.

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]