[Info-vax] decrementing & for loops in C

[johnwallace4 at yahoo.co.uk]

On Jan 12, 11:15 pm, Johnny Billquist <b... at update.uu.se> wrote:
> nobody skrev:
>
>
>
> > Johnny Billquist wrote:
> >> nobody skrev:
>
> >>> vax... 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: b... at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol

The compiler knows the types from the source, and there are ways of
getting the type info into the object file, so in principle such type
checking is possible. At least one perhaps slightly obscure
implementation did do such runtime type checks, using (iirc) debug
info as well as the usual function call stuff. This was back around
1985 so my memory is a bit limited. Very few people knew much about
it, as it was well hidden in the innards of a then-advanced runtime
environment for automation applications, part of a system known at the
time as the Gould Cell Controller (that's Gould Modicon, of Modbus
fame, with a software development team mostly in greater Boston
(Andover) and Munich (Softing AG) but a few of us in the UK). As well
as the runtime type checking, it also allowed "replacement in place"
of functions/modules >>while the application was actually running<<, a
bit like today's "edit and continue" in a well known IDE, except a
couple of decades earlier and done non-disruptively. This wasn't aimed
at general purpose C programming, the real user input was primarily in
"ladder logic" or other PLC-programming languages (eg Grafcet), which
were translated into C before being compiled and loaded on the fly.
The dynamic-linking and type-checking loader was my bit.

Wrt Ada: in general, properly written Ada functions don't have
unpredictable side effects so the compiler can generally be confident
that (eg) within a given module, global variables won't be modified
behind its back unless you say so. But if you want to write assembler-
style in Ada, you can, and given the appropriate qualifiers and
attributes you can get it just as wrong as in C, though in theory
it'll be more obvious in Ada.

Wrt VHDL: there are ways and means of getting from C-like languages to
VHDL. See (for example) the Oxford University spinoff Handel C.