Bug in pMARS

Hi,

either I don't know how EQUs work or I have found
a bug in the parser of pMARS. So far I cound pin
it down to:

;redcode-tiny
;name test
;assert CORESIZE == 800

v3 EQU 3 * (3 / 2 + 1) + 3
v4 EQU (CORESIZE - v3)

dat.f v3, v4

With the settings for tiny pMARS' parses it to:

dat.f $ 9, $ -9

The value for v3 is correct, but v4 is wrong. It should
be

(800 - 3 * (3 / 2 + 1) + 3) = 800 - 3 * 2 + 3 = 797 = -3

The confusing part is, that in the debug output pMARS
seems to correctly replace the v3 in v4:

After pass 1
Instruction (physical line, instr):

( 11) DAT.f 3*(3/2+1)+3,(800 -3*(3/2+1)+3)

Can somebody, who knows more about pMARS' parser,
please confirm it as a bug? And if it isn't a bug, why does
pMARS evaluate it that way?

By the way I found that problem in the warrior "Borkked"
(Tiny Hill at Koenigstuhl).

Regards,

Jens Gutzeit

"Jens Gutzeit" <jens.RemoveThis@jgutzeit.de> wrote in message
news:1141655358.942251.41770@i40g2000cwc.googlegroups.com...
> [...]
> Can somebody, who knows more about pMARS' parser,
> please confirm it as a bug? And if it isn't a bug, why does
> pMARS evaluate it that way?

It seems to me that -9 may be the correct output.

The term "v3" is apparently evaluated prior to being used for "v4". I see
no reason for this to not be a legitimate evaluation, since it more
logically follows what was written.

The way you evaluated the term is consistent with how a C preprocessor would
do it. That is, expanding all terms to their literal value before
performing the calculation. However, I never seen any C code that actually
relies on this behavior. In fact, most experienced C programmers
automatically put parentheses around their #define'd terms to ensure that
they are evaluated atomically.

I don't know what the specification for the language is, and if the
specification dictates that the EQU op be evaluated the same way a C
preprocessor would do it, then you're right, and it's a bug. But if there's
no such requirement, it seems to me that the behavior is a reasonable
choice, given that programmers commonly try to avoid the C preprocessor
default behavior at every opportunity.

As far as the debug output goes, it seems to me that at the very least, that
is buggy. After all, it should indicate what is actually happening,
otherwise it's not very useful as a debugging tool.

Pete