This is the mail archive of the
mailing list for the GCC project.
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers (joseph at codesourcery dot com)" <joseph at codesourcery dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>
- Date: Tue, 18 Mar 2014 20:16:00 +0000
- Subject: RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534AAE6E at LEMAIL01 dot le dot imgtec dot org> <878ut0fj45 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AD16E at LEMAIL01 dot le dot imgtec dot org> <87ppmbdobm dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AEB92 at LEMAIL01 dot le dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B023534B4C29 at LEMAIL01 dot le dot imgtec dot org> <87r46hbybi dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B572B at LEMAIL01 dot le dot imgtec dot org> <87mwh5bslv dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B581D at LEMAIL01 dot le dot imgtec dot org> <8761nsbj9w dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B7B3A at LEMAIL01 dot le dot imgtec dot org> <871tygbexk dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B7FA7 at LEMAIL01 dot le dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B023534C0BEE at LEMAIL01 dot le dot imgtec dot org> <874n31i4qj dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534C3E04 at LEMAIL01 dot le dot imgtec dot org> <87vbvch70x dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534C4A69 at LEMAIL01 dot le dot imgtec dot org> <87r460gdd6 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534C4D20 at LEMAIL01 dot le dot imgtec dot org> <8761nbgwcy dot fsf at talisman dot default>
Richard Sandiford <firstname.lastname@example.org> writes:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > Richard Sandiford <email@example.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
> >> (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.
Fantastic. I think the only loose end is:
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').