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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> 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?).

Yeah, .module should be a different configure test.  I don't think we need
an fpxx test though.  We don't usually do configure checks for passed-down
-m* options since it's really the assembler's job to say what it accepts.
It also means users can upgrade binutils without rebuilding GCC.

We only need configure tests (like .module) for optional enhancements
that get used under the covers.

>> > 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').

Like you say, it'd be good to hear other people's thoughts.

I think in practice a loader is going to have a reasonable interface
for accessing a given segment, so it should just be a setup call, some
error checking, and a tear-down call.

The advantage of encoding it directly in header types is that it avoids
having to do those things.  The advantage of a single header is that all
the data is directly available as a single struct, rather than it being
scattered over multiple headers (presumably handled via a switch statement).

Which ends up easier depends on how many bits of info we put in there,
and of course that's likely to change (increase) over time.

Thanks,
Richard