Re: demand_empty_rest_of_line and ignore_rest_of_line

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

kaih@khms.westfalen.de (Kai Henningsen) writes:

> ian@wasabisystems.com (Ian Lance Taylor)  wrote on 26.04.04 in <m3wu42am0e.fsf@gossamer.airs.com>:
> 
> > 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.
> 
> Has anyone tried including the effects of do_scrub_chars() into that state  
> machine? It certainly sounds as if that ought to be entirely possible  
> _and_ fast. Whereas the current two-pass logic sounds rather slow.

I guess I was unclear.  do_scrub_chars() is the state machine.

The parsing is indeed two pass.  All the input (other than #NO_APP
code) is first run through the do_scrub_chars() state machine.  The
general parsing code then looks at the parsed input.

Basically the general parsing code in read_a_source_file() requests a
buffer from input_scrub_next_buffer().  That function calls
input_file_give_next_buffer() to read data.  That function calls
either fread() or do_scrub_chars(), depending upon whether #NO_APP is
in effect.  If do_scrub_chars() is called, it calls fread(), scrubs
it, and returns the resulting buffer.  input_scrub_next_buffer() only
returns complete lines.  The general parsing code parses all the
information in the buffer, then requests another buffer.  And so
forth.  This is all made more complex by handling macros and include
files.  The general parsing code then checks for a pseudo-op
(generally, a leading '.' indicates a pseudo-op) and handles
pseudo-ops in a more or less machine independent fashion.  Anything
else is passed to the machine dependent parser.

The code could certainly be cleaned up, as is true of most of gas.
But I don't see anything wrong with the underlying logic.

Ian