By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,017 Members | 1,158 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,017 IT Pros & Developers. It's quick & easy.

Enforce instruction ordering?

P: n/a
Hi!

Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?

For example, say I have the following:

instruction1;
instruction2;
instruction3;

Is it possible to call some function/command to ensure that the
instructions are executed in this order?

May 24 '07 #1
Share this Question
Share on Google+
36 Replies


P: n/a
dspfun said:
Hi!

Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?

For example, say I have the following:

instruction1;
instruction2;
instruction3;

Is it possible to call some function/command to ensure that the
instructions are executed in this order?
You don't need to. The semicolons mark "sequence points", which impose
the correct ordering.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 24 '07 #2

P: n/a
Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?
For example, say I have the following:
instruction1;
instruction2;
instruction3;
Is it possible to call some function/command to ensure that the
instructions are executed in this order?

You don't need to. The semicolons mark "sequence points", which impose
the correct ordering.
Ok, great! Thanks for clear answer!

May 24 '07 #3

P: n/a
Richard Heathfield wrote:
dspfun said:
>Hi!

Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?

For example, say I have the following:

instruction1;
instruction2;
instruction3;

Is it possible to call some function/command to ensure that the
instructions are executed in this order?

You don't need to. The semicolons mark "sequence points", which impose
the correct ordering.
Well, yes and no. There are sequence points, to be sure,
but they exist only in the abstract machine. When the abstract
machine reaches a sequence point, the state of the real machine
must agree with the abstract -- but only to the extent that a
conforming C program can detect the agreement (or lack thereof).
For example, if the three lines were

x = sin(a) * cos(b) + cos(a) * sin(b);
y = cos(a) * cos(b) - sin(a) * sin(b);
z = atan2(y, x);

.... a sufficiently clever compiler might generate just five
instead of nine function calls, rather obviously changing
the apparent order of operations. We usually like it when the
compiler does this, and applaud it as "optimization."

The compiler can do such things if a conforming program
can't tell they've been done, but this may still pose problems
for non-conforming programs. If dspfun is trying to satisfy
some beyond-C-itself constraints (I/O registers? memory barriers?)
he'll need to rely on beyond-C-itself frameworks.

--
Eric Sosman
es*****@acm-dot-org.invalid
May 24 '07 #4

P: n/a
>
You don't need to. The semicolons mark "sequence points", which impose
the correct ordering.

Well, yes and no. There are sequence points, to be sure,
but they exist only in the abstract machine. When the abstract
machine reaches a sequence point, the state of the real machine
must agree with the abstract -- but only to the extent that a
conforming C program can detect the agreement (or lack thereof).
For example, if the three lines were

x = sin(a) * cos(b) + cos(a) * sin(b);
y = cos(a) * cos(b) - sin(a) * sin(b);
z = atan2(y, x);

... a sufficiently clever compiler might generate just five
instead of nine function calls, rather obviously changing
the apparent order of operations. We usually like it when the
compiler does this, and applaud it as "optimization."

The compiler can do such things if a conforming program
can't tell they've been done, but this may still pose problems
for non-conforming programs. If dspfun is trying to satisfy
some beyond-C-itself constraints (I/O registers? memory barriers?)
he'll need to rely on beyond-C-itself frameworks.
Thanks for your answer! What would be some common examples of beyond-c-
itself constraints when this wouldn't necessarily be true (i.e. that
the semicolon doesn't necessarily guarantee in order execution)? You
mentioned I/O registers and memory barriers - how can they cause
unexpected reordering?

May 24 '07 #5

P: n/a

"dspfun" <ds****@hotmail.comha scritto nel messaggio
news:11**********************@q75g2000hsh.googlegr oups.com...
You don't need to. The semicolons mark "sequence points", which impose
the correct ordering.

Well, yes and no. There are sequence points, to be sure,
but they exist only in the abstract machine. When the abstract
machine reaches a sequence point, the state of the real machine
must agree with the abstract -- but only to the extent that a
conforming C program can detect the agreement (or lack thereof).
For example, if the three lines were

x = sin(a) * cos(b) + cos(a) * sin(b);
y = cos(a) * cos(b) - sin(a) * sin(b);
z = atan2(y, x);

... a sufficiently clever compiler might generate just five
instead of nine function calls, rather obviously changing
the apparent order of operations. We usually like it when the
compiler does this, and applaud it as "optimization."

The compiler can do such things if a conforming program
can't tell they've been done, but this may still pose problems
for non-conforming programs. If dspfun is trying to satisfy
some beyond-C-itself constraints (I/O registers? memory barriers?)
he'll need to rely on beyond-C-itself frameworks.

Thanks for your answer! What would be some common examples of beyond-c-
itself constraints when this wouldn't necessarily be true (i.e. that
the semicolon doesn't necessarily guarantee in order execution)? You
mentioned I/O registers and memory barriers - how can they cause
unexpected reordering?
If you declare a variable as volatile, it will have to be accessed
whenever the abstract machine does. HTH (but, without knowing what
you are trying to do, or trying to prevent from happening, it's
hard to guess).
May 24 '07 #6

P: n/a
Richard Heathfield wrote:
>
dspfun said:
Hi!

Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?

For example, say I have the following:

instruction1;
instruction2;
instruction3;

Is it possible to call some function/command to ensure that the
instructions are executed in this order?

You don't need to. The semicolons mark "sequence points", which impose
the correct ordering.
But, if the compiler can prove there are no colliding side effects,
can't it rearrange them, or perhaps execute them in parallel?

Or does the sequence point require a strict ordering, regardless of
the possible optimization of rearranging?

For example:

extern int foo;
int a,b,c;

a = foo+2;
b = foo+1;
c = foo;

What if it would be a speed improvement to do something like this
pseudo-code:

load r1,foo
stor r1,c ' c = foo
incr r1
stor r1,b ' b = foo+1
incr r1
stor r1,a ' a = foo+2

Given the lack of "volatile", aren't the above sets of code equivalent?

Or perhaps a simple:

a = foo;
b = foo;

If the processor can execute "stor r1,a" and "stor r1,b" in parallel,
have you really "ensured that the instructions are executed in this
order"?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

May 24 '07 #7

P: n/a
dspfun wrote On 05/24/07 10:02,:
>>Eric Sosman wrote (attribution restored):

The compiler can do such things if a conforming program
can't tell they've been done, but this may still pose problems
for non-conforming programs. If dspfun is trying to satisfy
some beyond-C-itself constraints (I/O registers? memory barriers?)
he'll need to rely on beyond-C-itself frameworks.


Thanks for your answer! What would be some common examples of beyond-c-
itself constraints when this wouldn't necessarily be true (i.e. that
the semicolon doesn't necessarily guarantee in order execution)? You
mentioned I/O registers and memory barriers - how can they cause
unexpected reordering?
It's not that these things cause reordering, but
that reordering can affect the outcome in ways the
compiler may not be aware of. For example, if you
want to use a lock of some kind to coordinate access
to a shared variable in a multi-threaded program, you
might write code like

for (i = 0; i < 100; ++i) {
acquire_lock();
x[i] *= shared_flag ? shared_value1 : shared_value2;
release_lock();
...
}

.... the idea being to ensure that the shared_xxx variables
are not used by one thread while another is changing them.

Unfortunately, C-itself doesn't know anything about
threads or shared variables or locks, and doesn't realize
that the shared_xxx values should only be accessed while
the lock is held. The compiler may see an opportunity to
get rid of 99 conditionals, and reorganize the code as if
you had written

temp = shared_flag ? shared_value1 : shared_value2;
for (i = 0; i < 100; ++i) {
acquire_lock();
x[i] *= temp;
release_lock();
...
}

.... and this violates the one-at-a-time requirement. It's
not really the compiler's "fault;" it's just that the compiler
is unaware of the unstated relationship between the lock and
the shared_xxx variables. A deaf man is not at fault for
failing to perceive a difference between Beethoven and Bono.

(By the way: The `volatile' keyword is not an effective
cure for the problem here. It solves the reordering issue
but leaves others unaddressed; visit comp.programming.threads
for more information on this topic, or on this off-topic.)

Anyhow, your interest in enforcing instruction ordering
made me suspect that you might be facing a situation of this
general kind. Ordinarily, C programmers do not (and should
not) worry about the instructions the compiler generates to
carry out their wishes; they just want the program to do its
job in the most expeditious manner possible. Richard's
answer ("That's what sequence points are for") is fine for
the people who just need the program to run, but doesn't help
those who need it to run in a particular prescribed fashion
that isn't expressible in C as such. I suspected you might
be one of those and so threw out a caution flag.

--
Er*********@sun.com
May 24 '07 #8

P: n/a
Kenneth Brody said:
Richard Heathfield wrote:
>>
The semicolons mark "sequence points", which
impose the correct ordering.

But, if the compiler can prove there are no colliding side effects,
can't it rearrange them, or perhaps execute them in parallel?
If the compiler can prove that the strictly conforming program can't
tell the difference, it can do what it likes, and the strictly
conforming program - oddly enough - can't tell the difference, so it
doesn't actually matter.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 24 '07 #9

P: n/a
dspfun <ds****@hotmail.comwrites:
Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?

For example, say I have the following:

instruction1;
instruction2;
instruction3;

Is it possible to call some function/command to ensure that the
instructions are executed in this order?
What instructions?

C statements don't specify CPU instructions; they specify computations
or actions to be performed. The compiler is free to generate whatever
instructions will do the job, and to rearrange them within the
constraints imposed by the standard.

The assumption is that the programmer cares about what the program
does, not about what CPU instrutions it executes to do it. 99% of the
time, that's a valid assumption (and programmers who care about
specific instructions for some reason can always use assembly
language).

To be able to answer your question, it would be helpful if you could
answer a couple of questions. Why do you care? And what problem are
you trying to solve?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
May 24 '07 #10

P: n/a
On Thu, 24 May 2007 08:38:23 -0400, Eric Sosman wrote:
>Richard Heathfield wrote:
>dspfun said:
>>Hi!

Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?

For example, say I have the following:

instruction1;
instruction2;
instruction3;

Is it possible to call some function/command to ensure that the
instructions are executed in this order?

You don't need to. The semicolons mark "sequence points", which impose
the correct ordering.

Well, yes and no. There are sequence points, to be sure,
but they exist only in the abstract machine. When the abstract
machine reaches a sequence point, the state of the real machine
must agree with the abstract -- but only to the extent that a
conforming C program can detect the agreement (or lack thereof).
For example, if the three lines were

x = sin(a) * cos(b) + cos(a) * sin(b);
y = cos(a) * cos(b) - sin(a) * sin(b);
x=sin(a+b); y=cos(a+b);
z=atg(cos()/sin())=atg(1/tg())
> z = atan2(y, x);

... a sufficiently clever compiler might generate just five
for me computer has not to be clever
double t0, t1;
double a, b, x, y;
.........
x = (t0=sin(a))*(t1=cos(b)) + (t3=cos(a))*(t4=sin(b));
y = t3*t1 - t0*t4;
z = atan2(y, x);
or
t0=sin(a); t1=cos(b); t3=cos(a); t4=sin(b);
z = atan2(t3*t1 - t0*t4, t0*t1 + t3*t4);

the only problem here seems to be "a" and "b" are "good" double
and t0*t1 + t3*t4!=0 [sin(a+b)!=0 =a+b!=kPi]

but this should be better
if((t=sin(a+b))!=0.0)
z = atan2(cos(a+b), t );
else exit(-1);

or z= (t=sin(a+b))!=0.0 ? atan2(cos(a+b), t): 1.0/+0.0;
don't know what can happen for sin(a+b)==0

3 only calls
possibly the result can be done only use "a" and "b" so 0 calls
but i not try
May 25 '07 #11

P: n/a
"a\\/b" <al@f.gwrites:
On Thu, 24 May 2007 08:38:23 -0400, Eric Sosman wrote:
[an example of how an optimising compiler might transform a
sequence of expressions including]

x = sin(a) * cos(b) + cos(a) * sin(b);
y = cos(a) * cos(b) - sin(a) * sin(b);
z = atan2(y, x);

x=sin(a+b); y=cos(a+b);
z=atg(cos()/sin())=atg(1/tg())
If I may, I would like to comment a bit on this simplification.

Granted, you did later make the assertion that `a' and `b' be `good'.
However, trignonometric identities that are valid in the real numbers
fail, sometimes spectacularly, when applied to floating point numbers
as implemented in computer systems. For instance, what happens in the
above transformation if

(a DBL_MAX / 2.0) && (b DBL_MAX / 2.0)

?

Also, while your expression for `z' is enticing at first sight, I
would nevertheless use atan2() as the latter is designed to avoid
divide-by-zero problems.
Best regards,
--
Brd Skaflestad <Ba*************@math.ntnu.no>
May 25 '07 #12

P: n/a
On May 25, 1:45 am, Richard Heathfield <r...@see.sig.invalidwrote:
The semicolons mark "sequence points", which
impose the correct ordering.
If the compiler can prove that the strictly conforming program
can't tell the difference, it can do what it likes, and the
strictly conforming program - oddly enough - can't tell
the difference, so it doesn't actually matter.
Sometimes it is hardware, not compiler which
reorders transparently.

I hope readers don't object to off-topic, but
"interesting", anecdotes. Here's one ...

There was once a computer with a "write buffer".
When ordered to write some data, D2, at an address, A2,
it saved these in a buffer and actually wrote D1 at A1.
Later, when ordered to write D3 at A3 it saved these
in the buffer and actually wrote D2 at A2. On a read
operation, requested address was compared with write
buffer address so that buffered data could be sent
when required.

This peculiar design arose because of MOS ram
timing spec: system time from write data available at
chip to time read data from *next* cycle must be
valid exceeded chip spec.

The first prototype was a hand-soldered card
with a soldering error, such that the current
address was substituted for the correct buffered
address. The interesting thing was that *the IBM
memory diagnostics correctly with this bug*!
(This was a Brand-X memory attachment to 370/168.
Of course the IBM diagnostics did not know about
the write buffer, and of course system diagnostics
failed readily. Still it was peculiar that the
"comprehensive" memory diagnostics all passed --
this meant they all had a trivial form like
Write at A; Read at A with no intervening write;
or else wrote exact same data at all locations.)
"Usenet is a strange place" - dmr
Some computer systems were pretty strange too.
Especially ones with broken wires....

jamesdowallen at gmail

May 25 '07 #13

P: n/a
Brd Skaflestad wrote:
"a\\/b" <al@f.gwrites:
>On Thu, 24 May 2007 08:38:23 -0400, Eric Sosman wrote:
>>[an example of how an optimising compiler might transform a
sequence of expressions including]

x = sin(a) * cos(b) + cos(a) * sin(b);
y = cos(a) * cos(b) - sin(a) * sin(b);
z = atan2(y, x);
x=sin(a+b); y=cos(a+b);
z=atg(cos()/sin())=atg(1/tg())

If I may, I would like to comment a bit on this simplification.

Granted, you did later make the assertion that `a' and `b' be `good'.
However, trignonometric identities that are valid in the real numbers
fail, sometimes spectacularly, when applied to floating point numbers
as implemented in computer systems. For instance, what happens in the
above transformation if

(a DBL_MAX / 2.0) && (b DBL_MAX / 2.0)

?
Then the sines and cosines of a and b cannot be computed
with any accuracy anyhow. Garbage in, garbage out.

No compiler for any general-purpose programming language
that I've ever run into has done transformations of this kind,
and if I ever did run into one I doubt I'd like it. As you
say, identities that hold for the real numbers quite frequently
do not hold for floating-point numbers, a small subset of the
rationals. Even as simple an identity as 1+x-1==x does not
always hold (c.f. the definition of DBL_EPSILON).

My point was not about finding the fastest possible or
best possible or cleverest possible way to compute a value,
but about the ways typical compilers may try to improve on
a computation already expressed. Many improvements involve
relocating parts of the computation, substituting additions
for multiplications, and doing even weirder things. These
transformations do violence to the "instruction ordering,"
which is ordinarily not a concern for a C programmer but may
be important for the C-as-a-component-of-something-else
programmer.

--
Eric Sosman
es*****@acm-dot-org.invalid
May 25 '07 #14

P: n/a
Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?
For example, say I have the following:
instruction1;
instruction2;
instruction3;
Is it possible to call some function/command to ensure that the
instructions are executed in this order?

What instructions?

C statements don't specify CPU instructions; they specify computations
or actions to be performed. The compiler is free to generate whatever
instructions will do the job, and to rearrange them within the
constraints imposed by the standard.

The assumption is that the programmer cares about what the program
does, not about what CPU instrutions it executes to do it. 99% of the
time, that's a valid assumption (and programmers who care about
specific instructions for some reason can always use assembly
language).

To be able to answer your question, it would be helpful if you could
answer a couple of questions. Why do you care? And what problem are
you trying to solve?
Thanks for your answer! The reason I care is that I have a sequence of
registers in on-chip memory controllers and off-chip memory that must
be configured in chronological order. If the sequence of writes and
reads can be changed then the configuration will have undefined
behaviour. That's why I want to make sure things are written and read
in the order I have written the program.

BRs!

May 25 '07 #15

P: n/a
dspfun wrote On 05/25/07 09:12,:
>>>Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?
>>>For example, say I have the following:
>>>instruction1;
instruction2;
instruction3;
>>>Is it possible to call some function/command to ensure that the
instructions are executed in this order?

What instructions?

C statements don't specify CPU instructions; they specify computations
or actions to be performed. The compiler is free to generate whatever
instructions will do the job, and to rearrange them within the
constraints imposed by the standard.

The assumption is that the programmer cares about what the program
does, not about what CPU instrutions it executes to do it. 99% of the
time, that's a valid assumption (and programmers who care about
specific instructions for some reason can always use assembly
language).

To be able to answer your question, it would be helpful if you could
answer a couple of questions. Why do you care? And what problem are
you trying to solve?


Thanks for your answer! The reason I care is that I have a sequence of
registers in on-chip memory controllers and off-chip memory that must
be configured in chronological order. If the sequence of writes and
reads can be changed then the configuration will have undefined
behaviour. That's why I want to make sure things are written and read
in the order I have written the program.
What you need is `volatile'. There are a lot of
implementation-defined aspects to `volatile' so you'll
need to check your compiler's documentation, but this
is one of the purposes it exists for.

(Think of the time, words, and electrons that might
have been saved if you'd divulged this information about
your problem when you first posed it twenty-six hours
ago ... It is easy to get caught up in tactical issues
and ask questions solely about them, forgetting that the
people you're asking don't know the strategic context in
which the tactical questions arise. Next time, try to
convey a little more of the context.)

--
Er*********@sun.com
May 25 '07 #16

P: n/a
In alt.folklore.computers James Dow Allen <jd*********@yahoo.comwrote:
>On May 25, 1:45 am, Richard Heathfield <r...@see.sig.invalidwrote:
>The semicolons mark "sequence points", which
impose the correct ordering.
If the compiler can prove that the strictly conforming program
can't tell the difference, it can do what it likes, and the
strictly conforming program - oddly enough - can't tell
the difference, so it doesn't actually matter.

Sometimes it is hardware, not compiler which
reorders transparently.

I hope readers don't object to off-topic, but
"interesting", anecdotes. Here's one ...

There was once a computer with a "write buffer".
When ordered to write some data, D2, at an address, A2,
it saved these in a buffer and actually wrote D1 at A1.
Later, when ordered to write D3 at A3 it saved these
in the buffer and actually wrote D2 at A2. On a read
operation, requested address was compared with write
buffer address so that buffered data could be sent
when required.

This peculiar design arose because of MOS ram
timing spec: system time from write data available at
chip to time read data from *next* cycle must be
valid exceeded chip spec.

The first prototype was a hand-soldered card
with a soldering error, such that the current
address was substituted for the correct buffered
address. The interesting thing was that *the IBM
memory diagnostics correctly with this bug*!
(This was a Brand-X memory attachment to 370/168.
Of course the IBM diagnostics did not know about
the write buffer, and of course system diagnostics
failed readily. Still it was peculiar that the
"comprehensive" memory diagnostics all passed --
this meant they all had a trivial form like
Write at A; Read at A with no intervening write;
or else wrote exact same data at all locations.)
Which is one reason I wrote an article about 30 years ago telling
exactly *why* any decent "memory test" should use random data, or at
least algorithmic data, while bit-tests (supposedly the best tests
around at that time) would pass most failing memory.

I had plenty of real-time data to prove my point.
I never had memory that failed *any* type of pattern-test pass a random
memory test; while most memory that failed the random-pattern tests
would *pass* almost all pattern, bit, and shift tests.

Still don't trust any "memory test" that doesn't include random data
over large blocks of memory, with no repeats in the test area.

Damned few indeed still meet that criterium.
;-{
>"Usenet is a strange place" - dmr

Some computer systems were pretty strange too.
Especially ones with broken wires....

jamesdowallen at gmail
--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
May 25 '07 #17

P: n/a
On Fri, 25 May 2007 14:58:00 -0500, Frank McCoy <mc****@millcomm.com>
wrote:

<snip>
>
Still don't trust any "memory test" that doesn't include random data
over large blocks of memory, with no repeats in the test area.

Damned few indeed still meet that criterium.
;-{
Ever tried: http://www.memtest86.com/ ?

I have been using it for some years now, and it seems to do ok.
--
ArarghMail705 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.
May 25 '07 #18

P: n/a
In alt.folklore.computers Ar*****************@NOT.AT.Arargh.com wrote:
>On Fri, 25 May 2007 14:58:00 -0500, Frank McCoy <mc****@millcomm.com>
wrote:

<snip>
>>
Still don't trust any "memory test" that doesn't include random data
over large blocks of memory, with no repeats in the test area.

Damned few indeed still meet that criterium.
;-{

Ever tried: http://www.memtest86.com/ ?

I have been using it for some years now, and it seems to do ok.
Yes, I tried it, and it actually found some memory errors for me.
It has a random-data pattern test in it; but I'm not sure if it meets my
criteria or not. I *suspect* not; because of the way the data is
presented on the screen. That doesn't mean it isn't. I'd have to see
more information about the way the actual random-data is generated. My
*fears* are that they just generate a random 32-bit pattern ... and
duplicate that same 32-bits throughout memory, which is *NOT* what I
mean by random pattern testing though to a person not familiar with what
I mean, it *sounds* like the same thing, but is nowhere near the same.

--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
May 25 '07 #19

P: n/a
On Fri, 25 May 2007 18:34:45 -0500, Frank McCoy <mc****@millcomm.com>
wrote:
>In alt.folklore.computers Ar*****************@NOT.AT.Arargh.com wrote:
>>On Fri, 25 May 2007 14:58:00 -0500, Frank McCoy <mc****@millcomm.com>
wrote:

<snip>
>>>
Still don't trust any "memory test" that doesn't include random data
over large blocks of memory, with no repeats in the test area.

Damned few indeed still meet that criterium.
;-{

Ever tried: http://www.memtest86.com/ ?

I have been using it for some years now, and it seems to do ok.

Yes, I tried it, and it actually found some memory errors for me.
It has a random-data pattern test in it; but I'm not sure if it meets my
criteria or not. I *suspect* not; because of the way the data is
presented on the screen. That doesn't mean it isn't. I'd have to see
more information about the way the actual random-data is generated. My
*fears* are that they just generate a random 32-bit pattern ... and
duplicate that same 32-bits throughout memory, which is *NOT* what I
mean by random pattern testing though to a person not familiar with what
I mean, it *sounds* like the same thing, but is nowhere near the same.
New version back in Jan, 2007.

The source is available: memtest86-3.3.tar.gz is the latest version.

. . .

Just looked at it. At least 1 test calls the rand routine for each
memory word in 'test.c'. I suppose another question is how good is
the random number generator (in random.c). It's a PRNG, and I don't
know its period.
--
ArarghMail705 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.
May 26 '07 #20

P: n/a
Ar*****************@NOT.AT.Arargh.com wrote:
>
.... snip about memtest86 ...
>
New version back in Jan, 2007.

The source is available: memtest86-3.3.tar.gz is the latest version.

. . .

Just looked at it. At least 1 test calls the rand routine for each
memory word in 'test.c'. I suppose another question is how good is
the random number generator (in random.c). It's a PRNG, and I don't
know its period.
Then you should be able to replace it if you wish. The cokusmt
module (not mine) is included in hashlib.h, and is supposedly
excellent. See:

<http://cbfalconer.home.att.net/download/>

The interface is simple. Seed it with something, saving the seed
value, set the memory, reseed with the same value, and run
comparisons. Correct the 32 bit values modulo WHATEVER+1. Whether
or not it works when longs are bigger than 32 bits is unknown to
me.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

May 26 '07 #21

P: n/a
On Fri, 25 May 2007 21:08:59 -0400, CBFalconer <cb********@yahoo.com>
wrote:
>Ar*****************@NOT.AT.Arargh.com wrote:
>>
... snip about memtest86 ...
>>
New version back in Jan, 2007.

The source is available: memtest86-3.3.tar.gz is the latest version.

. . .

Just looked at it. At least 1 test calls the rand routine for each
memory word in 'test.c'. I suppose another question is how good is
the random number generator (in random.c). It's a PRNG, and I don't
know its period.

Then you should be able to replace it if you wish. The cokusmt
module (not mine) is included in hashlib.h, and is supposedly
excellent. See:

<http://cbfalconer.home.att.net/download/>

The interface is simple. Seed it with something, saving the seed
value, set the memory, reseed with the same value, and run
comparisons. Correct the 32 bit values modulo WHATEVER+1. Whether
or not it works when longs are bigger than 32 bits is unknown to
me.
Replacing the PRNG might be a good idea. memtest86 is supposed to be
able to test up to 2 gig of memory, so for a GOOD random test, the
period of the PRNG needs to be larger than 2 gig. IMO.

. . .

Just took another look at 'random.c' I can't tell from the way it's
coded just what the period might be.
--
ArarghMail705 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.
May 26 '07 #22

P: n/a
Ar*****************@NOT.AT.Arargh.com writes:
Replacing the PRNG might be a good idea. memtest86 is supposed to
be able to test up to 2 gig of memory, so for a GOOD random test,
the period of the PRNG needs to be larger than 2 gig. IMO.
Shirley it would still be "good" provided the period and 2G were
relatively prime, even if the period was smaller?

(This isn't topical in either clc or afc; followups set to
comp.programming, in the absence of any better idea. Followers-up are
of course free to ignore this suggestion.)

mlp
May 26 '07 #23

P: n/a
In alt.folklore.computers Ar*****************@NOT.AT.Arargh.com wrote:
>On Fri, 25 May 2007 18:34:45 -0500, Frank McCoy <mc****@millcomm.com>
wrote:
>>In alt.folklore.computers Ar*****************@NOT.AT.Arargh.com wrote:
>>>On Fri, 25 May 2007 14:58:00 -0500, Frank McCoy <mc****@millcomm.com>
wrote:

<snip>

Still don't trust any "memory test" that doesn't include random data
over large blocks of memory, with no repeats in the test area.

Damned few indeed still meet that criterium.
;-{

Ever tried: http://www.memtest86.com/ ?

I have been using it for some years now, and it seems to do ok.

Yes, I tried it, and it actually found some memory errors for me.
It has a random-data pattern test in it; but I'm not sure if it meets my
criteria or not. I *suspect* not; because of the way the data is
presented on the screen. That doesn't mean it isn't. I'd have to see
more information about the way the actual random-data is generated. My
*fears* are that they just generate a random 32-bit pattern ... and
duplicate that same 32-bits throughout memory, which is *NOT* what I
mean by random pattern testing though to a person not familiar with what
I mean, it *sounds* like the same thing, but is nowhere near the same.

New version back in Jan, 2007.

The source is available: memtest86-3.3.tar.gz is the latest version.

. . .

Just looked at it. At least 1 test calls the rand routine for each
memory word in 'test.c'. I suppose another question is how good is
the random number generator (in random.c). It's a PRNG, and I don't
know its period.
Um ... That sounds good.
If the source is available like you say, I *really* should look it over
and see if I can figure decent improvements to same, considering my past
background in the subject; especially in random-number generators used
to test memory. My suspicions would be (from what you describe) that
the test in question probably takes about three times as long (or even
far more) than necessary, because of it calling the routine in random.c.

*Far* faster, and just as good a test would be a pseudo-random
shift-register test based on a good ECC algorithm, that is rolled into
the code loop instead of being a function-call. For best "randomality",
doing the generation a prime number of times (3 to 7) gives
astonishingly good "randomness" as far as memory patterns are concerned.

There are other methods of doing even better; but (of course) they are
also much slower.

The key, of course, is it being a psuedo-random pattern that can be
recovered from the starting word; and if the test is run several times,
a different start used on each iteration.

Still, it's nice to know they probably *do* meet my basic criteria of a
good memory test.

Thanks.

--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
May 26 '07 #24

P: n/a
In alt.folklore.computers Ar*****************@NOT.AT.Arargh.com wrote:
>On Fri, 25 May 2007 21:08:59 -0400, CBFalconer <cb********@yahoo.com>
wrote:
>>Ar*****************@NOT.AT.Arargh.com wrote:
>>>
... snip about memtest86 ...
>>>
New version back in Jan, 2007.

The source is available: memtest86-3.3.tar.gz is the latest version.

. . .

Just looked at it. At least 1 test calls the rand routine for each
memory word in 'test.c'. I suppose another question is how good is
the random number generator (in random.c). It's a PRNG, and I don't
know its period.

Then you should be able to replace it if you wish. The cokusmt
module (not mine) is included in hashlib.h, and is supposedly
excellent. See:

<http://cbfalconer.home.att.net/download/>

The interface is simple. Seed it with something, saving the seed
value, set the memory, reseed with the same value, and run
comparisons. Correct the 32 bit values modulo WHATEVER+1. Whether
or not it works when longs are bigger than 32 bits is unknown to
me.

Replacing the PRNG might be a good idea. memtest86 is supposed to be
able to test up to 2 gig of memory, so for a GOOD random test, the
period of the PRNG needs to be larger than 2 gig. IMO.
No ... at *least* 2 gig; but not necessarily longer.
Explaining why this is so, would take considerable time.
Running it with several different starting seeds though, is a good idea
.... *if* you have the time to spare.
. . .

Just took another look at 'random.c' I can't tell from the way it's
coded just what the period might be.
It's difficult to tell with most generators.
Rather like "The Halting Problem" with computers.
Sometimes you either have to *know* from the design, or just run tests
to see.

Generally (but not always) shift-register generators that use
exclusive-ors of the last two bits and at least one from the first
three, tend to be size-limited; taking the full word-size shifted.

But, not always. I've seen a 32-bit shift that repeated in only 65K
iterations.

--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
May 26 '07 #25

P: n/a
On May 25, 8:58 pm, Frank McCoy <mcc...@millcomm.comwrote:
Which is one reason I wrote an article about 30 years ago telling
exactly *why* any decent "memory test" should use random data, or at
least algorithmic data, while bit-tests (supposedly the best tests
around at that time) would pass most failing memory.
One of the few times that I had a computer with bad memory (actually
four out of batch of seven that the company bought), no memory test
found any problems. We then found out that someone had put RAM with
wrong refresh timing into four of the machines. As long as you kept
reading and writing, that is as long as the tests ran, everything was
fine. If you left the machines alone, then over time some bits would
randomly change :-(

May 26 '07 #26

P: n/a
In alt.folklore.computers "christian.bau"
<ch***********@cbau.wanadoo.co.ukwrote:
>On May 25, 8:58 pm, Frank McCoy <mcc...@millcomm.comwrote:
>Which is one reason I wrote an article about 30 years ago telling
exactly *why* any decent "memory test" should use random data, or at
least algorithmic data, while bit-tests (supposedly the best tests
around at that time) would pass most failing memory.

One of the few times that I had a computer with bad memory (actually
four out of batch of seven that the company bought), no memory test
found any problems. We then found out that someone had put RAM with
wrong refresh timing into four of the machines. As long as you kept
reading and writing, that is as long as the tests ran, everything was
fine. If you left the machines alone, then over time some bits would
randomly change :-(
Which, believe it or not, was one of the things I found out early that
the random test catches much better than fixed pattern tests.

If you write *the entire memory* with a random data pattern, and then go
back to the beginning to see if *any* data has changed, it's surprising
what a difference you get between that and a fixed data pattern, even
one that's written and left alone. Not just dropped bits, but pattern
and address interference show up. Nothing *but* a random pattern will
properly show up those problems. Sometimes they're not really RAM
problems, but bad design of the motherboard or chip carrier. ;-{

But yes, it *does* add considerably to the test to first write the
random data-pattern and then come back minutes later and perform the
read-random test.

I've seen fixed-data-pattern tests that actually *corrected* what would
otherwise be shown as bad-data by writing to adjacent memory, or to a
similar address. The "good data" got written to the wrong address; thus
"fixing" the bad data when it got read. Not exactly what you want in a
good memory-test.

If you have a bad address line ... Shudder!
Passes every test you can throw at it with fixed patterns, rolling bits,
Xs and Os, etc.

--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
May 27 '07 #27

P: n/a
Frank McCoy <mc****@millcomm.comwrites:
>
Which, believe it or not, was one of the things I found out early that
the random test catches much better than fixed pattern tests.

If you write *the entire memory* with a random data pattern, and then go
back to the beginning to see if *any* data has changed, it's surprising
what a difference you get between that and a fixed data pattern, even
one that's written and left alone. Not just dropped bits, but pattern
and address interference show up. Nothing *but* a random pattern will
properly show up those problems. Sometimes they're not really RAM
problems, but bad design of the motherboard or chip carrier. ;-{
It isn't clear to me that "random" is really what's necessary to spot
these things: making sure adjacent bits are different seems to be
what turns these up.

May 27 '07 #28

P: n/a
krw
In article <1b************@snowball.wb.comcast.net>,
pf******@cs.nmsu.edu says...
Frank McCoy <mc****@millcomm.comwrites:

Which, believe it or not, was one of the things I found out early that
the random test catches much better than fixed pattern tests.

If you write *the entire memory* with a random data pattern, and then go
back to the beginning to see if *any* data has changed, it's surprising
what a difference you get between that and a fixed data pattern, even
one that's written and left alone. Not just dropped bits, but pattern
and address interference show up. Nothing *but* a random pattern will
properly show up those problems. Sometimes they're not really RAM
problems, but bad design of the motherboard or chip carrier. ;-{

It isn't clear to me that "random" is really what's necessary to spot
these things: making sure adjacent bits are different seems to be
what turns these up.
The problem is that it's difficult to know what is adjacent to what
in a RAM. RAM test people spend lots of time on what sounds like a
simple problem, at least on the surface.

--
Keith
May 27 '07 #29

P: n/a
Mark L Pappin wrote:
Ar*****************@NOT.AT.Arargh.com writes:
>Replacing the PRNG might be a good idea. memtest86 is supposed
to be able to test up to 2 gig of memory, so for a GOOD random
test, the period of the PRNG needs to be larger than 2 gig. IMO.

Shirley it would still be "good" provided the period and 2G were
relatively prime, even if the period was smaller?
The period of the Mersenne Twister greatly exceeds 2G. See the
original references.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

May 27 '07 #30

P: n/a
"dspfun" <ds****@hotmail.comwrote in message
news:11**********************@p47g2000hsd.googlegr oups.com...
Is there any way in C that one can guarantee that instructions are
executed in the same order as they are written in the program?

For example, say I have the following:

instruction1;
instruction2;
instruction3;

Is it possible to call some function/command to ensure that the
instructions are executed in this order?
You don't write instructions in C; you write statements. There is little
correspondence between C statements and what the processor executes.

Compilers are generally free to rearrange your program however they wish
provided that the result acts "as if" no transformations had been done.
Even if you disable all compiler optimizations, most modern CPUs also do the
same thing, and they operate on roughly the same "as if" principle as
optimizing compilers.

Perhaps if you tell us why you care, we could better answer your real
questions...

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

May 27 '07 #31

P: n/a
Which, believe it or not, was one of the things I found out early that
the random test catches much better than fixed pattern tests.

If you write *the entire memory* with a random data pattern, and then go
back to the beginning to see if *any* data has changed, it's surprising
what a difference you get between that and a fixed data pattern, even
one that's written and left alone. Not just dropped bits, but pattern
and address interference show up. Nothing *but* a random pattern will
properly show up those problems. Sometimes they're not really RAM
problems, but bad design of the motherboard or chip carrier. ;-{

It isn't clear to me that "random" is really what's necessary to spot
these things: making sure adjacent bits are different seems to be
what turns these up.

The problem is that it's difficult to know what is adjacent to what
in a RAM. RAM test people spend lots of time on what sounds like a
simple problem, at least on the surface.
You don't have to know what is adjacent to what. Assume anything
might be adjacent to anything. Random patterns, while they might
test most of the possible errors quickly, aren't guaranteed to hit
all of them.

Test by writing a pattern to the entire memory, waiting for decay,
and checking the entire memory. Patterns to use include:

- The Nth bit of the bit's address.
- The complement of the Nth bit of the bit's address.

For byte-addressable memories, also include as part of the "address"
the (3-bit) bit number, so all bits have a unique address. For a
64-bit machine, this uses 134 passes.

This will detect:

- Any bits hard-stuck at 0
- Any bits hard-stuck at 1
- Any bits hard-connected to another bit (which makes issues of which bit
is physically close to another bit on the silicon moot).
- Any address line hard-stuck at 0
- Any address line hard-stuck at 1
- Any address line hard-shorted to (wired-or or wired-and) any
other address line.

It doesn't necessarily do that well at detecting refresh timing
failures. Some memory tests do a great job of providing refresh
when it is not working, masking the failure.

It may not do a great job of testing power issues (e.g. a certain memory
state consumes more power, and if the entire memory is in that state, it
can't handle the current flow or temperature rise, causing errors.
Gordon L. Burditt
May 27 '07 #32

P: n/a
In alt.folklore.computers Joe Pfeiffer <pf******@cs.nmsu.eduwrote:
>Frank McCoy <mc****@millcomm.comwrites:
>>
Which, believe it or not, was one of the things I found out early that
the random test catches much better than fixed pattern tests.

If you write *the entire memory* with a random data pattern, and then go
back to the beginning to see if *any* data has changed, it's surprising
what a difference you get between that and a fixed data pattern, even
one that's written and left alone. Not just dropped bits, but pattern
and address interference show up. Nothing *but* a random pattern will
properly show up those problems. Sometimes they're not really RAM
problems, but bad design of the motherboard or chip carrier. ;-{

It isn't clear to me that "random" is really what's necessary to spot
these things: making sure adjacent bits are different seems to be
what turns these up.
The problem is:
It's not just adjacent bits, but address-lines, interference, loading,
and other problems. A chip with a weak addressing problem in one
address-line, for example, will *never* show a problem with an
adjacent-bit test.

Only random patterns, where NO pattern is duplicated throughout the test
area; and the whole pattern is first written and THEN tested after all
the test-area is done with writing will find such problems.

--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
May 27 '07 #33

P: n/a
(This is increasingly off-topic in comp.lang.c, which probably
should have been deleted from the newsgroups line. I do not
read alt.folklore.computers myself, though. So, one little off
topic post from me :-) )
>In alt.folklore.computers "christian.bau"
<ch***********@cbau.wanadoo.co.ukwrote:
>>One of the few times that I had a computer with bad memory (actually
four out of batch of seven that the company bought), no memory test
found any problems. We then found out that someone had put RAM with
wrong refresh timing into four of the machines. As long as you kept
reading and writing, that is as long as the tests ran, everything was
fine. If you left the machines alone, then over time some bits would
randomly change :-(
In article <jf********************************@4ax.com>
Frank McCoy <mc****@millcomm.comwrote:
>Which, believe it or not, was one of the things I found out early that
the random test catches much better than fixed pattern tests.
This depends on many things, including the "random test method":
>If you write *the entire memory* with a random data pattern, and then go
back to the beginning to see if *any* data has changed ...
.... you would still miss the problem on early versions of the
MicroVAX.

The bug there was that the automatic refresh logic simply did not
work. If you accessed enough addresses to hit every row between
maximum refresh times, however -- assuming that this was a RAS-based
refresh system; if CAS-based, simply substitute "column" here --
then all was well.

The system worked under VMS because its idle loop wandered about
through memory, triggering refreshes. It crashed oddly when BSD
Unix was brought up on it, though, because the BSD idle loop
consisted of, in essence:

while (workqueue_bitmask == 0)
continue;

Running memory tests made things work, because the memory tests
accessed different addresses in memory. What made things fail was
to *not* access (much) memory.

In other words, anything of the form:

for (p = base; p < limit; p++)
operate(*p); /* where operate is read, write, or r/m/w */

keeps it working. Even:

for (p = base; p < limit; p += small_random_number())
operate(*p);

tends to keep it working. However:

for (reg1 = 0; reg1 < LOTS; reg1++)
continue;

allows it to accumulate failures.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
May 27 '07 #34

P: n/a
In alt.folklore.computers Chris Torek <no****@torek.netwrote:
>(This is increasingly off-topic in comp.lang.c, which probably
should have been deleted from the newsgroups line. I do not
read alt.folklore.computers myself, though. So, one little off
topic post from me :-) )
>>In alt.folklore.computers "christian.bau"
<ch***********@cbau.wanadoo.co.ukwrote:
>>>One of the few times that I had a computer with bad memory (actually
four out of batch of seven that the company bought), no memory test
found any problems. We then found out that someone had put RAM with
wrong refresh timing into four of the machines. As long as you kept
reading and writing, that is as long as the tests ran, everything was
fine. If you left the machines alone, then over time some bits would
randomly change :-(

In article <jf********************************@4ax.com>
Frank McCoy <mc****@millcomm.comwrote:
>>Which, believe it or not, was one of the things I found out early that
the random test catches much better than fixed pattern tests.

This depends on many things, including the "random test method":
>>If you write *the entire memory* with a random data pattern, and then go
back to the beginning to see if *any* data has changed ...

... you would still miss the problem on early versions of the
MicroVAX.

The bug there was that the automatic refresh logic simply did not
work. If you accessed enough addresses to hit every row between
maximum refresh times, however -- assuming that this was a RAS-based
refresh system; if CAS-based, simply substitute "column" here --
then all was well.

The system worked under VMS because its idle loop wandered about
through memory, triggering refreshes. It crashed oddly when BSD
Unix was brought up on it, though, because the BSD idle loop
consisted of, in essence:

while (workqueue_bitmask == 0)
continue;

Running memory tests made things work, because the memory tests
accessed different addresses in memory. What made things fail was
to *not* access (much) memory.

In other words, anything of the form:

for (p = base; p < limit; p++)
operate(*p); /* where operate is read, write, or r/m/w */

keeps it working. Even:

for (p = base; p < limit; p += small_random_number())
operate(*p);

tends to keep it working. However:

for (reg1 = 0; reg1 < LOTS; reg1++)
continue;

allows it to accumulate failures.
For that specific type of problem, there probably isn't a free-running
test that can even be designed that will catch *all* of such problems;
as every memory-test will loop through a certain set of addresses in a
Von Neumann machine anyway, as the program itself loops. The problem
you mention shows up when certain areas of memory aren't accessed; but
another similar type of problem would show up if close-together memory
locations weren't accessed. The only solution for both would be a
random-pattern test which went into a *halt* condition after writing;
which a timed interrupt pulled it out of several seconds (or, in an
extreme test, minutes) later when the read would be performed. Most
"modern" computers won't stand for such stuff; nor do they have the
proper interrupt system to handle it if the programmer wanted to try.

Still, it *would* be a good trick if you could pull it off.
It might be "merely difficult", not impossible.
I remember some other "impossible" jobs for particular computers ....

I doubt it could even be written in C, considering the constraints of
the language.
An assembly-language programmer might pull it off though, if he knew the
interrupt and timer structure well enough.

Ada *might*; but I doubt it.

--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
May 27 '07 #35

P: n/a
On 27 May 2007 06:28:14 GMT
Chris Torek <no****@torek.netwrote:
... you would still miss the problem on early versions of the
MicroVAX.

The bug there was that the automatic refresh logic simply did not
work. If you accessed enough addresses to hit every row between
maximum refresh times, however -- assuming that this was a RAS-based
refresh system; if CAS-based, simply substitute "column" here --
then all was well.
Oh yummy just like a problem I had on the first prototype 6MHz Z80
board for the Torch. It would boot, copy the ROM into RAM, load the OS and
present a prompt. By the time a command was typed enough had corrupted to
ensure that it did strange and unexpected things. Putting a test ROM in
revealed problems that looked to be refresh failures. Spend hours staring
at 'scope traces looking for the timing glitch that wasn't there.
Eventually discover that the wrong chips are in the sockets and these ones
didn't do pin 1 refresh.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
May 27 '07 #36

P: n/a
On Sun, 27 May 2007 01:51:14 -0500
Frank McCoy <mc****@millcomm.comwrote:
The only solution for both would be a
random-pattern test which went into a *halt* condition after writing;
which a timed interrupt pulled it out of several seconds (or, in an
extreme test, minutes) later when the read would be performed. Most
"modern" computers won't stand for such stuff; nor do they have the
proper interrupt system to handle it if the programmer wanted to try.
Are you sure ? FreeBSD systems use halt and an interrupt for the
idle loop and PCs do have timers that interrupt which I'm pretty sure can
be made to provide long enough delays for this. I think for multi-processor
systems you probably have to disable all but one CPU. What's missing ?

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
May 27 '07 #37

This discussion thread is closed

Replies have been disabled for this discussion.