Re: demand_empty_rest_of_line and ignore_rest_of_line

[Ian Lance Taylor <ian at wasabisystems dot com>]

Zack Weinberg <zack@codesourcery.com> writes:

> The conversation so far was mainly about the appearance of the
> generated assembly, which I agree is minor, but I have another
> reason for not liking #NO_APP, which is that it adds a nontrivial
> amount of complexity to GCC's assembly output logic.  I would like
> if we could make it all just go away.

It does add complexity where we want -fverbose-asm support.  Other
than that, as far as I can see, it does not.  Is that the nontrivial
complexity that you are talking about?

> > For that matter, this patch to gas would accept your example input in
> > #NO_APP mode.
> 
> This is the sort of thing I was thinking about when I said 'let's
> spend time making GAS go faster instead' -- although, if I were in
> charge of doing that, I'd try to collapse as much of the parsing logic
> together as possible, rather than tweaking all the tc-* parsers.

Well, the assembler parsing logic is already completely collapsed
together.  It is all done in gas/app.c, using a state machine that
operates on buffers.  (It turns out that there are a number of machine
dependencies for assembler parsing, but they are still all handled in
one place.)  The output of do_scrub_chars() in gas/app.c is what the
machine dependent parsers work with.

The idea behind #NO_APP is that the assembler input is precisely that
which is generated by do_scrub_chars().  Thus, in #NO_APP mode,
do_scrub_chars() is not called at all.  do_scrub_chars() will reliably
convert sequences of whitespace to a single space, which is why the
i386 assembler can reliably use is_space_char() to skip whitespace,
and that is why #NO_APP code is expected to use a single space
character.

My patch to config/tc-i386.c was to tweak what the i386 assembler will
accept so that it would take the tab characters you wanted.  I agree
that this approach is not particularly useful.


The general #NO_APP approach makes a great deal of sense to me.  99%
of the time the assembler code generated by the compiler is read only
by the assembler.  Given that, it is already kind of silly that the
compiler has to go to a lot of effort to generate a text file.  The
assembler has to spend time doing parsing and hash table lookups to
recreate information which the compiler already has.

Given that we are going to stick with a text file to communicate
between the compiler and the assembler, it makes sense to me to
eliminate parsing in the assembler as much as possible.  We have text
generated by one program and read by another program; parsing is
useless overhead.  That is the idea behind #NO_APP.

Naturally an even more efficient process would be to link the compiler
and the assembler together into one process, or to use a binary
communication format which does not require parsing.  (The latter is
what the MIPS compiler from MIPS used to do, and perhaps still does.)
However, both of those would require a great deal more engineering
effort than #NO_APP.

Ian