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
C values that are not known at compile time
Started by ●December 21, 2005
Reply by ●December 21, 20052005-12-21
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
Reply by ●December 21, 20052005-12-21
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
Reply by ●December 21, 20052005-12-21
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
Reply by ●December 21, 20052005-12-21
*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.
Reply by ●December 21, 20052005-12-21
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. �����������������������������������������������������������������������
Reply by ●December 21, 20052005-12-21
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. > > JerryI agree. I was trying to ask him if he was asking "RIGHT" question ;)
Reply by ●December 21, 20052005-12-21
>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.
Reply by ●December 21, 20052005-12-21
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
Reply by ●December 21, 20052005-12-21
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
