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


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? The push/pop case (and perhaps some others) will still need special handling to prohibit them for .module.

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.

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.

Regards,
Matthew


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