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


Ian Lance Taylor <ian@wasabisystems.com> writes:

> 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?

I'm talking about the 192 places in the GCC source code where "APP" or
"NO_APP" or other names related to emitting these strings in assembly
appear.  If it were one, I'd not be complaining.  Two or three even,
ok.  192, not cool.

(number got by running "find . -type f | grep -v CVS | grep -v ChangeLog |
xargs egrep '(\<APP\>|\<NO_APP\>|APP_ON|APP_OFF|app_on|app_off)' | wc -l" 
in a CVS checkout - yes, documentation deliberately included).

>> 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.

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.

zw


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