Date: Fri, 19 Apr 1996 13:30:31 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@sri.MT.net (Nate Williams) Cc: terry@lambert.org, kuku@gilberto.physik.rwth-aachen.de, freebsd-current@freefall.freebsd.org Subject: Re: gzipped executables Message-ID: <199604192030.NAA08890@phaeton.artisoft.com> In-Reply-To: <199604192012.OAA04133@rocky.sri.MT.net> from "Nate Williams" at Apr 19, 96 02:12:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Is anyone working on fixing the broken gzip executable feature in > > > -current? > > > > It's a cache interaction. Pentium caches are written back inside > > the cache queue depth, whereas pre-Pentium processors have > > immutable cache queues. > > > > It can be fixed by incorporating 32 NOP's (until the next processor > > revision, anyway), in part of the code. > > If this is the case, why did it used to work on Pentium processors? Because it's circumstantial based on where the code is loaded -- and now it's loaded at a new place and you see the problem -- an optimized loop is wholly in cache. I'm suprised, given the size of the cache, that it worked at all on Pentium boxes, ever. In either case, I was able to kludge a fix locally. A real fix wants to alternate the compress-from/compress-to areas to intentionally force LRU activity. As in inverting the compressed image, or inverting the page ordering between decompress and execute. Alternately, throwing 32 NOP's before jumping will work with current cache queue depths. Didn't we discuss all this in detail before? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604192030.NAA08890>