lccwin fails to generate NOPs

[Seebs]

Am I the only one pretty sure that OP (and some other recent OP's
with foolish questions) are trolls? (Does Edward Rutherford
even have any prior Usenet history?)

No. I got flamed by Tim Rentsch for commenting on one of them,
though.

-s

 

[glen herrmannsfeldt]

No. I got flamed by Tim Rentsch for commenting on one of them,
though.

TXR is here?

I haven't heard from him in years. He was the one who first
taught me about PDP-10 Assembly. I had previously done S/360
and S/370 assembly code, but DEC machines were new to me at
the time.

-- glen

 

[Chris H]

Poor man's delay? Sometimes hardware devices require a minimum delay
between being written and being read.

But you can't do delays with NOP's in C. You need to use either ASM or a
proper delay using interrupts or timers.

 

[Ian Collins]

[...]
a __nop keyword almost makes sense, since if-anything, it can tell the
compiler not to optimize it away... (vs the compiler doing its best to
figure out that "some function in another compilation unit accessed via
a function pointer and performing a few global variable assignments" is
in-fact no-op...).

I'm still trying to understand why this, or anything like it, would make
sense. What would be the benefit of forcing NOP instructions in the
object code generated by a C compiler?

Poor man's delay? Sometimes hardware devices require a minimum delay
between being written and being read.

But you can't do delays with NOP's in C. You need to use either ASM or a
proper delay using interrupts or timers.

See the question I was answering!

 

[Noob]

And the OP still hasn't given us a clue about *why* he needs NOP instructions.

<Waaay OT>

Perhaps the OP is playing with Linux "jump labels"

http://lwn.net/Articles/412072/

 

[BartC]

Am I the only one pretty sure that OP (and some other recent OP's
with foolish questions) are trolls?

No. Posts making unreasonable demands on 'lccwin' usually are. But one
mitigating factor was the cross-post to the lcc group.

 

[Tim Rentsch]

No. I got flamed by Tim Rentsch for commenting on one of them,
though.

This remark is misleading because the two cases are significantly
different. In the second instance, a complaint was raised primarily
because of the contents of the posting. In the first instance, a
complaint was raised based primarily on the email address and site
used to post; the contents that posting seem perfectly reasonable
(at least that was my impression and I believe others voiced the
same opinion). Maybe the authors' intentions were otherwise, but
that's how they came across. The second instance may provide some
benefit to the group, or it may not, but whether it does is at least
arguable. The first instance is IMO worse than useless, and that
was the basis for my objection. So these two cases shouldn't be
just glibly lumped together.

 

[qarnos]

     A thought: The O.P. feels that the null statement ";" should
be translated as a single no-op instruction.  Why not a hundred?
Or a hundred million?

I wonder... If an empty loop is unrolled, should there be a NOP for
every iteration?

 

[Antoine Leca]

in message


I was going to say my compiler, but I've just tried it, and no code!
(A bit of a surprise because I thought it did no useful optimisations
at all, let alone for silly, unlikely code.)

Since the C standard requires the full evaluation of constant
expressions, every compiler includes constant folding, and about all do
propagate the result of constant folding to the generated code;
likewise, the typing rules for assignment are required, and need some
analysis.

Since the tests above combine the two requirements, it may well be above
the capacities of your compiler to anticipate that these combinations
are in fact silly, without first going into the relevant analysis: it is
much easier to do that analysis, and after the simplification which
brings back i=i, to just drop the operation.


Antoine

 

[BartC]

Since the C standard requires the full evaluation of constant
expressions, every compiler includes constant folding,

I don't know about that; with cross-compilers, for example, it might not be
possible for the machine running the compiler to perform arithmetic exactly
the same way as the target machine.

and about all do
propagate the result of constant folding to the generated code;
likewise, the typing rules for assignment are required, and need some
analysis.

Since the tests above combine the two requirements, it may well be above
the capacities of your compiler to anticipate that these combinations
are in fact silly, without first going into the relevant analysis: it is
much easier to do that analysis, and after the simplification which
brings back i=i, to just drop the operation.

That's true; the 0 or 1 above might be the result of a more complex
expression that doesn't involve literals. So checking for arithmetic with 0
or 1 is not as silly as I mentioned.

 

[Marcin Grzegorczyk]

I don't know about that; with cross-compilers, for example, it might not
be possible for the machine running the compiler to perform arithmetic
exactly the same way as the target machine.

If a compiler knows how to generate code for the target platform, I
think it can know how that platform performs integer arithmetic, and
emulate that if necessary. C99 requires that even for the preprocessor,
anyway.

For floating-point constant expressions, compile-time evaluation is not
required; but if done, there is a minimum requirement about the
precision (N1256 6.6p5).

 

[glen herrmannsfeldt]

I don't know about that; with cross-compilers, for example, it might not be
possible for the machine running the compiler to perform arithmetic exactly
the same way as the target machine.

It might be that floating point constant expressions are not
required to be evaluated at compile time. In any case, it isn't
unusual to get different results at compile time than run time
for floating point expressions. I do remember at the time of the
Pentiam FDIV bug some test programs used a constant expression
that was evaluated in software emulated floating point at compile
time, and didn't test at all for the bug. More generally, you
don't always get equality for test between constant and variable
floating point expressions.

-- glen

 

[glen herrmannsfeldt]

If a compiler knows how to generate code for the target platform, I
think it can know how that platform performs integer arithmetic, and
emulate that if necessary. C99 requires that even for the preprocessor,
anyway.

Another that I learned some years ago that isn't required is string
subscripts, such as "abcd"[2], which I tried to use in a case statement.

For floating-point constant expressions, compile-time evaluation is not
required; but if done, there is a minimum requirement about the
precision (N1256 6.6p5).

-- glen

 

[Niklas Holsti]

Poor man's delay? Sometimes hardware devices require a minimum delay
between being written and being read.

That is indeed a fairly common need for C programs on small processors.

The IAR C compilers for (at least) the 8051 and AVR support an
"intrinsic" instruction written "__no_operation" that is defined to
generate a NOP instruction.

For the AVR, the IAR C compiler also has an intrinsic "__delay_cycles"
which takes as parameter a positive number and generates code, probably
using NOPs, that takes that number of cycles to execute but has no other
effect on the computation.

These effects can of course be achieved by assembly-language insertions.
Still, I think the C language could reasonably include a standard syntax
for creating a small delay of an implementation-defined and possibly
variable length.