CASTalk.com

When writing small programs to test, it is a nuisance that compilers
replace any sequence of operations that can be worked out at compile
time, with the constant value.

Typically, I make such constant values be volatile, which forces the
compiler to load them. But volatile also forces other different
behavior so it changes the way the program is compiled.

I could use a function like rand() but that requires using a library,
which I prfer not to do as that also changes the program.

Is there any simple way a C program can assign a value to some
variable, such that the value is not known at compile time, without
using a library function?

Thanks,

Chris
====================
Chris Bore
www.bores.com

Chris Bore wrote:

When writing small programs to test, it is a nuisance that compilers
replace any sequence of operations that can be worked out at compile
time, with the constant value.

Typically, I make such constant values be volatile, which forces the
compiler to load them. But volatile also forces other different
behavior so it changes the way the program is compiled.

I could use a function like rand() but that requires using a library,
which I prfer not to do as that also changes the program.

Is there any simple way a C program can assign a value to some
variable, such that the value is not known at compile time, without
using a library function?

Thanks,

Chris
====================
Chris Bore
www.bores.com

What are you _really_ trying to do? Do you want to compile in values

that are different for each compile but still constant? Do you want to
have constants that can be modified by a debugger? What?

As an embedded programmer I think it's _great_ that compilers work out
constant expressions into constants -- it saves a great deal of
execution time, which is a good thing when you're working on a slow
processor.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Chris wrote:

Is there any simple way a C program can assign a value to some
variable, such that the value is not known at compile time, without
using a library function?

Is the value indeed not known at compile time? If it is not, and
the compiler is assuming it is, I'd like to see the code. If it is,
and you'd like the compiler to assume it isn't, I'd ask why.

--Randy

Jerry Avins wrote:

Richard Owlett wrote:

...

You might wish to investigate FORTH .


...

I invite Jerry Avins to jump in at this point as he is a more
accomplished FORTH programmer than I.


Chris wants to know how to make his C compiler do his bidding. Telling
him about another compiler might be useful, but maybe not. Telling him
about a compiler for another language seems to me to be out of place.

Jerry

I agree.

I was trying to ask him if he was asking "RIGHT" question ;)

Chris wants to know how to make his C compiler do his bidding.

Many people have long believed that computer languages
(and especially assembler languages) need to have the
instruction:
DWIM *; "Do what I mean!"

Luddites say that HCF *' Halt and catch fire" would be even better.

Richard Owlett wrote:

...

You might wish to investigate FORTH .

...

I invite Jerry Avins to jump in at this point as he is a more
accomplished FORTH programmer than I.

Chris wants to know how to make his C compiler do his bidding. Telling
him about another compiler might be useful, but maybe not. Telling him
about a compiler for another language seems to me to be out of place.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Randy Yates wrote:

Chris wrote:

Is there any simple way a C program can assign a value to some
variable, such that the value is not known at compile time, without
using a library function?

Is the value indeed not known at compile time? If it is not, and
the compiler is assuming it is, I'd like to see the code. If it is,
and you'd like the compiler to assume it isn't, I'd ask why.

My interpretation of Chris' post is that he wants to test some
computational
code with input parameters that de facto are known at compile time for
his
test routine, since he defined them. The parameters are not known at
compile time for "the real program." I can understand that things
change in
the two cases, depeding on how the test is implemented. I am very
curious
about an application where such details become as important as they
apparently are in this case.

Rune

*CAUTION*
I use " _AND_ ' significantly

Chris Bore wrote:

When writing small programs to test, it is a nuisance that compilers
replace any sequence of operations that can be worked out at compile
time, with the constant value.

Typically, I make such constant values be volatile, which forces the
compiler to load them. But volatile also forces other different
behavior so it changes the way the program is compiled.

I could use a function like rand() but that requires using a library,
which I prfer not to do as that also changes the program.

Is there any simple way a C program can assign a value to some
variable, such that the value is not known at compile time, without
using a library function?

Randy Yates wrote:

Is the value indeed not known at compile time? If it is not, and
the compiler is assuming it is, I'd like to see the code. If it is,
and you'd like the compiler to assume it isn't, I'd ask why.

Tim Wescott wrote:

What are you _really_ trying to do? Do you want to compile in values
that are different for each compile but still constant? Do you want to
have constants that can be modified by a debugger? What?

Randy and Tim raise important questions.

You might wish to investigate FORTH .
FORTH has two operators to assign a 'stagnant' number to a "label".
[ "label" is possibly a poor word choice, but then again I would never
be confused with a CS major ;]


CONSTANT creates a "label" with an _unchanging_ value.
VALUE creates a "label" with a _changeable_ value.

eg
1234 CONSTANT alpha
associates the quantity 1234 with alpha [ which _CANNOT_ be changed ]

5678 VALUE beta
associates the quantity 5678 with beta [ which _CAN _ be changed ]

alpha AND beta would subsequently be used _IDENTICALLY_ in source code

Using SwiftForth [ see forth.com comp.lang.forth ]

The machine code to print alpha would be
46E86F 4 # EBP SUB 83ED04
46E872 EBX 0 [EBP] MOV 895D00
46E875 4D2 # EBX MOV BBD2040000
46E87A 40935F ( . ) JMP E9E0AAF9FF

The machine code to print beta would be
46E89F 4 # EBP SUB 83ED04
46E8A2 EBX 0 [EBP] MOV 895D00
46E8A5 6C714 [EDI] EBX MOV 8B9F14C70600
46E8AB 40935F ( . ) JMP E9AFAAF9FF

Would these be *significantly* different in your application?

I invite Jerry Avins to jump in at this point as he is a more
accomplished FORTH programmer than I.

Chris Bore wrote:

When writing small programs to test, it is a nuisance that compilers
replace any sequence of operations that can be worked out at compile
time, with the constant value.

Compilers do this because it creates smaller and faster code,
which are some of the metrics by which compiler writers are paid.

However this is done in the optimizer portion, so either turn
off the optimizer, or the particular optimization causing the
problem (benchmark compilers sometimes have zillions of
different optimizer options), or play the game of
trick-the-optimizer. You might be able to trick the optimizer
by making it look like the variable might be changed in
some far off place (above your subroutine, in another called
subroutine, in another thread, by another process, etc.).
In the worse case of a nearly omniscent globally everything
compiler with infinite optimization, you need to input the data
from something the compiler never has access to (a file on
an unmounted disk stored in a rusty undergound file cabinet
marked "beware of tiger", or some such...)

Typically, I make such constant values be volatile, which forces the
compiler to load them. But volatile also forces other different
behavior so it changes the way the program is compiled.

I could use a function like rand() but that requires using a library,
which I prfer not to do as that also changes the program.

Is there any simple way a C program can assign a value to some
variable, such that the value is not known at compile time, without
using a library function?

IMHO. YMMV.
--
rhn A.T nicholson d.O.t C-o-M

On Wed, 21 Dec 2005 10:17:34 -0800, Chris Bore wrote:

When writing small programs to test, it is a nuisance that compilers
replace any sequence of operations that can be worked out at compile
time, with the constant value.

As others have said, that's generally a good thing.

Typically, I make such constant values be volatile, which forces the
compiler to load them. But volatile also forces other different
behavior so it changes the way the program is compiled.

I could use a function like rand() but that requires using a library,
which I prfer not to do as that also changes the program.

Is there any simple way a C program can assign a value to some
variable, such that the value is not known at compile time, without
using a library function?

Separate compilation is generally the way to go: put your
compile-time constants into your test framework, and put your routine
under test into a separate compilation unit. Make sure that you compile
that separately, to object code, and subsequently link the object code
with the C main, rather than putting all of the C files on one command
line (which might make the compiler cocky.) Make sure that your object
code is real object code, not some sort of intermediate form, and make
sure that your linker isn't clever enough to reverse engineer the code and
do inlining and post-optimization on it's own.

That way your function under test can be compiled with full optimization,
much as it might be in the final project.

I suspect that you've been at this game longer than I have, Chris, and you
almost certainly know all of this. What's the real question? Are you
using tools that are sufficiently advanced that this sort of
sleight-of-hand doesn't get past them?

There's probably another way to fool most compilers, if you really want to
produce one-module test files for reasons of convenience. (I often try
things out in stand-alone disposable "foo.c" files, myself): compiler
generally won't propagate a constant through a real function (but will
through a macro or inline). So you could create a do-nothing function like:

int const_int(int v) { return v; }

and put it in it's own .c file to make sure that auto-inlining tricks
don't apply. Then run your routine under test as:

....
test_me(const_int(10), const_int(8));
....

As long as const_int() is in a different compilation unit, that should be
enough to stop const propagation in most compilers, I think. (I've used a
similar techinique to force an optimizing compiler to actually cast from a
double to a float: apparently C standards allow the use of a "higher
precision" value to be used, if there's one handy. That makes computing
the (double-float) remainder painful (the result is always zero).)

Cheers,

--
Andrew

Chris--

When writing small programs to test, it is a nuisance that compilers
replace any sequence of operations that can be worked out at compile
time, with the constant value.

Typically, I make such constant values be volatile, which forces the
compiler to load them. But volatile also forces other different
behavior so it changes the way the program is compiled.

I could use a function like rand() but that requires using a library,
which I prfer not to do as that also changes the program.

Is there any simple way a C program can assign a value to some
variable, such that the value is not known at compile time, without
using a library function?

Normaly one would such kind of injections from outside the scope of C, sa
like using a scripting language like perl. Is that what you are lookin
for?

Additional comment: Why not disable optimization? Anyways, it seems yo
are only debugging the code, so why not turn-off optimization?

--Bhooshan

Thanks for the replies, all helpful.

I teach detailed optimization strategies that can be applied by a
programmer.
In small programs that illustrate a particular point, it is common for
most values to be in fact known at compile time and so constant
propagation effectively eliminates some code.
In 'real' situations these values would not be pre-determined, but
'real' code introduces complexities that I do not wish to deal with in
class, and tends also to be large and slow when simulated for
profiling.
I do not want to change optimization parameters, and I want to be able
to use small programs.
So I would like to find a simple way for some parameters to be 'not
known' at compile time.

A similar situation can arise when benchmarking - if y9u have a set of
test vectors that are known at compile time, then many results
calculated from these can also be known at compile time, so constant
propagation can give unrealistically fast benchmarks in these cases.

Chris

Is the value indeed not known at compile time? If it is not, and
the compiler is assuming it is, I'd like to see the code. If it is,
and you'd like the compiler to assume it isn't, I'd ask why.

The value is known, but only because the program is in this sense
artificially simple.
My problem is, how to retain the simplicity of example but to simulate
the non-constant-ness.

Chris

My interpretation of Chris' post is that he wants to test some computational
code with input parameters that de facto are known at compile time for his
test routine, since he defined them. The parameters are not known at
compile time for "the real program." I can understand that things change in
the two cases, depeding on how the test is implemented. I am very curious
about an application where such details become as important as they apparently are in this case.

That is a clear statement of what I intend, thank you.

If I could 'read in' real values from the 'outside world' then I would
have a fair test
(although I accept the results still depend on the test values).
But the code to read in values introduces libraries I do not want, and
makes the code larger and slower
(I am running in simulation). Hence the desire for some simple 'this is
what you might have got if you had read it in'.

Chris

Additional comment: Why not disable optimization? Anyways, it seems you
are only debugging the code, so why not turn-off optimization?

No, I am testing the optimization.

Chris