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. > 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. Thanks, Richard
