Olin Lathrop wrote:

>>> As you can see the variables declared with 'const' are really static
>>> (like the 'static' directive in C) while the ones with the 'var'
>>> are 'auto' variables (aka sits on the stack).
>>
>> I find this at least not intuitive. I'd expect a const to be constant.
> 
> In the Pascals I am familiar with CONST defines compile time symbolic
> constants only.  Certainly my version works this way, although it
> often realizes these constants as static read-only variables. 
> 
> Note that Tamas' code doesn't prove how exactly the compiler
> interpreted the CONST symbols.  Either interpretation would have
> resulted in the same output.  For that matter his code doesn't even
> prove the constants are static if they are implemented as values in
> memory locations.  Since you can only read them and then you always
> read the same value, you can't tell whether you are reading a
> different memory location each time or whether the compiler is
> substituting the symbol's value on the fly.

:: const
::   globConst: Integer = 999; {<<<}
:: 
:: procedure test ( par: Integer );
:: const
::   v1: Integer = 0;
:: var
::   v2: Integer;
::   v3: Integer absolute globConst; {<<<}
:: begin
::   v1 := par;
::   v2 := par;
::   v3 := par; {<<<}

It seem the compiler assigned a memory location to the constant
globConst, because v3 is pointed to that memory location. It also seems
that in the line where v3 is pointed at that memory location, the
compiler didn't really care that it was defined as a constant; it
allowed pointing a variable to it, which later was written to.

> The only way to tell would be to take the address of a symbolic
> constant. If you get a compile error, then its just a symbolic
> constant.  If it works, then you still don't know whether the
> compiler created a literal only because you asked for the address. 
> You can pass a symbolic constant to a subroutine pass by reference
> parameter and see if the the address changes with nesting level.  If
> so, then these things aren't variables at all since the compiler is
> creating the argument anew each call. 
> 
> It's very tricky to tell the difference, which also makes it so you
> don't need to care in most cases.

This seems to assume that a constant remains constant, which in the
above isn't the case. He didn't try to access globConst under that name,
but if the "absolute" directive does what I think it does, its value
will have changed after the last cited line above.

As he later explains, constants defined like that aren't constants, more
like static variables in C. Bad naming; nothing constant to a static
variable. And the 'real' constants don't seem to have a type, similar to
the preprocessor #defines in C. Not good either; in a strongly typed
language, constants should also have a type. Well... nothing's perfect
:)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist