Richard Sandiford <rdsandif...@googlemail.com> writes: > Matthew Fortune <matthew.fort...@imgtec.com> writes: > > Richard Sandiford <rdsandif...@googlemail.com> writes: > >> Matthew Fortune <matthew.fort...@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
