constants pre-evaluated?

[Mark Hunter]

Does the compiler pre-evaluate constants so that the computation is not done at run-time? For example you might have

Macro Foo(x) = (x)*256 + 1
%dim = 10
%dimA = Foo(%dim)

Does that last line compile the same as
%dimA = 2561

[Eric Pearson]

Yes.

[Stuart McLachlan]

The answer to both questions is Yes.
Constanta are evaluated during compilation.
The macro Foo is expanded when encountered dunring the compile time evalaution of %dimA

[Mark Hunter]

And something like
x = 5 + y + 4
gets compiled the same as
x = y + 9
?

[Stuart McLachlan]

And something like
x = 5 + y + 4
gets compiled the same as
x = y + 9
?

No idea about that sort of optimisation, guess you'd have to decompile a test application to find out.

[Dale Yarker]

In post 1 x is known at compile time (%dim = 10); so %dimA can be resolved at compile time.

In post 4 y is not known at compile time. Will y in the middle interrupt resolution; or will 5 and 4 be added? Either way resolving x has to wait till run time; I agree with Stuart about decompiling.

edit - aside: key word (ie dim in this case) as a constant/variable name???? may work, asking for a problem (IMO)

Cheers,

[Eric Pearson]

> Will y in the middle interrupt resolution

I tested this during a beta cycle (not the last one) and the compiler is smart enough to resolve the "constant math" at compile time.

[Dale Yarker]

[Michael Mattias]

And something like
x = 5 + y + 4
gets compiled the same as
x = y + 9

If you are worried about that, you are worried about the wrong things. This would NOT be what is slowing your program or making your executable file overly large.

[Eric Pearson]

If you are worried about the questions that other people ask, you are worried about the wrong things.

[Michael Mattias]

If you are worried about the questions that other people ask, you are worried about the wrong things.

Huh? On a Peer Support Forum? I thought that was why people posted questions here in the first place!

[Eric Pearson]

Mark didn't say that his program was slow or bloated, he asked a question about how the compiler works. I don't see any reason to critique that; the only information that your post provides is about your personal opinion.

[Stuart McLachlan]

mark didn't say that his program was slow or bloated, he asked a question about how the compiler works. I don't see any reason to critique that; the only information that your post provides is about your personal opinion assumption.

fify

[Mark Bullivant]

And something like
x = 5 + y + 4
gets compiled the same as
x = y + 9
?

No, but x = 5 + 4 + y will compile to 9 + y. Everything to the left of the variable will be evaluated to a single value so long as there is no hint of floating-point arithmetic and the operands are integer literals or equates, so our discussion is really only relevant to integer expressions involving the operators that will not produce non-integer results from integer operands. It's not whether they will in a given instance, it's whether they can in any instance. Some examples:

intvar = 23 + 1 * 2 --> intvar = 25

but

intvar = 23 + 2/1 --> intvar = 23 + 2/1

and

intvar = 23 + 2^1 --> intvar = 23 + 2^1

though

intvar = 23 +2\1 --> intvar = 25

[Dale Yarker]

No, but x = 5 + 4 + y will compile to 9 + y.

Did you see post 7?

[Stuart McLachlan]

> Will y in the middle interrupt resolution

I tested this during a beta cycle (not the last one) and the compiler is smart enough to resolve the "constant math" at compile time.

No, but x = 5 + 4 + y will compile to 9 + y. Everything to the left of the variable will be evaluated to a single value

So we have two diametrically opposed assertions. One stating how it was determined, the other a flat assertion with no explanation.

[Eric Pearson]

> x = 5 + y + 4

Honestly, it was years ago and I don't remember testing exactly that before/after scenario, so I'll buy Mark's assertion. It makes sense that the parser would be thrown off by that.

Generally speaking, later versions of PB do a very thorough job of resolving numeric and string constants at compile time, but I probably over-generalized.

[Rodney Hicks]

Methinks, y must have a value or you'll get a compiler error, ergo, the two 'diametrically opposed assertions' are both correct. There is nothing in x=5+4+y or in x=5+y+4 that relates to 'constant math'(there are no constants indicated). Only the rules of operator precedence apply to those two equations.

[Mark Bullivant]

EDIT: Sorry, the original post had the same source for both instances. Now fixed.

Thanks, Eric.

Here's the source:

FUNCTION PBMAIN () AS LONG

LOCAL x, y AS LONG


mDisassemTo(LAB01)
x = 5  + y +  4
LAB01:

WAITKEY$

END FUNCTION

This is the output:
'&H00000000: 8B C7 MOV EAX, EDI
'&H00000002: 83 C0 05 ADD EAX, 5
'&H00000005: 83 C0 04 ADD EAX, 4
'&H00000008: 89 C6 MOV ESI, EAX

Source:

FUNCTION PBMAIN () AS LONG

LOCAL x, y AS LONG


mDisassemTo(LAB01)
x = 5 + 4 + y
LAB01:

WAITKEY$

END FUNCTION

Output:
'&H00000000: B8 09 00 00 00 MOV EAX, 9
'&H00000005: 03 C7 ADD EAX, EDI
'&H00000007: 89 C6 MOV ESI, EAX

In both cases, EDI is y and ESI is x

[Michael Mattias]

%X= 4
%Y=5
%Z = %X + %Y

For sure the addition is performed at compile time.

[ADDED]

From my standard :"skeleton" file...

%ONE_FILETIME_DAY = 600000000 * 60 * 24
%ONE_FT_DAY = 864000000000&& ' 864,000,000,000
%ONE_FILETIME_HOUR = %ONE_FILETIME_DAY\24&&
%ONE_FILETIME_MINUTE = %ONE_FILETIME_HOUR \ 60&&