«

On Jan 4, 4:30*pm, Edward Rutherford
<edward.p.rutherfor...@REMOVETHIS.gmail.com> wrote:
> Hello
>
> I am trying to write code that includes a certain number of NOPs in the
> generated machine code, I would like to do it portably so without using
> inline asm.
>
> On lccwin, even without optimisations, no NOPs are generated.

Doesn't happen with gcc, either. For my part, I would not expect a
null statement to result in a NOP (as opposed to no code at all).

I guess my question is, why do you need the NOPs to be generated? Is
it a timing issue? If so, there may be a better way to accomplish it,
if not a more portable way (frankly, if we're talking about generating
specific opcodes, we've thrown portability out the window already).

On 1/5/2011 7:55 AM, Kenneth Brody wrote:
> On 1/4/2011 8:57 PM, wrote:
> [...]
>> In the same vein, both Intel and IBM have defined explicit undefined
>> instructions. Intel even gave it a mnemonic.
>
> Well, by giving it a mnemonic, they've "reserved" that opcode more
> strongly than simply saying "don't use it".
>
> Unlike, as I recall, when the 8086 first came out, one of the interrupt
> vectors was marked by Intel as "reserved" or "unused". IBM, in their
> infinite wisdom, decided to use that interrupt as their "print screen"
> handler. Along comes the 80286, and Intel now uses that interrupt for
> some hardware trap, leaving BIOS writers with the task of deciding "was
> this a hardware trap, or a software-generated interrupt meant to 'print
> screen'?"
>

and then in the 386 and newer most of the interrupts used by the BIOS
and IRQ controllers happen to fall into the region where the CPU may
validly generate PMode exceptions (hence meaning the need to remap the
IRQ controllers for a PMode OS, and mapping them back if one for some
reason feels a need to go back into real-mode and access the BIOS, well
that or probably have remap entries in the real-mode IVT which redirect
calls to the appropriate BIOS handlers...).

BGB <> writes:
[...]
> 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?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 01/ 6/11 10:44 AM, Keith Thompson wrote:
> BGB<> writes:
> [...]
>> 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.

--
Ian Collins

Ben Pfaff wrote:
> "BartC"<> writes:
>> It would be difficult I think to find a C expression that doesn't
>> access memory, sets no flags, generates a single byte of code, and
>> behaves consistently across machines; but depending on exactly why
>> these no-ops are needed, that may or may not be important.
>
> The "single byte of code" part is impossible, because some
> architectures have fixed-length instructions that are wider than
> one byte.

And there are architectures that have variable-length instructions, but
the instruction length is always a multiple of 2. (Examples I'm
familiar with: Motorola's M68k and National Semiconductor CompactRISC.)
--
Marcin Grzegorczyk

BartC <> wrote:
>
> Skip and Jump in a program listing does make it sound fun
> though..

I don't suppose there's a HOP instruction, too?
--
Larry Jones

The problem with the future is that it keeps turning into the present.
-- Hobbes

On Jan 5, 4:44*pm, Keith Thompson <ks...@mib.org> wrote:
> BGB <cr88...@hotmail.com> writes:
>
> [...]
>
> > 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?

I actually use NOP delays primarily in writing serial protocols that I
have to bit-bang myself. For example, if I'm running a
microcontroller at 32 MHz, I sometimes need to insert small NOP delays
to create a electrical signal that is slow enough to be detected by
the peripheral (in my case a temperature sensor). If I ran the
microcontroller at a slower clock speed, I wouldn't need to insert
delays. I personally haven't used anything like this outside the
embedded domain.

\code snippet
/*
* Define the baseline for the delay according to the PIC18F2X1X/4X1X
* oscillator frequency. Each instruction requires 4 clock cycles to
* complete. The table below gives the measured time used by a NOP
* instruction 'asm( "nop" )'.
*
* Osc Freq | Delay
* -------------------
* 1 MHz | 4 ms
* -------------------
* 2 MHz | 2 us
* -------------------
* 4 MHz | 1 us
* -------------------
* 8 MHz | 500 ns
* -------------------
* 16 MHz | 250 ns
* -------------------
* 32 MHz | 125 ns
* -------------------
*/
#if defined(FOSC)
# if (FOSC == 1000000)
# define delay_4us asm( "nop" )
# elif (FOSC == 2000000)
# define delay_2us asm( "nop" )
# elif (FOSC == 4000000)
# define delay_1us asm( "nop" )
# define delay_2us delay_1us; delay_1us
# elif (FOSC == 8000000)
# define delay_500ns asm( "nop" )
# define delay_1us delay_500ns; delay_500ns
# define delay_2us delay_1us; delay_1us
# elif (FOSC == 16000000)
# define delay_250ns asm( "nop" )1
# define delay_500ns delay_250ns; delay_250ns
# define delay_1us delay_500ns; delay_500ns
# define delay_2us delay_1us; delay_1us
# elif (FOSC == 32000000)
# define delay_125ns asm( "nop" )
# define delay_250ns delay_125ns; delay_125ns
# define delay_500ns delay_250ns; delay_250ns
# define delay_1us delay_500ns; delay_500ns
# define delay_2us delay_1us; delay_1us
# else
# error FOSC is not a valid clock speed
# endif
#else
# error delay.h requires FOSC to be defined
#endif
\endcode

\code snippet2
void sensibus_transmit_start( uint8_t sensor_id )
{
/* ______ ______
* DATA: |_________|
* ___ ___
* CLK : ____| |_____| |____
*/

SENSIBUS_DATA_OUT( sensor_id );
SENSIBUS_CLK = 0;
C_SET_BIT( SHT1X_SENSOR_PORT, sensor_id );
delay_1us;
SENSIBUS_CLK = 1;
delay_1us;
C_CLEAR_BIT( SHT1X_SENSOR_PORT, sensor_id );
delay_1us;
SENSIBUS_CLK = 0;
delay_us( 5 );
SENSIBUS_CLK = 1;
C_SET_BIT( SHT1X_SENSOR_PORT, sensor_id );
delay_1us;
SENSIBUS_CLK = 0;
}
\endcode

If I strip out all the delays in the sensibus_transmit_start running
at 32 MHz, the temperature sensor can't keep up.

Best regards,
John D.

On 1/5/2011 2:44 PM, Keith Thompson wrote:
> BGB<> writes:
> [...]
>> 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?
>

mostly it would be to force delay loops to not be optimized away.

often, a C compiler will see something like:
"for(i=0; i<1000000; i++);"
and in being so clever will emit something akin to "i=1000000;" instead...


similarly:
"for(i=0; i<1000000; i++)myNop();"
will do likewise, if the compiler just happens to notice that "myNop()"
doesn't actually change any external state.

so, something like a "__nop" keyword would mostly serve as a hack to
prevent the compiler from simply optimizing away a function/loop/...
even if it sees it could otherwise do so.

granted, most real compilers can be tricked into not optimizing away a
loop with measures a little less drastic...


for most code, this is optimization perfectly reasonable, but it is not
as good when one is doing some operation a large number of times in a
loop mostly just to measure the thing (needed for micro-benchmarks,
....), where if the loop simply completes instantly it is of little use
WRT measuring its timings.

for example, one might want to time the loop by itself, and then time
the loop doing some simple task, ...

but, for other reasons, one might not want to disable compiler
optimization outright (say, they want to time an operation as it is with
the compilers' optimizations enabled, ...).

or such...

On 1/5/2011 4:26 PM, John Bode wrote:
> On Jan 4, 4:30 pm, Edward Rutherford
> <edward.p.rutherfor...@REMOVETHIS.gmail.com> wrote:
>> Hello
>>
>> I am trying to write code that includes a certain number of NOPs in the
>> generated machine code, I would like to do it portably so without using
>> inline asm.
>>
>> On lccwin, even without optimisations, no NOPs are generated.
>
> Doesn't happen with gcc, either. For my part, I would not expect a
> null statement to result in a NOP (as opposed to no code at all).
>
> I guess my question is, why do you need the NOPs to be generated? Is
> it a timing issue? If so, there may be a better way to accomplish it,
> if not a more portable way (frankly, if we're talking about generating
> specific opcodes, we've thrown portability out the window already).

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?

--
Eric Sosman
lid

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?)

But let me participate anyway! I'll inject some useless comments
from the distant past. On the CDC 6x00 machines, instruction
words often had to be padded out with NOP's. Was I the only
one perverse enough to note that on the 6400 one half-word
SB0 B0+0 instruction was faster than *two* quarter-word NOP's?

On Jan 5, 4:29*pm, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
wrote:
> "DIAG" actually. *A problem for the assembler is that Diagnose doesn't
> even have a defined format.

I had an unusual job for a while that meant I was coding and
even inventing Diagnose instructions for several 370 models.
IIRC, the only Diagnoses typical for O.S.'es were to specify
error-recording modes, but there were other nifty possibilities.
But I sometimes found it more convenient to associate new
diagnostic firmware functions with unused opcodes. Great fun
when maintenance personnel forgot to re-Impl before returning
machine to customer. ::whack::

James Dow Allen