Andrew, > you create the TargetVariable arc_mpy_option, however, I think it > would be neater to fold this variable into the mmpy-option as it was > before, but, changing the type to Enum. This would allow the big > option checking switch to be removed from arc-common.c, which I think > is a win overall. > > I wasn't 100% certain that the above would actually be possible, so I > put together a prototype, I've included the patch below, that applies > on top of your patch. Hopefully you'll agree that it's a nice clean > up.
Thanks for the suggestion. > I wonder where the vale 0x10000000 comes from, what's the significance > of it. I could ask the same question about the magic -1 constant, but > it's rather more obvious that -1 is just a no-value-selected magic > number. I guess my questions for 0x10000000 are why this specific > value? What does it mean? I need a value to mark if the variable in question is changed by a command line option or not. This is required when we set the cpu's specific configuration. I'll include this comment in the description of the define for clarity. > and also the driver-arc.c file. You seem to be missing support for > nps400 in here. Specifically, if I pass -mcpu=nps400 to GCC I'd > expect the generated assembler file to include ".cpu NPS400", and the > assembler to be driven with "-mcpu=nps400". This patch was crafted way before the new ARC binutils to be upstreamed. Hence, it needed to work with the "old" binutils which had no support for nps400 :) > Admittedly we're missing a GCC test for this (there's a patch below > for just such a new test). > > I think the solution could be fairly easy, if we tracked the specific > processor type in arc_cpu_t structure we could specialise in > arc_override_options and in driver-arc.c, though I don't know if you'd > agree that this is the right approach... I'm not entirely sure > myself... but it might be the easiest approach to move us forward. > Anyway, I include a patch for that below too, feel free to use or not > as you see fit. I am preparing a patch to binutils which should be able to recognize all GCC's cpu variations as valid .cpu pseudo-op argument. Hence, we can just pass to the assembler the appropriate .cpu variation seamlessly. If it is ok with you, I would like to come with a new patch on this topic after I extend .cpu support in binutils. Alternatively, I can include your suggestion now, but then I will refurbish it later on. Please let me know what do u fancy most. Thanks, Claudiu
