Re: OT: Programming Languages

On Fri, 01 Nov 2024 16:54:44 -0700, john larkin <jl@glen--canyon.com>
wrote:

On Fri, 1 Nov 2024 16:03:00 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
>

On 11/1/2024 3:50 PM, Nick Hayward wrote:

What about C++?

>
C++ is an order of magnitude more complex than C.  Even a
casual C programmer can imagine what his code will look
like after compilation.  I.e., can imagine exactly what the
CPU will be doing (ignoring the fact that the compiler will
often out-think the coder in terms of time/space efficiency).

I think that the complexity ratio between C and C++ well exceeds ten.

Have kernel debugger, will travel.  Well, now days it's had kernel
debugger, would travel.

We want to time the execution of a control algorithm. One way to time
it is to run it in a loop maybe 100K times and measure that with a
stopwatch. But a very smart compiler might run it once, notice that
nothing has changed, and skip the reruns.

Yeah.  In C, one can declare something to be "volatile", which tells
the optimizer that it is not alone, that something invisible may
change it. 

There were some compilers this treated volatile as friendly advice,
versus royal command, but those compilers were soon stamped out.  But
they do pop up from time to time in new products.

It took a while for compilers to handle mutual-exclusion
functions/commands correctly - in most architectures, one must block
interrupts for this to work correctly.  It's a long story, and is a
good reason to work in assembly for that.

It's best to bang a port pin and measure it with an oscilloscope.

Yes.

We've had FPGA compilers do that sort of thing, optimize out
intentional delays. One fix is to XOR signals with a level from a pin
that *we* know is always low.

One would assume that there is a FPGA equivalent to volatile.

Joe Gwinn