Thread

1. Platforms with v6.3 trouble

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-25T14:28:37Z

   >From what I understand, there are at least two platforms which are
   having trouble with the macro inlining in v6.3. The alpha ports have
   trouble inlining the slock assembler code, and the SCO port has trouble
   inlining the cache lookup code.
   
   Since these macros were inlined only for performance reasons, would it
   be possible to revert to non-inline function calls for these platforms?
   It would seem that substituting a macro expansion for a compiled routine
   could be done with a compiler switch (e.g. USE_INLINING) so it could be
   turned on and off at will.
   
   For most of us, the performance gains are fantastic, but for those ports
   which broke performance has degraded to zero :(
   
                                                                      - Tom
   
   
   

2. Re: [HACKERS] Platforms with v6.3 trouble

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-25T15:19:55Z

   > 
   > >From what I understand, there are at least two platforms which are
   > having trouble with the macro inlining in v6.3. The alpha ports have
   > trouble inlining the slock assembler code, and the SCO port has trouble
   > inlining the cache lookup code.
   > 
   > Since these macros were inlined only for performance reasons, would it
   > be possible to revert to non-inline function calls for these platforms?
   > It would seem that substituting a macro expansion for a compiled routine
   > could be done with a compiler switch (e.g. USE_INLINING) so it could be
   > turned on and off at will.
   > 
   > For most of us, the performance gains are fantastic, but for those ports
   > which broke performance has degraded to zero :(
   
   Yes, how do we do that?  Do we have inlined-versions of these files? 
   Sounds messy.  Can people run cpp separately on the files, then compile
   them?  I wonder.  I think this is an SCO-only problem, and seeing as
   their native compilers are notoriously buggy (Microsoft/SVr4 code), it
   is no wonder.
   
   The alpha problem has been solved by having a s_lock.c file, that only
   contains the alpha/linux locking code.  They don't have local asm
   labels, and hence the workaround.  I believe this is not a problem issue
   for 6.3.  Anyone?  Of course, we still have the initdb problem, or do
   we?
   
   
   -- 
   Bruce Momjian                          |  830 Blythe Avenue
   maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
     +  If your life is a hard drive,     |  (610) 353-9879(w)
     +  Christ can be your backup.        |  (610) 853-3000(h)
   
   

3. Re: [HACKERS] Platforms with v6.3 trouble

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-25T17:36:26Z

   > > Since these macros were inlined only for performance reasons, would it
   > > be possible to revert to non-inline function calls for these platforms?
   > > It would seem that substituting a macro expansion for a compiled routine
   > > could be done with a compiler switch (e.g. USE_INLINING) so it could be
   > > turned on and off at will.
   > >
   > > For most of us, the performance gains are fantastic, but for those ports
   > > which broke performance has degraded to zero :(
   >
   > Yes, how do we do that?  Do we have inlined-versions of these files?
   > Sounds messy.  Can people run cpp separately on the files, then compile
   > them?  I wonder.  I think this is an SCO-only problem, and seeing as
   > their native compilers are notoriously buggy (Microsoft/SVr4 code), it
   > is no wonder.
   
   Well, those macros used to be a function call, right? So surround the macro
   with#ifdef USE_INLINING
   #define ...
   #endif
   
   and surround the old subroutine code with
   
   #ifndef USE_INLINING
   ...
   #endif
   
   Or are the macros of a different nature and not just a subroutine inlining?
   If there still needs to be a little macro expansion, then that could be done
   also...
   
   > The alpha problem has been solved by having a s_lock.c file, that only
   > contains the alpha/linux locking code.  They don't have local asm
   > labels, and hence the workaround.  I believe this is not a problem issue
   > for 6.3.  Anyone?  Of course, we still have the initdb problem, or do
   > we?
   
   Don't know...
   
   
   

4. Re: [HACKERS] Platforms with v6.3 trouble

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-25T19:10:52Z

   > Well, those macros used to be a function call, right? So surround the macro
   > with#ifdef USE_INLINING
   > #define ...
   > #endif
   > 
   > and surround the old subroutine code with
   > 
   > #ifndef USE_INLINING
   > ...
   > #endif
   > 
   
   I was trying to avoid having the code in two places, and you can't just
   copy the macro. You have to replace the parameters in each instance for
   the huge conditional to work.
   
   -- 
   Bruce Momjian                          |  830 Blythe Avenue
   maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
     +  If your life is a hard drive,     |  (610) 353-9879(w)
     +  Christ can be your backup.        |  (610) 853-3000(h)