9fans archive / 1997 / 04 / 73    prev next


    search terms are split using tokenize    
    from:regexp searches From: lines    
    subject:regexp searches Subject: lines    
    before:yyyy[/mm[/dd]] and after:yyyy[/mm[/dd]] specify date range    

    powered by grep(1)    
From: David Johnston DJ@sym...
Subject: In defence of hardware engineers and out of order execution.
Date: Tue, 22 Apr 1997 15:04:37 +0100

Being a hardware type (with a CS background) I'm feeling a little under
fire here. Out of order execution is a pretty reasonable way of making a
processor go faster. If processor designers didn't pull every trick to
make the things go faster you'd all go and buy somebody else's. Then
again you'd probably buy Intel anyway.

The general principal is of course that the computations performed have
the same end result as executing in order but for a single locus of
control only. It's a bit much to expect the processor to guess what the
other processors are up to at instruction rate. The introduction of
pipelines, caches and optimising compilers have all forced extra
constraints on software writers (self modifying code used to be
mandatory for efficient use of the 256bytes of program memory) so don't
be too surprised at this sort of jiggery pokery on a 30 billion gate
processor.

Intel are of course to be deplored for not documenting sufficiently that
you can analyse exactly what will happen but then Intel have a bit of
reputation to keep down. Documenting their processors would never do.

The poor, hassled micro designer has your best interests at heart and is
likely to provide something to fix the problem. From the top of my head
I think the powerPC provides an EIEIO instruction (Something like:
Enforce in order execution of something of other, I've lost the book)
god knows what the Pentiblob provides but the best a processor designer
can do is provide an instruction or a processor mode which switches off
the reordering. They can't second guess the compiler writers. So there
will inevitably be some machine dependency.

So why not provide a system call like:

  set_the_bloody_reordering_mode(reordermode a)

Which on many architectures will dissolve down to nothing, however on
pentiblob pros and the like it will land you with an assembler
instruction to do the business.

The whole messy edifice of parallel computing theory and practice has
been set up to sort out what happens when some madman goes and writes:

	par {
		{ a = 1; x = b; }
		{ b = 1; y = a; }
	}

Maybe this would be better:

 	set_the_bloody_reordering_mode(REORDERMODE_OFF);
	par {
		{ a = 1; x = b; }
		{ b = 1; y = a; }
	}
	set_the_bloody_reordering_mode(REORDERMODE_ON);

Apologies for the non plan9 style verbosity, but I've been writing VHDL
all this week, sigh.

David Johnston