Re: [BENCHMARK] Corrected gcc3.2 v gcc2.95.3 contest results

[Richard B. Johnson]

On Mon, 23 Sep 2002, Erik Andersen wrote:

> On Mon Sep 23, 2002 at 08:30:21PM +1000, Con Kolivas wrote:
> > Yes you make a very valid point and something I've been stewing over privately
> > for some time. contest runs benchmarks in a fixed order with a "priming" compile
> > to try and get pagecaches etc back to some sort of baseline (I've been trying
> > hard to make the results accurate and repeatable). 
> 
> It would sure be nice for this sortof test if there were
> some sort of a "flush-all-caches" syscall...
> 
>  -Erik

I think all you need to do is reload the code-segment register
and you end up flushing caches in ix86.

#
#   This forces a cache-line refill by reloading the code-segment
#   segment register. This would normally slow things down. However,
#   if I put this at the start of a procedure that suffers a cache-line
#   refill within the procedure, it is possible to speed things up.
#
.section	.text
.global		cflush	
.type		cflush,@function

cflush: pushl	%cs		# Put code segment on the stack
	pushl	$goto		# Put offset on the stack
	lret			# Do a 'long' return (reloads cs)
goto:	ret
.end

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.