This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: demand_empty_rest_of_line and ignore_rest_of_line


Zack Weinberg <zack@codesourcery.com> writes:

> Uh, when I said "collapse the parsing logic together" I meant "think
> of a way to get rid of the machine-dependent parsers to the maximum
> extent possible."  While thinking very carefully about how to make the
> parser go blazingly fast *without* special tricks.  I'm quite
> confident this is possible.  Assembly syntax - with or without extra
> added whitespace - is not complicated, nor does it vary that much
> across architectures supported by GAS.

That turns out to be an oversimplification.  Consider i386 prefixes,
as Alan mentioned.  Consider the d10v, for which the assembler
programmer (or the compiler) may specify packing orderings between two
instructions written on the same line.  Consider m68k operand syntax,
which is sufficiently complex that we wrote a bison parser to handle
it.  Let's not even discuss MRI compatibility mode.  Remember that
while the assembler normally handles compiler output, it must also
handle hand-written assembler code which is much more free in how
operands and expressions are used.  Look at the current complexity of
do_scrub_chars() today, when it doesn't have to worry about many of
the details handled by the machine dependent parsers.

Can these issues be solved?  Yes, of course they can.  Would the
resulting parser be maintainable and blazingly fast?  I very much
doubt that both could be achieved simultaneously.  Even if were
achieved, would it still be faster to use some equivalent of #NO_APP
mode?  Almost certainly.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]