[Info-vax] decrementing & for loops in C

[Johnny Billquist]

johnwallace4 at yahoo.co.uk skrev:
> 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.

This isn't about type checking. Type checking won't get you anywhere.
Type checking can see that you are doing function calls with the correct type of 
parameters. Type checking don't say anything about what the function actually do 
with the parameters.

> 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.

You have Erlang, which have exactly those properties, and which are in current 
use today. Still don't help, and still can't optimize the order of function 
calls with regards to ordering.

> 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.

Huh? That's nonsense. Ada functions definitely have side effects. It's an 
imperative programming language.
Assigning a value to a variable have the side effect of that variable being 
changed. Do you know what "side effects" mean?
If you call two different functions in Ada, you have no idea what either of them 
will do before returning. They could both, in turn, call an entry point in the 
same task, which would mean that the order of the calls were very important. And 
there is no way of describing this in the spec, and no way for the compiler to 
know that this would be done, since it isn't even in the same body.

Can you please tell me how you tell that a function will modify some global 
state in Ada (and feel free to be technical here, I've programmed Ada for a few 
years, so I feel pretty confident at looking at code)?

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

Yes, as long as you place some restrictions on what you allow in the C code.

	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