ideas for cpplib

[Zack Weinberg]

On Tue, 13 Oct 1998 21:28:40 -0700, Per Bothner wrote:
>> I can't find this ChangeLog.  gcc 2.7.2 stops at Nov 95 and CVS only 
has
>> back to 1997 or so.
>
>Our cvs logs go back further!  This may be rather intimidating ...
>
>Sun Dec 17 06:57:02 1995  Paul Eggert  <eggert@twinsun.com>
>
>        * cccp.c: Try harder not to open or stat the same include file twice.
	[...]
>        (do_include):  Use new lookup_include and add_import.

I found it a bit later - I didn't know about the `FSFChangeLog'
files.  It is a bit intimidating but I'll try to look at the diff you
sent at some point.  (I want to get the safe_file_read stuff done
first.)


>> Current cccp does almost as badly as cpplib on glibc.  Short of 
saving
>> stat() information across compiles, I don't think anything will help 
much;
>> the problem is having to examine something like 30 directories on 
every
>> #include, most of which don't have the header it's looking for.
>
>Maybe;  when I looked into, I convinced myself (and Paul) that
>ceaning this up could make a noticable difference.  (That cccp
>is almost as badly at cpplib could mean that more cruft has crept
>into cccp.  Inany case, it implies cccp *is* faster, and better
>include file management is I believe one reason.)

Read "almost as badly" as "any difference is lost in the noise".  Of
course this is on my machine with its ridiculously slow disk.  There
certainly is a lot of cruft in the include code.

A question - is #import supposed to block that file from both future
#imports and #includes (as if you had a pragma once or a guard ifdef)
or just #import?

>> Hm.  Trouble with that is that backslash-newline can appear 
anywhere, even
>> in the middle of a token.  I thought about replacing it with an 
escape
>> that meant 'bump line number here', postponed till whitespace.  That 
would
>> be the only way to get lines and cols right in the middle of a long 
series
>> of escaped newlines.
>
>Not necessarily.  The key to getting the line and col numbers right
>is to *not mess with the input buffer*, and get line and col numbers
>directly from there.  In addition, there is a stack of other input 
buffers
>(such as those from macro expansions).  For each input buffer
>(cpp_buffer) corresponding to a file, you remember the current
>input pointer, plus the previous line beginning.  Calculating
>the column number is then just a subtraction.  At least, I think
>that is the basic idea (it's been a while since I looked at this).

Something along these lines could work.  However, I'm fairly certain
that the overhead of trying to do comments and backslash-newline at
the same time as macro and directive parsing is bad enough that it's
worth messing with the input buffer over.  I think I can keep the line
and column number info correct anyway; let me bash on it a bit more.

>> The commonest use of escaped newlines is big hairy macros.  cc1 
doesn't even
>> try to look into big hairy macros for error messages; you get the 
error on
>> the line where the macro was called.  If cpplib could fix that, that 
would
>> be nice.
>
>Probably not when using cppmain, but I think we should try to do
>better when using cpplib linked into cc1.

Definitely.

>> On a 32Mb machine (pretty common these days) running X and 2.0 
kernel,
>> things start hitting swap at around 2 megs of working set.
>
>Which should tell you that you need at least 48MB to be productive.

Getting more memory is impractical.  Besides, the swap situation with
libc is going to be horrible as long as ar and ld copy the entire
archive file when updating it.

>> Ulrich says he wants to put mmap of read-only files into stdio, and 
I'd
>> rather not worry about whether we have mmap support inside cpplib.
>
>Most of the hosts we support are not using Linux, let alone glibc.

True, but similar hacks exist in other people's stdios, and using
stdio instead of mmap or even open/read improves portability.  I think
a bit of the VMS-specific goop goes away, for example.

zw