Message-ID: <355276B2.16DBD939@vlsi.com> Date: Thu, 07 May 1998 20:06:26 -0700 From: Charles Marslett MIME-Version: 1.0 To: Nate Eldredge CC: djgpp-workers AT delorie DOT com Subject: Re: Far string/mem functions available for testing References: <19980508005312 DOT AAD26907 AT ppp117 DOT cartsys DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Nate Eldredge wrote: > At 11:23 5/7/1998 +0200, Vik Heyndrickx wrote: > >.... > >``FIXME string operations'' remarks: FYI they are not generally slow > >when they are > >repz/repnz-ed. Intel knows where they are used for (I hope ;-) > > I seem to recall from looking at some glibc sources that on newer > processors, Intel had put more work into speeding up the more RISC-ish > instructions than the string ones. The result was that they could sometimes > be slower than their simpleminded equivalents. I don't know enough to know > whether that applies here, hence the comment. But you may well be right. A pretty good rule of thumb is that "move"s are faster, "load"s and "store"s are not [for the Pentium]. I think "REPZ CMPD" might be slower too, but I'm not sure. Ppros and P-IIs are a lot more complicated, but they look more like 486s than Pentiums (that is, the dual pipe tricks no longer help, so REPs may start helping more again). Not a lot has been written (that I've read, at least) on P6 string optimization, though, so I stand to learn a lot about these cases if anyone else has a bit to say. >.... > Btw, can somebody tell me the following about LFN's: > * Is case significant with LFN's enabled? i.e. will open("FooBar") fail if > the file is really `foobar'? Nope, case is only sorta significant. Case is preserved (and returned) but two file names differing only in case will match. And Win95 seems to preserve the existing file name more than I would think possible (my version of MicroEMACS, for example, is set up to build a temporary, then when the write takes place, the original is deleted and the temporary is renamed -- usually, but not always, the updated file will have the same case as the original in spite of the fact that the program is not LFN aware and the original file should have been flushed before the rename takes place!). > * If so, is there a way to make Info-Zip store names as what you tell it, > instead of the actual file names? > > I ask because my distribution includes some .S files, and GCC interprets > that differently from .s, and I only have SFNs. Previously I made the zip on > Linux, but rebooting all the time is a pain. For paranoia I am now including > a fixlfn.bat file which will rename them to the appropriate cases, but if > there is a better solution I would like to know it. (I'm also considering > just naming them .s, and passing GCC `-x assembler-with-cpp', but that's not > pretty.) I, too, would like to know the answer to this question! > Thanks again > > Nate Eldredge > nate AT cartsys DOT com --Charles