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

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Richard Sandiford <rdsandiford@googlemail.com> writes:
> 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.

Although it does seem like feature creep, I'm happy to do it as it gives a smaller problem for me to work on and submit to go through the motions. It may however be worthwhile tying this in with the introduction of -mfpxx to allow one assembler feature test to infer that both the new .module support and fpxx are implemented (or would you do this as two tests anyway?).
 
> > 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.

Fantastic. I think the only loose end is:
http://gcc.gnu.org/ml/gcc/2014-03/msg00204.html

I'm concerned about the program loader and dynamic linker having to read a segment as well as the header to get the feature bits when the program header fields could be interpreted specially for a new program header type. With 7 32-bit fields there are 224 bits of data available which seems quite generous and would be simple to read. As it stands ld.so carries around a pointer to and quantity of the program headers which means the data directly present in the headers is exceptionally easy to read, a segment is harder. (I hope I have the right terminology there with 'segment').

Regards,
Matthew