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? The push/pop case (and perhaps some others) will still need special handling to prohibit them for .module. 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. 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. Regards, Matthew
