equ expansion in redcode assembler

Archived from groups: rec.games.corewar (More info?)

Hello,

As some of you may know, I was writing another mars for some time. Now I've
gotten to the parser part, specifically implementing equ and for/rof
expansion.

I have a small problem: pmars allows to give an equ the name of instruction
modifier [f a b ab ba x i], which can lead to ambiguity when the equ of such
name is placed where the instruction modifier should be placed. In pmars it's
walked around by checking if there is a space and modifier - if yes, then the
equ is expanded, otherwise it's not.
So, the code:

f equ x
dat.f 0, 0
dat. f 0, 0

would be assembled to:

dat.f 0, 0
dat.x 0, 0

This, paired with the fact that pmars equ expansion isn't perfect textual
substitution, leads to a different problem:

ins equ dat
f equ x
ins.f 0, 0
ins .f 0, 0

after expansion becomes:

dat.x 0, 0
dat.x 0, 0

I have a couple of ideas about how to deal with above problems:

1) Add a restriction that equs are expanded only in arithmetic expressions.
This would eliminate any ambiguities completely, and would allow to run most
of existing warriors with trivial or no modifications. On the other hand,
pmars multi-line equs would be broken, and besides that, restrictions in general
aren't a good thing.

2) Add a restriction that equs with names of modifiers aren't allowed. I don't
really like this idea, since it eliminates many useful short identifiers.

3) Add a restriction that equs with names of modifiers aren't allowed
_in_place_where_the_regular_modifier_is_expected_. This is much lighter
restriction than the two above, but leads to an unconsistent behaviour.

4) Duplicate pmars behaviour. The question is, how closely - I was expecting
that equs would be substituted perfectly, so 'ins' equ would act exactly like
dat opcode.

Personally I'm in favour of the first solution, also taking into account that
the mars is designed to be component of optimizers, and as such, it doesn't
really need a fully featured parser. If you have any thoughts or ideas about
these, or related issues, I would appreciate you sharing them.

Michal