sim's -DPROFILE=1 conflicts with CGEN's PROFILE attribute

[Doug Evans]

Ben Elliston writes:
 > Hi Greg,
 > 
 >    Now, A(PROFILE) erroneously expands to (1 << CGEN_HW_1) rather than
 >    the intended (1 << CGEN_HW_PROFILE).
 > 
 >    I see a couple solutions, and will provide a patch for whichever the
 >    maintainers prefer:
 >    1) fix desc-cpu.scm to no longer define & use A(x), but rather generate
 >       (1<<CGEN_HW_x) in-line.  Same for other definitions & uses of shorthand A(x).

I like the readability that the use of A() and others of its ilk adds.

 >    2) shift an underscore from the definition of A(x) and into the arg,
 >       like so:
 >    	#define A(a) (1 << CONCAT2 (CGEN_HW,a))
 >    	use: A(_PROFILE)

[pedantic: _[A-Z]* is owned of compiler]

 > I'd prefer to see #1.  Macros are bad, m'kay?

Like anything they need to be used with care.
The opc.c files are more readable [to me] with the macros.

An alternative is to rename CGEN_{FOO}_{ATTRIBUTE} to
CGEN_{FOO}_A_{ATTRIBUTE}.  Having attributes named like
CGEN_INSN_RELAXABLE kinda bothered me anyway, whereas
I much more like CGEN_INSN_A_RELAXABLE [or s/_A_/_ATTR_/].

On the other hand, another useful clean up is the whole
attribute definition scheme.  Note that CGEN_{FOO}_{ATTRIBUTE}
needn't have the same value across ports.  There's a kludgey
mechanism to support having attributes that you want to have
the same value across ports.  Generally it makes sense to
have all predefined target-independent attributes have the same value
[by `value' I mean "p/d CGEN_{FOO}_{ATTRIBUTE}" in a gdb session
would print the same number].

I think we should pick a direction _before_ deciding on a bandaid
[assuming one doesn't want to bite off the whole enchilada right away].
For the time being, if a fix is needed sooner rather than later is
there a patch that can be done to the i960 simulator?
(if we're going to have a bandaid, let's localize it as much as possible)