Subject: Re: g4, cache and speculative addressing
To: Riccardo Mottola <rollei@tiscalinet.it>
From: Bruce O'Neel <edoneel@sdf.lonestar.org>
List: port-macppc
Date: 06/27/2005 10:55:34
Hi,

I'm fighting a similar problem but my sonnet g4 card doesn't seem
to work as well as yours does :-(


On Mon, Jun 27, 2005 at 10:47:30AM +0200, Riccardo Mottola wrote:

> - powerlogix states that speculative addressing could be a problem on
> non-g3/g4 computers which get such a processor. But My question is "why"
> ? is it a ROM problem? an MacOS problem? Should it be disabled in NetBSD
> too? (and how?) I thought we didn't utilize ROM functions. But if the
> problem is instead some hardware controller...

Googling  sonnet g4 speculative processing problems

turns up some articles on macspeedzone.com.  They seem to say that:

- 8600 and 9600 machines are ok.  My guess is the systems that can use 
the 350mhz 604ev chips are ok.
- Everything else might need either extra chips on the cpu 
card and/or openfirmware patches.

The basic problem that speculative processing is trying to solve is
that modern CPUs are pipelined.  This means that the whole CPU can
stop and wait if an unanticipated memory location is referenced that
say is not in the cache.  This is not good.  What happens then is that
the CPU works to read ahead instructions and data and start them
executing as well, even if they might never be need to be executed
(say they are on a branch that is never taken).  Ars Technica has
several articles that explain this well.

Normally this would be ok, but not always.

Let's say we have code that does

blah
blah
blah
read a status value from the network chip
if data is ready then 
read the data buffer
read status register 2 <- this causes the chip to change states
write the status value indicating data read
endif

What can happen here is that with speculative processing, possibly
before the status value from the network chip has been read the data
buffer can be read and the status register 2 could also have been
read.  There is no guarantee that the reads occur in the order that
they exist in the code, nor is there a guarantee that all or none
occur if the then is not taken.  The only guarantee is that the write
won't happen if the then isn't taken.

Now for normal memory, at worst, you've just wasted a memory read or two.
But for a device you might have put it in an inconsistant state, and/or
lost a databuffer partially filled, etc.  This is not good.

If someone has any insight as to what the openfirmware patches might
look like that would be fantasic.  I think I have this problem as was
not looking forward to reinstalling MacOS just to install the software
that came with the card.

cheers

bruce

-- 
edoneel@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org