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