Agree with that - I didn't realise this would put yylex on top of
the list if byte manipulations were the real problem; my language of
choice predates automatic lexers by two decades, and I didn't
really kept up with the field after the card readers were scrapped
around here :-)
>> Now neither bytes,
>> nor the members of the various structures used in gcc internally,
>> are necessarily long- or quadwords (i.e. 32 or 64 bit quantities).
> I suppose they needn't have been but they are. Virtually
> everything done inside of gcc once things are parsed are
> with pointers and longs.
Well, I don't mean to argue this to death, but in _my_ copy of gcc,
the first two fields in the RTX structure are 16 and 8 bits wide,
followed by 7 one bit flags.
> No, the thing to do to make gcc faster is not to worry
> about the I/O, but to improve the algorithms used in the
> optimization phases.
Sure, but I hoped to pinpoint a *common* cause for the difference
between gcc on the Alpha and on the i386, given that Jim's
experiment shows that no *single* routine is responsible.
-- To unsubscribe: send e-mail to email@example.com with 'unsubscribe' as the subject. Do not send it to firstname.lastname@example.org
Copyright © 1995-1997 Red Hat Software. Legal notices