13 May
2005
13 May
'05
3:05 p.m.
From: "Paul Koning" <pkoning at
equallogic.com>
Hi
The last place I worked, the processor was designed to
be able to optimize by doing out of order execution ( HaL
computer system, first Sparc64 ). They soon discovered the
problem when dealing with I/O. They, luckily, had a
sequential mode that they could switch to during I/O
operations that made the order predictable. You'd have
thought that someone in the design team might have realized
the problem.
Dwight
>>>> "Dwight" == Dwight K
Elvey <dwight.elvey at amd.com> writes:
> From: "Lyle Bickley" <lbickley
at bickleywest.com>
Dwight> ---snip--- The first sentence in
> the final paragraph reads: "The moral of
this discussion is that
> writing code which depends on order of evaluation is a bad
> programming practice in any language."
>
> I'll buy that.
Dwight> Hi Interesting! I've always considered order of execution to
Dwight> be one of the fundamentals of being able to predict what a
Dwight> computer does. I've always thought of it as an accentual part
Dwight> of programming with predictable results.
That's true for a single CPU sequential computer without any
interrupts going on. It isn't true if you run things in parallel on
several CPUs. It may not be true in multi-issue computer (which is
most modern fast CPUs) if the architecture has sufficiently relaxed
ordering rules.
But all that applies to the hardware. Many programming languages
don't specify a single order of doing everything in every possible
program, but instead leave things partially unspecified, so the
translation from source code to machine language has more
opportunities for optimization. So even if a machine is fully
sequential and fully ordered, the high level language programs you
feed it might not be.
paul