ralf@uni-koblenz.de wrote:
>
> On Tue, May 19, 1998 at 10:24:43AM +0100, Mike Jagdis wrote:
>
> > My own feeling is that this is not so useful as it might appear
> > at first glance. If you _really_ want to try something interesting
> > why not write a gcc back end that uses a locked L1 line as a nice
> > big register file and see if you can push the x86 architecture to
> > new heights?
>
> ... which somehow reminds of the Texas Instruments TMS 8900 used in the
> TI99/4a, just that it had no cache and the register file was part of the
> memory. Slow, especially when the memory bus is shared with the video
> subsystem.
I designed a TMS9900 (not 8900, BTW) based motherboard at the time when
it was the only 16-bit microprocessor available. Back then (1980-81) the
bottleneck was the CPU, not the memory. Nowadays it's exactly the other
way around.
>
> Playing games with the cache is almost always a bad idea. The standard
> lru or lru like replacement algorithems tend to be pretty good heuristics.
> The cache locking feature is usually a candy added for sake of ``ultra
> hard realtime'' apps for which cache line replacement would cause too much
> jitter in the reaction times. Before that these guys often used to live
> without caches for sake of consistent memory delays.
I think the point of locking cache lines is that a cache miss has a very
high cost in terms of CPU clock cycles, because of the line refill
latency.
But as suggested by Mike Jagdis, it could be a way to workaround one of
the worst quirks of the x86 architecture: the scarcity of registers.
Cheers,
------------------------
André Balsa
andrebalsa@altern.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu