Loading ...
Sorry, an error occurred while loading the content.
 

Re: vim 6.3 errors on sunos 4.1.3_U1

Expand Messages
  • Antoine J. Mechelynck
    ... 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
    Message 1 of 10 , Aug 9, 2004
      Craig Barkhouse <cabarkho@...> wrote:
      > ----- Original Message -----
      > From: "Soh Tk-r28629" <TKSoh@...>
      > To: "'Yakov Lerner'" <qlerner@...>
      > Cc: <vim@...>; <vim-dev@...>
      > Sent: Monday, August 09, 2004 12:04 AM
      > Subject: RE: vim 6.3 errors on sunos 4.1.3_U1
      >
      >
      > > > -----Original Message-----
      > > > > The bug has been comfirmed. I found this in patch #101759 for
      > > > > SunOS
      > > > > 4.1.3_U1 (similar bug for 4.1.3):
      > > > >
      > > > > 1074633 strcmp gets bad result when 0x80 char put in string
      > > > >
      > > > > I downloaded the patch and it did fix the problem I have with
      > > > > vim. Since I can't apply the patch to all the Sun boxes (of our
      > > > > manufacturing equipments), I wonder if we can just change
      > > > K_SPECIAL to something else. I've changed it to 0x81, which
      > > > seemed to work so far.
      > > > >
      > > > >
      > > > When patch can't be installed, the safe solution is is to
      > > > link with home-grown strcmp.o (code untested, but seems ok to me):
      > > >
      > > > /* strcmp.c - work around libc strcmp() bug */
      > > > int strcmp(const char* p, const char* q) { /* untested */
      > > > while(*p == *q && *p != 0) /* untested */
      > > > p++, q++; /* untested */
      > > > return *p - *q; /* untested */
      > > > }
      > >
      > > I don't know if strcmp() can be replace so easily judging from it's
      > > manpages.
      >
      > Why not? It's a pretty simple function.
      >
      > I don't know how difficult this is to do, but... Maybe the configure
      > 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.

      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.

      Regards,
      Tony.
    • George V. Reilly
      ... 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
      Message 2 of 10 , Aug 9, 2004
        Antoine J. Mechelynck wrote:

        >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.

        --
        Audemus jura nostra defendere...
        [Let us dare defend our rights.]
        (Get Witty Auto-Generated Signatures from http://SmartBee.org)
        George V. Reilly george@...
        http://george.reilly.org/
      • Antoine J. Mechelynck
        ... Vim admittedly spends most of its time waiting for keyboard action. But how about commands like :substitute or :helpgrep, which IIUC do quite a lot of
        Message 3 of 10 , Aug 9, 2004
          George V. Reilly <george@...> wrote:
          > Antoine J. Mechelynck wrote:
          >
          > > 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.

          Vim admittedly spends most of its time waiting for keyboard action. But how
          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.

          Regards,
          Tony.
        • Bram Moolenaar
          ... A system with a strcmp() that doesn t work???? That is the most stupid bug heard off. I don t think it s worth checking for, that system is broken. Do
          Message 4 of 10 , Aug 31, 2004
            Craig Barkhouse wrote:

            > I don't know how difficult this is to do, but... Maybe the configure
            > 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.

            A system with a strcmp() that doesn't work???? That is the most stupid
            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 ///
          Your message has been successfully submitted and would be delivered to recipients shortly.