[Info-vax] decrementing & for loops in C

[vaxinf at chemie.uni-konstanz.de]

On 13 Jan., 01:02, johnwalla... at yahoo.co.uk wrote:
> 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.

Ada?

I'm sure you know the famous bug of the Ariane 5 control software:

http://en.wikipedia.org/wiki/Ariane_5_Flight_501

In my opinion there is no computer language that hinders a programmer
to produce wrong code.

eberhard