[Info-vax] decrementing & for loops in C
Johnny Billquist
bqt at update.uu.se
Mon Jan 12 18:15:55 EST 2009
nobody skrev:
> Johnny Billquist wrote:
>> nobody skrev:
>>
>>> vaxinf at chemie.uni-konstanz.de wrote:
>>>
>>>> Hi,
>>>>
>>>> I tried to run one of the example found on Jim Duff's homepage and
>>>> found a behavior of for loops written in C:
>>>
>>>
>>>
>>> Others have commented about the program not working, so I won't.
>>>
>>> Another thing you may experience with some compilers is that the
>>> result will be that both loops go in the same direction no matter
>>> what you write. The reason beeing that an optimizing compiler may
>>> realize that you are not doing anyting inside the loop that forces
>>> you to do it in a special order. Therefore it may choose to turn one
>>> of them around in order to do the execution faster.
>>
>>
>> True.
>> But for this example, the program is doing something inside the loop.
>> A function call (printf). And since one argument of that function call
>> is the loop variable, changing the order of the loop will change the
>> order of the function calls to printf with different values, so an
>> optimizer who did that, would potentially change the whole programs
>> effect. I doubt anyone would write an optimizer who did that. :-)
>>
>> You can only reorder a loop if it is obvious that this won't change
>> the way the program acts.
>>
>> Johnny
>>
>
> Well, I realized that soon after I posted. However I liked the amount of
> dust I stirred up. I'm not a C programmer but I am studying the crap and
> the more I learn the more I hate it.
:-)
I hate C sometime as well, but not for this reason.
> A C compiler actually has to give up for the reason you specify. It has
> no way to know what the called function does, since it's not until link
> time that the function call is connected to some function that hopefully
> has the same argument list. In a hypothetical other language the
> compiler could look at the called function to see what side-effects it
> had and decide if it could reorder. In the specific case with printf it
> would probably not be able to do it. Unless its able to write streams
> backwards.
Not entirely correct. C have had prototype definitions for functions for many
years now, and will check at compile time that the arguments in the call match
the definition of the function. At link time, no such checks are made, and never
have been. It the dark ages (long ago), C just did the calls blindly. There
weren't any checking anywhere.
> I believe Ada is such a language. There you have a package spec from
> which you can see if the code is ada or just something linked.
Sorry, but no. ADA cannot do that kind of optimizations either.
The specification for a function tells you how it is called, and with which
variables. It don't give you a clue of what the function will do with those
variables, nor what other things the function might do, which might have
"interesting" side effects, including modifying global variables anywhere.
So, function calls in general can never be reordered.
The one language that I can think of, off my head, which allows functions to be
executed in any order is Prolog. But you don't call them functions there, and in
the true form, nothing in Prolog can affect something in a way that can't be
undone again, so you'll get all permutations of call order you can ever imagine.
(Prolog is fun, but I doubt we should go through that here.)
Languages that are used to program in VHDL is a bit special, since it's all very
much parallel oriented. But I don't know how much of "functions" you have
there. Nor side-effects or global variables. So they are a bit limited in scope,
and can allow other types of optimization you can't in a normal programming
language.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
More information about the Info-vax
mailing list