Re: vim 6.3 errors on sunos 4.1.3_U1
- George V. Reilly <george@...> wrote:
> Antoine J. Mechelynck wrote:Vim admittedly spends most of its time waiting for keyboard action. But how
> > IMHO, a function like strcmp() should not be emulated in C because
> > of speed constraints. If you want to rewrite it, OK, but do it in
> > assembly language (and since assembly is inherently non-portable,
> > write a different version for each possible processor...). For
> > example, on the i86 family, I believe that REPE CMPSB is
> > significantly faster than the loop described above in C, even if
> > you first have to do a REPNE SCASB to find the null byte.
> This fragile approach is worthwhile only if strcmp() is a major
> bottleneck. Most Vim operations consume minimal amounts of CPU time
> on a modern gigahertz processor. Even on a decade-old Sparc,
> rewriting strcmp in assembler is unlikely to yield a noticeable
> improvement in Vim.
about commands like :substitute or :helpgrep, which IIUC do quite a lot of
string comparisons before they return to the wait-for-keyboard state? I
maintain that whatever the gigaspeed, for something as basic as string
comparison, you can only afford the fastest of the fast coding.
- Craig Barkhouse wrote:
> I don't know how difficult this is to do, but... Maybe the configureA system with a strcmp() that doesn't work???? That is the most stupid
> script should have a test to see if strcmp() works in the critical
> scenario (i.e. strings containing 0x80). Then, depending on an
> #ifdef, either override strcmp() or not.
bug heard off. I don't think it's worth checking for, that system is
broken. Do we also need to test for bad RAM chips perhaps?
Two fish in a tank. One says to the other:
"Do you know how to drive this thing?"
/// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
/// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ Project leader for A-A-P -- http://www.A-A-P.org ///
\\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///