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

Re: New Makefile for bcc 5.5

Expand Messages
  • maurice s. barnum
    ... on a vaguely related subject, i think that using the -pr switch ( use register calling convention by default ) was a mistake that has resulted in the Vim
    Message 1 of 9 , Apr 1, 2000
    • 0 Attachment
      Bram Moolenaar <Bram@...> writes:

      : Thanks to a hint from Dan Sharp, menus do work now when Vim is compiled with
      : the free Borland C compiler 5.5.
      :

      on a vaguely related subject, i think that using the -pr switch ("use register
      calling convention by default") was a mistake that has resulted in the
      Vim source being littered with "#ifdef __BORLANDC__". the performance
      advantage of the register calling convention will only come into play
      with rather small functions: otherwise, the parameter will likely get
      pushed onto the stack to free up the register in which it's sitting.

      would you be interested in a tested patch that removes this clutter?


      : There is one remaining problem that I could not solve yet: When running the
      : OLE version, it cannot register itself. After successfully registering (using
      : a gvim compiled with MS-VC) it does run normally. Does anyone know why
      : registering doesn't work?

      I don't, but i'll take a look at it.

      --xmsb
    • Bram Moolenaar
      ... Having system or compiler specific #ifdefs in many files is certainly a disadvantage. And when making changes these __BORLANDC__ things may need to be
      Message 2 of 9 , Apr 2, 2000
      • 0 Attachment
        Maurice S. Barnum wrote:

        > on a vaguely related subject, i think that using the -pr switch ("use
        > register calling convention by default") was a mistake that has resulted in
        > the Vim source being littered with "#ifdef __BORLANDC__". the performance
        > advantage of the register calling convention will only come into play
        > with rather small functions: otherwise, the parameter will likely get
        > pushed onto the stack to free up the register in which it's sitting.
        >
        > would you be interested in a tested patch that removes this clutter?

        Having system or compiler specific #ifdefs in many files is certainly a
        disadvantage. And when making changes these __BORLANDC__ things may need to
        be updated too. If there is no noticable performance difference, I would
        rather get rid of them.

        > : There is one remaining problem that I could not solve yet: When running the
        > : OLE version, it cannot register itself. After successfully registering
        > : (using a gvim compiled with MS-VC) it does run normally. Does anyone know
        > : why registering doesn't work?
        >
        > I don't, but i'll take a look at it.

        Please do, it's probably simple to solve if you know how to do it...

        --
        There is no right or wrong, there is only your personal opinion.
        (Bram Moolenaar)

        /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
        \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
      • Martin Dalecki
        ... The shouldn t be any. Modern ix86 processors have register renaming, TLB s fast 1 level caches... even more some have dedicated stack caches... ... --
        Message 3 of 9 , Apr 2, 2000
        • 0 Attachment
          Bram Moolenaar wrote:
          >
          > Maurice S. Barnum wrote:
          >
          > > on a vaguely related subject, i think that using the -pr switch ("use
          > > register calling convention by default") was a mistake that has resulted in
          > > the Vim source being littered with "#ifdef __BORLANDC__". the performance
          > > advantage of the register calling convention will only come into play
          > > with rather small functions: otherwise, the parameter will likely get
          > > pushed onto the stack to free up the register in which it's sitting.
          > >
          > > would you be interested in a tested patch that removes this clutter?
          >
          > Having system or compiler specific #ifdefs in many files is certainly a
          > disadvantage. And when making changes these __BORLANDC__ things may need to
          > be updated too. If there is no noticable performance difference, I would
          > rather get rid of them.

          The shouldn't be any. Modern ix86 processors have register renaming,
          TLB's
          fast 1 level caches... even more some have dedicated stack caches...

          >
          > > : There is one remaining problem that I could not solve yet: When running the
          > > : OLE version, it cannot register itself. After successfully registering
          > > : (using a gvim compiled with MS-VC) it does run normally. Does anyone know
          > > : why registering doesn't work?
          > >
          > > I don't, but i'll take a look at it.
          >
          > Please do, it's probably simple to solve if you know how to do it...
          >
          > --
          > There is no right or wrong, there is only your personal opinion.
          > (Bram Moolenaar)
          >
          > /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
          > \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

          --
          Marcin Dalecki
        • Ron Aaron
          ... Ahem. If I may interject, I am the one who made the Borland compiles use register calling convention. Before you turn off the feature, benchmark the
          Message 4 of 9 , Apr 2, 2000
          • 0 Attachment
            Maurice S. Barnum <pixi@...> writes:
            >Bram Moolenaar <Bram@...> writes:
            >
            >: Thanks to a hint from Dan Sharp, menus do work now when Vim is compiled with
            >: the free Borland C compiler 5.5.
            >:
            >
            >on a vaguely related subject, i think that using the -pr switch ("use register
            >calling convention by default") was a mistake that has resulted in the

            Ahem. If I may interject, I am the one who made the Borland compiles use
            register calling convention.

            Before you turn off the feature, benchmark the behaviour with and without it.
            I saw a 15-30% speed improvement with the feature on, as well as a size
            reduction in the executable. The benefit will be different depending on the
            processor class etc, but do be sure to test on 486, Pentium and newer
            processors -- and realize that *many* people use older CPUs.

            In my judgement, the benefit of 'fastcall' was worth cluttering the code with
            a few #ifdefs. YMMV.

            >the performance
            >advantage of the register calling convention will only come into play
            >with rather small functions: otherwise, the parameter will likely get
            >pushed onto the stack to free up the register in which it's sitting.

            Have you *benchmarked* this to verify what you are saying? My experience is
            different than what you indicate, but admittedly the source is fairly
            different than the version I put 'fastcall' in.

            >
            >would you be interested in a tested patch that removes this clutter?

            No, thanks -- I use the much better 'gcc-2.95.2' free compiler now :-)

            Ron
          • maurice s. barnum
            ... well, numbers beats conjecture, that s for sure. i don t have a 486 available, but i ll test on some slower machines and ask for help when i have the
            Message 5 of 9 , Apr 2, 2000
            • 0 Attachment
              "Ron Aaron" <ron@...> writes:


              : Before you turn off the feature, benchmark the behaviour with and without it.
              : I saw a 15-30% speed improvement with the feature on, as well as a size
              : reduction in the executable. The benefit will be different depending on the
              : processor class etc, but do be sure to test on 486, Pentium and newer
              : processors -- and realize that *many* people use older CPUs.
              :
              : >the performance
              : >advantage of the register calling convention will only come into play
              : >with rather small functions: otherwise, the parameter will likely get
              : >pushed onto the stack to free up the register in which it's sitting.
              :
              : Have you *benchmarked* this to verify what you are saying? My experience is
              : different than what you indicate, but admittedly the source is fairly
              : different than the version I put 'fastcall' in.
              :

              well, numbers beats conjecture, that's for sure. i don't have a 486
              available, but i'll test on some slower machines and ask for help when
              i have the patch ready. out of curiosity, what did you use to make
              the measurements, and was this for win32 or dos?

              --xmsb
            • maurice s. barnum
              ... i haven t had any luck reproducing this problem yet on a win2k system. i don t think i ve ever run the ole-enabled gvim before, and i ve scoured the
              Message 6 of 9 , Apr 5, 2000
              • 0 Attachment
                Bram Moolenaar <Bram@...> writes:

                : > : There is one remaining problem that I could not solve yet: When running the
                : > : OLE version, it cannot register itself. After successfully registering
                : > : (using a gvim compiled with MS-VC) it does run normally. Does anyone know
                : > : why registering doesn't work?
                : >
                : > I don't, but i'll take a look at it.
                :
                : Please do, it's probably simple to solve if you know how to do it...

                i haven't had any luck reproducing this problem yet on a win2k
                system. i don't think i've ever run the ole-enabled gvim before, and
                i've scoured the registry looking for vim stuff to delete.

                if i get a bit of time later this week, i'll try on nt4 and see what i
                can find.

                --xmsb
              • Bram Moolenaar
                ... In case it matters, I had these registration problems of OLE gvim on Windows 98 (original, I still don t have SE). The version compiled with MS-VC works
                Message 7 of 9 , Apr 5, 2000
                • 0 Attachment
                  Maurice S. Barnum wrote:

                  > : > : There is one remaining problem that I could not solve yet: When running the
                  > : > : OLE version, it cannot register itself. After successfully registering
                  > : > : (using a gvim compiled with MS-VC) it does run normally. Does anyone know
                  > : > : why registering doesn't work?
                  > : >
                  > : > I don't, but i'll take a look at it.
                  > :
                  > : Please do, it's probably simple to solve if you know how to do it...
                  >
                  > i haven't had any luck reproducing this problem yet on a win2k
                  > system. i don't think i've ever run the ole-enabled gvim before, and
                  > i've scoured the registry looking for vim stuff to delete.
                  >
                  > if i get a bit of time later this week, i'll try on nt4 and see what i
                  > can find.

                  In case it matters, I had these registration problems of OLE gvim on Windows
                  98 (original, I still don't have SE). The version compiled with MS-VC works
                  just fine. Perhaps another #define we need to set for Bcc 5.5?

                  --
                  "I've been teaching myself to play the piano for about 5 years and now write
                  most of my songs on it, mainly because I can never find any paper."
                  Jeff Lynne, ELO's greatest hits

                  /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
                  \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
                • maurice s. barnum
                  ... oh, that makes things uglier to track down, but with that clue i can find an appropriate machine at work to test on and report back tomorrow if someone
                  Message 8 of 9 , Apr 5, 2000
                  • 0 Attachment
                    Bram Moolenaar <Bram@...> writes:

                    : Maurice S. Barnum wrote:
                    :
                    : > i haven't had any luck reproducing this problem yet on a win2k
                    : > system. i don't think i've ever run the ole-enabled gvim before, and
                    : >
                    : > if i get a bit of time later this week, i'll try on nt4 and see what i
                    : > can find.
                    :
                    : In case it matters, I had these registration problems of OLE gvim on Windows
                    : 98 (original, I still don't have SE). The version compiled with MS-VC works
                    : just fine. Perhaps another #define we need to set for Bcc 5.5?

                    oh, that makes things uglier to track down, but with that clue i can
                    find an appropriate machine at work to test on and report back
                    tomorrow if someone doesn't beat me to it.

                    --xmsb
                  Your message has been successfully submitted and would be delivered to recipients shortly.