P4's "PAUSE" instruction 
Author Message
 P4's "PAUSE" instruction

All,

I have been doing some detailed research lately and came across an
interesting opcode sequence accompanied by an interesting suggestion
from Intel's optimization guide.

Intel introduced a new PAUSE instruction with the P4 (opcode 0f390h,
IA-32 Volume 2, page 586).  It conveys information to the processor at
runtime that it's currently executing a "spin-wait loop" or SWL
(sample code shown below).  The P4 architecture can take a huge
performance hit when exiting a SWL due to the nature of its NetBurst
Architecture design (page 270 of Intel manual # 248966).  The PAUSE
instruction can be added to tell the processor that it's in a
spin-wait loop.  Use of this new instruction often removes any penalty
the P4 might otherwise incur, and can equate to zero added clocks for
SWL processing.

Also, if you look at the opcode sequence, it's 0f3h (REP prefix) and
090h (NOP instruction).  Together, they mean nothing to any x86
processor and will be interpreted, simply, as a NOP with an extra
(ignored) prefix byte.  But, look closely at what Intel has done here.
They've come up with an opcode sequence that allows their own P4
processor to bypass an architectural shortcoming, while simultaneously
providing a way to make competing processors incur an extra delay for
the processing of the "REP NOP" instruction.  Intel's P4 & Xeon
optimization guide recommends that the PAUSE instruction be added to
*ALL* spin-wait loops (page 268 of Intel manual # 248966).  If done,
it will have no effect on processed data, but it will have an affect
on processing time.

What do you think about that?  To me, it seems a somewhat underhanded
way to give their own processor a leg-up because it simultaneously
causes competing processors to run slower.  The only redeeming aspect
I see is the state of the processor at the time it's executed.  The
processor will already be busy in the SWL, essentially doing nothing
until some value changes.  So, an extra clock cycle here or there
won't be a big deal.  Nevertheless, I found that instruction encoding
and optimization suggestion quite an interesting pair.

-----
Example of spin-wait loop code:
top:
    cmp eax,10
    jnz try_again
    ; do whatever code here when eax is 10

try_again:
    ; do something which reads a new value into eax
    jmp top
-----

- Rick C. Hodgin



Sun, 17 Oct 2004 18:56:00 GMT  
 P4's "PAUSE" instruction


Quote:
> Intel introduced a new PAUSE instruction with the P4 (opcode 0f390h,
> spin-wait loop.  Use of this new instruction often removes any penalty
> the P4 might otherwise incur, and can equate to zero added clocks for
> SWL processing.

Huh? The instruction will not reduce waiting time!!!

Quote:
> Also, if you look at the opcode sequence, it's 0f3h (REP prefix) and
> 090h (NOP instruction).  Together, they mean nothing to any x86
> processor and will be interpreted, simply, as a NOP with an extra
> (ignored) prefix byte.  But, look closely at what Intel has done here.
> They've come up with an opcode sequence that allows their own P4
> processor to bypass an architectural shortcoming, while simultaneously
> providing a way to make competing processors incur an extra delay for
> the processing of the "REP NOP" instruction.  Intel's P4 & Xeon
> optimization guide recommends that the PAUSE instruction be added to
> *ALL* spin-wait loops (page 268 of Intel manual # 248966).  If done,
> it will have no effect on processed data, but it will have an affect
> on processing time.

> What do you think about that?  To me, it seems a somewhat underhanded

I think that you are wrong with your assumptions.

First, the instruction is suposed to be used when the processor is waiting
for something (loosing cycles). NOP is executed in less than one cycle (2..3
NOPs per cycle), REP NOP would be executed by non-Intel CPU in no more than
2 cycles (maybe in one, maybe 2..3 per cycle), PAUSE execution time is much
higher. So if the task is to loose cycles, any of these solutions will work,
the main advantage of PAUSE being not consuming the bus bandwidth.

Quote:
> Example of spin-wait loop code:

My students would score "F for this example... 50% of jumps can be removed
from the code below :)
Quote:
> top:
>     cmp eax,10
>     jnz try_again
>     ; do whatever code here when eax is 10

> try_again:
>     ; do something which reads a new value into eax
>     jmp top



Sun, 17 Oct 2004 20:55:57 GMT  
 P4's "PAUSE" instruction

Quote:
> > spin-wait loop.  Use of this new instruction often removes any penalty
> > the P4 might otherwise incur, and can equate to zero added clocks for
> > SWL processing.

> Huh? The instruction will not reduce waiting time!!!

According to the optimization guide, the PAUSE instruction can incur as
little as a 0 clock penalty for executing it.  But, it has the effect of
setting up internal conditions within the P4's NetBurst architecture which
removes a "memory order violation" which occurs when the spin-wait loop is
exited.

If you're unhappy with my explanation, please refer to the pages I indicated
in the optimization guide and read for yourself.

Quote:
> First, the instruction is suposed to be used when the processor is waiting
> for something (loosing cycles).

Yes.  As I indicated, that seems to be the only redeeming feature of its
implementation.

Quote:
> NOP is executed in less than one cycle (2..3
> NOPs per cycle), REP NOP would be executed by non-Intel CPU in no more
than
> 2 cycles (maybe in one, maybe 2..3 per cycle), PAUSE execution time is
much
> higher.

According to the optimization manual, there are implementations in which the
execution time is 0 clocks.

Quote:
> So if the task is to loose cycles, any of these solutions will work,
> the main advantage of PAUSE being not consuming the bus bandwidth.

The purpose isn't to lose cycles.  The very nature of the code will be that
you are losing cycles in a loop.  The purpose of the PAUSE instruction is to
remove a "memory order violation" that the processor will otherwise
encounter when exiting the loop.  It says that clearly in the optimization
manual, and kind of hints at it in the IA-32 Vol 2 manual.

Quote:
> > Example of spin-wait loop code:

> My students would score "F for this example... 50% of jumps can be removed
> from the code below :)

The example I gave is a simplistic one.  What would be more likely is a case
where eax is compared to 10, then to 12, then to 15, then to other values,
then it loads in the new value and loops back to the top.

BTW, what is an ["F]?

- Rick C. Hodgin



Mon, 18 Oct 2004 00:55:53 GMT  
 P4's "PAUSE" instruction
I tried to send you the following answer, but my adress was rejected with
the comment "we don't accept spam". Nice shot, considering the fact this is
my university address and we are quite secure when it comes to email
forwarding.
----------------------------------------------------------------------------
-----------------------------
Right, but still I can see no real advantage for Intel. Pause looks simply
as a long NOP. This long NOP solves some sync problems in very long pipeline
architecture, like P4. SHould have no real advantage (or marginal one) on
shorter pipelines like K7. And then I am almost sure that the new AMD CPUs
will have PAUSE instruction.

Ok, maybe I am missing something important, but from the basic Intel docs I
can't see anything special about PAUSE.

Gregory

Quote:
----- Original Message ----- > See page 268 of Intel's P4 and Xeon

optimiation manual.  The following
> excerpt is what I'm basing my conclusions on:
> "The frequency and duration that a thread needs to synchronize with other
> threads

> BTW, what is an ["F]?

One grade less than "E". In fact, we have numbers, not letters here, so the
lowest mark is 0, then 2..5 (there is no 1).



Mon, 18 Oct 2004 04:56:00 GMT  
 P4's "PAUSE" instruction

[...]
| Intel introduced a new PAUSE instruction with the P4 (opcode 0f390h,
| IA-32 Volume 2, page 586).

Interesting page number :)

[..]
| What do you think about that?  To me, it seems a somewhat underhanded
| way to give their own processor a leg-up because it simultaneously
| causes competing processors to run slower.

The only extra time on non-PAUSE processors would be decoding one extra F3h
prefix and only the last time the CPU decodes it since the other times it's
just waiting in the loop and it would wait equally long if the F3h weren't
there.

I'd guess that almost all non-Intel CPUs sold now probably support PAUSE.
PAUSE is, what, 2 years old by now?

And why stop with PAUSE? Most software probably is Intel-CPU optimized. They
run faster on Intel CPUs than on competing processors. Compared to that,
PAUSE is nothing!



Mon, 18 Oct 2004 05:56:06 GMT  
 P4's "PAUSE" instruction
Rick,

I really doubt that the performance penalty upon exiting the loop is all
that serious.  But be that as it may, PAUSE's real meaning in life is to
save power.  Lots of programs use JMP $ (JMP to itself) to sit around
and wait for an interrupt.  In the Pentium 4, this dissipates a hell of
a lot of heat because it overexercises a small number of transistors.
What programmers should to is:

mov [MyInterruptHappened], FALSE
sti

Halt:
hlt (sits here until an interrupt happens)
cmp [MyInterruptHappened], TRUE
jnz Halt

(Continue processing...)

I've gone as far as to attach a power meter to an Athlon system doing
this, and I can observe a drop of about 4W compared to "JMP $".  (With
JMP $, the interrupt modifies the IRET address, which of course only
works if it's not a nested interrupt, so the technique is bad.)

Intel claims in their instruction manual that PAUSE is great to insert
in a spin loop (either JMP $ or CMP+JNZ, I suppose).  This is true,
because it cuts power consumption.  HLT also cuts power consumption.

Now, here's what I think is REALLY going on:  PAUSE has effectively
nothing to do with performance.  Intel wants you to use PAUSE because it
will run very power-efficiently on their Pentium 4, whereas on other
processors it will be treated as NOP (instead of a delay), and dissipate
much more power.  Since most OSes are in spin loops all day long, the
Pentium 4 will show better battery life savings than, say, a Transmeta
product.  My advice:  Use HLT because it levels the playing field for
all CPUs.

Lawrence

Quote:

> All,

> I have been doing some detailed research lately and came across an
> interesting opcode sequence accompanied by an interesting suggestion
> from Intel's optimization guide.

> Intel introduced a new PAUSE instruction with the P4 (opcode 0f390h,
> IA-32 Volume 2, page 586).  It conveys information to the processor at
> runtime that it's currently executing a "spin-wait loop" or SWL
> (sample code shown below).  The P4 architecture can take a huge
> performance hit when exiting a SWL due to the nature of its NetBurst
> Architecture design (page 270 of Intel manual # 248966).  The PAUSE
> instruction can be added to tell the processor that it's in a
> spin-wait loop.  Use of this new instruction often removes any penalty
> the P4 might otherwise incur, and can equate to zero added clocks for
> SWL processing.

> Also, if you look at the opcode sequence, it's 0f3h (REP prefix) and
> 090h (NOP instruction).  Together, they mean nothing to any x86
> processor and will be interpreted, simply, as a NOP with an extra
> (ignored) prefix byte.  But, look closely at what Intel has done here.
> They've come up with an opcode sequence that allows their own P4
> processor to bypass an architectural shortcoming, while simultaneously
> providing a way to make competing processors incur an extra delay for
> the processing of the "REP NOP" instruction.  Intel's P4 & Xeon
> optimization guide recommends that the PAUSE instruction be added to
> *ALL* spin-wait loops (page 268 of Intel manual # 248966).  If done,
> it will have no effect on processed data, but it will have an affect
> on processing time.

> What do you think about that?  To me, it seems a somewhat underhanded
> way to give their own processor a leg-up because it simultaneously
> causes competing processors to run slower.  The only redeeming aspect
> I see is the state of the processor at the time it's executed.  The
> processor will already be busy in the SWL, essentially doing nothing
> until some value changes.  So, an extra clock cycle here or there
> won't be a big deal.  Nevertheless, I found that instruction encoding
> and optimization suggestion quite an interesting pair.

> -----
> Example of spin-wait loop code:
> top:
>     cmp eax,10
>     jnz try_again
>     ; do whatever code here when eax is 10

> try_again:
>     ; do something which reads a new value into eax
>     jmp top
> -----

> - Rick C. Hodgin



Mon, 18 Oct 2004 11:55:56 GMT  
 P4's "PAUSE" instruction

Quote:

> The only extra time on non-PAUSE processors would be decoding one extra F3h
> prefix and only the last time the CPU decodes it since the other times it's
> just waiting in the loop and it would wait equally long if the F3h weren't
> there.

One interesting issue is this: What happens on a cpu which actually
tries to execute a REP NOP combination?

Would it destroy (e)cx, by decrementing it each time, or is this already
covered by a general 'Only these instructions can take a REPxx prefix,
on other instructions a REP prefix is ignored' rule?

Terje

--

"almost all programming can be viewed as an exercise in caching"



Mon, 18 Oct 2004 15:55:54 GMT  
 P4's "PAUSE" instruction
Quote:
----- Original Message -----

Newsgroups: comp.lang.asm.x86
Sent: Wednesday, May 01, 2002 20:55
Subject: Re: P4's "PAUSE" instruction

> BTW, what is an ["F]?

Grade. The *f*ailing one. Ever got one at school? :)

Good Luck
Alexei A. Frounze
http://alexfru.narod.ru
http://members.tripod.com/protected_mode/



Mon, 18 Oct 2004 15:56:00 GMT  
 P4's "PAUSE" instruction

| One interesting issue is this: What happens on a cpu which actually
| tries to execute a REP NOP combination?
|
| Would it destroy (e)cx, by decrementing it each time, or is this already
| covered by a general 'Only these instructions can take a REPxx prefix,
| on other instructions a REP prefix is ignored' rule?

I remember reading someplace that redundant prefixes are ignored in the
first opcode table, but I couldn't find the text. Perhaps I was dreaming...



Mon, 18 Oct 2004 18:56:12 GMT  
 P4's "PAUSE" instruction

Quote:
> One interesting issue is this: What happens on a cpu which actually
> tries to execute a REP NOP combination?

Intel's P4 & Xeon Optimization manual states that the REP NOP is executed as
a NOP on "all known x86 implementations".  It's on page 66:

"Spin-Wait and Idle Loops

The Pentium 4 processor introduces a new pause instruction which is
architecturally a nop on all known IA-32 implementations. To the Pentium 4
processor, it acts as a hint that the code sequence is a spin-wait loop.
Without a pause instruction in these loops, the Pentium 4 processor may
suffer a severe penalty when exiting the loop because the processor detects
a possible memory order violation. Inserting the pause instruction
significantly reduces the likelihood of a memory order violation, improving
performance. The Pentium 4 processor can execute a spin-wait loop using
fewer resources and little power."

Quote:
> Would it destroy (e)cx, by decrementing it each time, or is this already
> covered by a general 'Only these instructions can take a REPxx prefix,
> on other instructions a REP prefix is ignored' rule?

I was under the impression that all x86 implementations ignore extra or
redundant prefixes (such as sticking in two ES: overrides) up until the
point where they signal #GP because the instruction encoding is > 15 bytes.

- Rick C. Hodgin



Mon, 18 Oct 2004 21:55:58 GMT  
 P4's "PAUSE" instruction

Quote:
> Rick,

> I really doubt that the performance penalty upon exiting the loop is all
> that serious.

Intel's P4 & Xeon Optimization manual states that the PPro, PII and PIII all
have similar penalties.  However, due to the nature of the NetBurst
architecture the penalty on P4 is 25x greater than on previous Intel cores.
It's on page 268:

"On detection of a write by another worker thread to any load that is in
progress, the processor must guarantee that no violations of memory order
can occur. To maintain the proper order of outstanding memory operations,
the processor suffers a severe penalty, affecting both threads. This
performance penalty also occurs on the Pentium? Pro processor, the Pentium
II processor and the Pentium III processor. However, the penalty in these
processors is small compared with the penalty on the Pentium 4 processor and
XeonT processor where the performance penalty of exiting this loop is about
25 times more severe. On a processor with Hyper-Threading technology,
spin-wait loops can consume a significant portion of the execution bandwidth
of the processor. One logical processor executing a spin-wait loop could
severely impact the performance of the other logical processor doing useful
work."

Quote:
> But be that as it may, PAUSE's real meaning in life is to
> save power.  Lots of programs use JMP $ (JMP to itself) to sit around
> and wait for an interrupt.  In the Pentium 4, this dissipates a hell of
> a lot of heat because it overexercises a small number of transistors.
> What programmers should to is:

> mov [MyInterruptHappened], FALSE
> sti

> Halt:
> hlt (sits here until an interrupt happens)
> cmp [MyInterruptHappened], TRUE
> jnz Halt
> (Continue processing...)

I agree completely.  In fact, before reading further down in your post to
the code snippet part I responded with that statement. :)  I have
implemented this on several platforms and have seen almost unbelievable
decreases in system temperature.  Even an old Pentium 233 MMX system that
typically runs at 33C in spin-wait loops dropped down to 21C when the HLT
instruction was added.  Since that time, I've used it almost exclusively
(when possible).

Quote:
> I've gone as far as to attach a power meter to an Athlon system doing
> this, and I can observe a drop of about 4W compared to "JMP $".  (With
> JMP $, the interrupt modifies the IRET address, which of course only
> works if it's not a nested interrupt, so the technique is bad.)

That's interesting.  I would've thought it would be more.  What kind of
interrupts are you running at the time?

Quote:
> Now, here's what I think is REALLY going on:  PAUSE has effectively
> nothing to do with performance.  Intel wants you to use PAUSE because it
> will run very power-efficiently on their Pentium 4, whereas on other
> processors it will be treated as NOP (instead of a delay), and dissipate
> much more power.  Since most OSes are in spin loops all day long, the
> Pentium 4 will show better battery life savings than, say, a Transmeta
> product.

That's an interesting statement.  It certainly makes sense and, to me, seems
even worse than the timing issue I brought up in my original post.

Quote:
> My advice:  Use HLT because it levels the playing field for
> all CPUs.

Agreed.

- Rick C. Hodgin



Mon, 18 Oct 2004 21:56:07 GMT  
 P4's "PAUSE" instruction

:   I have
:  implemented this on several platforms and have seen almost unbelievable
:  decreases in system temperature.  Even an old Pentium 233 MMX system that
:  typically runs at 33C in spin-wait loops dropped down to 21C when the HLT
:  instruction was added.  Since that time, I've used it almost exclusively
:  (when possible).

Ever since the original Pentium (and perhaps 486slc), Intel
AMD and Cyrix implemented _major_ powersavings when the HLT
instruction was executing.  Go look at some datasheets, 5-10%
of max power draw is typical.

This isn't entirely problem free.  There's an engineering problem
with the high current slew.  You also have to wait for an interrupt
before the system will do anything.  This isn't a problem on
systems that are essentially single tasking, but wastes cycles
under multitasking iff there are other jobs to run.

Modern multitasking OSes (IBM OS/2, Linux, MS-WindowsNT, *BSD) have
implemented HLT in their idle threads.  Older OSes like MS-DOS,
MS-Window95 do not have HLT at idle, but you can easily write
software that comes close to this functionality even though HLT is
a priviliged, Ring0 instruction.

-- Robert  author `cpuburn` http://users.ev1.net/~redelm



Tue, 19 Oct 2004 01:55:57 GMT  
 P4's "PAUSE" instruction
Rick,

Quote:
> "On detection of a write by another worker thread to any load that is in
> progress, the processor must guarantee that no violations of memory order
> can occur. To maintain the proper order of outstanding memory operations,
> the processor suffers a severe penalty, affecting both threads. This
> performance penalty also occurs on the Pentium? Pro processor, the Pentium
> II processor and the Pentium III processor. However, the penalty in these
> processors is small compared with the penalty on the Pentium 4 processor and
> XeonT processor where the performance penalty of exiting this loop is about
> 25 times more severe. On a processor with Hyper-Threading technology,
> spin-wait loops can consume a significant portion of the execution bandwidth
> of the processor. One logical processor executing a spin-wait loop could
> severely impact the performance of the other logical processor doing useful
> work."

Ah, interesting.  I didn't think of the ramifications for
Hyperthreading.  I learned something today.

Quote:

> I agree completely.  In fact, before reading further down in your post to
> the code snippet part I responded with that statement. :)  I have
> implemented this on several platforms and have seen almost unbelievable
> decreases in system temperature.  Even an old Pentium 233 MMX system that
> typically runs at 33C in spin-wait loops dropped down to 21C when the HLT
> instruction was added.  Since that time, I've used it almost exclusively
> (when possible).

Again interesting.  I'm surprised that the temperature drops so much.

Quote:

>>I've gone as far as to attach a power meter to an Athlon system doing
>>this, and I can observe a drop of about 4W compared to "JMP $".  (With
>>JMP $, the interrupt modifies the IRET address, which of course only
>>works if it's not a nested interrupt, so the technique is bad.)

> That's interesting.  I would've thought it would be more.  What kind of
> interrupts are you running at the time?

Just the clock interrupt.  Athlon is not optimized to conserve power.
Athlon XP is supposedly better.

Lawrence



Tue, 19 Oct 2004 03:56:14 GMT  
 P4's "PAUSE" instruction
Hello {*filter*}folk!

On Thu, 2 May 2002 10:56:12 +0000 (UTC), Henrik spake thus:

Quote:

>| One interesting issue is this: What happens on a cpu which actually
>| tries to execute a REP NOP combination?
>|
>| Would it destroy (e)cx, by decrementing it each time, or is this already
>| covered by a general 'Only these instructions can take a REPxx prefix,
>| on other instructions a REP prefix is ignored' rule?

>I remember reading someplace that redundant prefixes are ignored in the
>first opcode table, but I couldn't find the text. Perhaps I was dreaming...

Prior to the P4, the Intel docs say (about REP):

        The behavior of the REP prefix is undefined when used with
         non-string instructions.

This is in the description of REP, up to the PIII docs (24319102.PDF).
It would be my guess that when they implemented the PAUSE instruction,
they knew that no previous processor did anything with REP in this
instance, and as such that it wouldn't break code originally written
for earlier processors. Again, I'm only guessing, but I would also
suggest that decoding the REP prefix on an earlier processor would not
affect the time to execute the instruction when the prefix is ignored,
only when it has to be executed.

--
Debs

----
You have the right to remain silent. Anything you say will be misquoted and used against you.



Wed, 20 Oct 2004 22:56:00 GMT  
 P4's "PAUSE" instruction

Quote:
> >I remember reading someplace that redundant prefixes are ignored in the
> >first opcode table, but I couldn't find the text. Perhaps I was
dreaming...

> Prior to the P4, the Intel docs say (about REP):

> The behavior of the REP prefix is undefined when used with
> non-string instructions.

That seems pretty vague.  How could they have included it in the new PAUSE
encoding if it is "undefined" with non-string instructions?  I would think
it would have to be clearly defined for them to implement it.  Granted the
REP NOP prefix probably isn't used in any other applications prior to P4.
But, it might be.  To ensure 100% backward compatibility it would seem that
it would have to be based on solid, recognizable results.

For the record, I've tried the test code below on the following:

PIII Xeon:  REP NOP takes ~1 clock, NOP takes ~1 clock
VIA C3:  REP NOP takes ~2 clocks, NOP takes ~1 clock
P4:  REP NOP takes ~21 clocks, NOP takes ~1 clock

On all processors, the (E)IP register moves to the opcode sequence immediate
after "REP NOP".  No registers or flags are affected (save (E)IP).  If
anyone else wants to try it, here's the MASM 6.11d code I used:

--------
; test_nop.asm

TITLE test_nop
    .DOSSEG
    .MODEL tiny
    .386
    .STACK 100h
    .CODE
    .STARTUP
test_repnop EQU 1       ; Define if testing REP NOP, comment-out otherwise
;test_nop    EQU 1       ; Define if testing NOP only, comment-out otherwise

    db 0fh
    db 031h
ENDM

    db  0f3h
    db  090h
ENDM

    mov     ecx,test_count
    finit

; Top of average loop
; while (ecx > 0) {
  next_test:
    push    ecx
    mov     ecx,0fffffffh    ; Number of iterations for each test, should be
a large number to reduce the significance of the overhead present in all the
extras assembly instructions used for maintaining counts
; Get_Start_Count()

    mov     dword ptr val1[0],eax
    mov     dword ptr val1[4],edx

; while (ecx > 0) {
  instr_loop:
IFDEF test_repnop

ENDIF
IFDEF test_nop
    nop
ENDIF
    db 067h         ; force a loop on ECX rather than CX (remove if running
in pmode)
    loop instr_loop
; }

; Get_End_Count()

    mov     dword ptr val2[0],eax
    mov     dword ptr val2[4],edx

; cum_val += val2 - val1 == cum_val += end_count - start_count
    fild    val1
    fild    val2
    fsubrp  st(1),st(0)
    fild    cum_val
    faddp   st(1),st(0)
    fistp   cum_val

    pop     ecx
    loop    next_test
; }
; End of average-loop

; avg_result = cum_val / test_count
    fild    cum_val
    fidiv   test_count
    fistp   avg_result
    mov     eax,dword ptr avg_result[0]
    mov     edx,dword ptr avg_result[4]

  ; Now, trap back to de{*filter*} for display in EDX:EAX register pair (usually
count will be in EAX only, on P4 it occupied the first 2 bits of EDX)
    int 3

val1            dq 0            ; First RDTSC value
val2            dq 0            ; Second RDTSC value
cum_val         dq 0            ; Cumulative value (increased for each test)
avg_result      dq 0            ; Final averaged result

test_count      dd 10

END

--------

- Rick C. Hodgin



Thu, 21 Oct 2004 02:40:36 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Set a pause when variable="x"??

2. how to make a "pause"

3. '"""' and linefeed characters

4. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

5. Availability of "N3" instructions

6. "0xC0000096: Privileged instruction"

7. "out" instruction

8. "OUT" Instruction

9. Pentium III "katmai" instructions

10. MASM instruction "s" bit question

11. Instruction like "if"

12. BEGIN{want[]={"s1o", "s2o", "s2q", "s3q"}

 

 
Powered by phpBB® Forum Software