Compile Problem? 2 Variables at same location?!???

Steel

I have code, and it seems as though 2 variables are at the same location!

In my code, I have the following declared:


VAR
··· Byte ACTIVATE, MODE,BUFFER[noparse][[/noparse]32], LOCK··


in my code, I am using the TV Terminal to output the variable locations:


··········· TV.HEX(@LOCK, 8)
··········· TV.OUT(13)·

Because of other long variables, the address of "Lock" was 29B6.
I ran this code again with "@BUFFER[noparse][[/noparse]32]" and the address was 29BA.

Here are the following Variables I checked, and their addresses:

·29B5··· Buffer[noparse][[/noparse]27]
·29B6····LOCK······ ···· !!!
·29B6··· Buffer[noparse][[/noparse]28]····· !!!
·29B7··· Buffer[noparse][[/noparse]29]
·29B8··· Buffer[noparse][[/noparse]30]
·29B9··· Buffer[noparse][[/noparse]31]
·29BA··· Buffer[noparse][[/noparse]32]

I thought something was funny, and started going through the Array, and Low and Behold, BUFFER[noparse][[/noparse]28] is showing the same location as LOCK!!!

If anybody wants to look at the code, I can email it to you...I just don't want to publicly post it (yet).

Is there an error with the compiler that would allow access to a memory location by 2 different variables?

Shaun

Post Edited (Steel) : 8/21/2007 7:03:07 PM GMT

deSilva

Couldn't produce your problem - looks fine in my test.
Give the whole code, please!

Phil Pilgrim (PhiPi)

If you rewrite your program each time to check a different variable — especially a subscripted variable vs. a simple variable — the variable allocation will change. Try writing one program to check all the variables you're interested in.

-Phil

deSilva

.. the reason for this being that VAR (the "yellow" area) is allocated after the static (the "red") area.

Stupid of me!

Phil Pilgrim (PhiPi)

This may still reveal something about the compiler. The code for accessing an array element with a constant subscript should take up no more room than that for accessing a scalar. The fact that your code size changed (assuming you used a constant subscript) implies that subscripting was included in the object code, even though a fixed address could have been used instead.

-Phil

rokicki

The prop compiler does not do *any* optimizations, including the one you describe.

There's no constant folding. If you go

a := 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1

it will do all the arithmetic at runtime (although there is a constant keyword to
help with this).

Similarly,

a := @v[noparse][[/noparse]30]

will do the subscripting a runtime, despite the use of a constant.

And trying to wrap @v[noparse][[/noparse]30] in constant() won't work either.

Yet another reason I've wanted to write my own Spin compiler.

Phil Pilgrim (PhiPi)

rokicki,

Although it would be nice to have these kinds of optimizations in the compiler, it might be best to leave them out and do any optimizations in a preprocessor. My reasoning is this: So long as the compiler doesn't optimize, it's easy to predict what kind of code it will produce and design a preprocessor around those assumptions. If the compiler optimizes, but poorly or not to someone's satisfaction, it's much harder to work around those optimizations in a preprocessor. Plus, with a preprocessor, you can actually see the optimizations in the processed source code. This assumes, of course, that for every optimization, there's a canonical source equivalent that compiles optimally. That this is true for constant folding should be obvious. But for other kinds of optimizations, it may not be.

In any event, I hope the next IDE version includes the necessary hooks to make user preprocessor incorporation seamless. That way, you and I, and everybody else who has ideas about how Spin should compile or evolve can either write their own preprocessor or choose someone else's that they like. It's democratic, and Parallax doesn't have to support it; so it's a win for everbody!

-Phil

Fred Hawkins

Wish list: a simple .binary reader -- hand it the compiler's eeprom file and get back a decoded dump in a txt file.