Re: FYI: 4-gary-symtab-rewrite.patch

[Gary V. Vaughan]

On Thu, Oct 04, 2001 at 10:20:04AM +0200, Akim Demaille wrote:
> >>>>> "Gary" == Gary V Vaughan <address@hidden> writes:
> 
> Gary> Hi, This one's a biggie.  I have been meaning to do this for
> Gary> over a year, and some of the groundwaork was already in place...
> 
> Never answered before, but I read it, and it's great.  Congrats!

Thanks.  I have been thinking about the new layout some more, and I
think that it is still not a good fit for the problem space,
especially considering our problems with trace bit propogation.  After
my last round of patches we now have the following again (as returned
from an m4_hash lookup of a symbol name):

  m4_symbol:     .--> m4_token_data:  .--> m4_token_data:
    traced: yes  |    next -----------'    next: NULL
    data --------'    type: TEXT           type: FUNC
                      module handle        module handle
                      flags (not shadow!)  flags (not shadow!)
                      union value          union value
                    

I think this gives us more leverage for the features we need:

  m4_symbol:
    bitfield: name_associated_flags (including traced bit)
    data -----.
              |
              V
  m4_symbol_data:         ,--> m4_symbol_data:
    next: ----------------'      next:  ----------------> etc
    bitfield: defn_flags         bitfield: defn_flags
    lt_dlhandle module           lt_dlhandle module
    data -----.                  data -----.
              |                            |
              V                            V
       m4_token:                    m4_token:
         enum type                    enum type
         union value                  union value


This is mainly to save passing all that empty memory around with
builtin handler calls, since the stuff in m4_data_symbol is only
relevant if the symbol was added to the table from a module.  When
reading tokens from an m4 source file, we waste time zeroing out this
memory... despite the additional dereference, I would hope to see
another marginal speedup since we spend *a lot* of time in the token
parser compared to the time spent fetching the contents of interned
symbols.  Our memory footprint should drop noticably too, I think.

This scheme allows us to implement my idea of marking traced symbols
in an interned m4_symbol structure with a NULL data field.  This would
save us the bother of tracking traced symbols separately and
performing lookups and comparisons all the time to decide whether a
symbol is being traced or not.

Out of interest, both /usr/ucb/bin/m4 and /usr/ccs/bin/m4 on Solaris
lose track of a traced symbol entirely if you undefine and the
redefine it...  I guess the semantics we want should be considered a
gnu extension that is disabled by --traditional.

Cheers,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/