From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19859 invoked by alias); 26 Apr 2004 19:42:25 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 19852 invoked from network); 26 Apr 2004 19:42:23 -0000 Received: from unknown (HELO yosemite.airs.com) (209.128.65.135) by sources.redhat.com with SMTP; 26 Apr 2004 19:42:23 -0000 Received: (qmail 19398 invoked by uid 10); 26 Apr 2004 19:42:22 -0000 Received: (qmail 20706 invoked by uid 500); 26 Apr 2004 19:42:12 -0000 Mail-Followup-To: binutils@sources.redhat.com, kaih@khms.westfalen.de From: Ian Lance Taylor To: kaih@khms.westfalen.de (Kai Henningsen) Cc: binutils@sources.redhat.com Subject: Re: demand_empty_rest_of_line and ignore_rest_of_line References: <40587E7B.10705@codesourcery.com> <87u0z78ni8.fsf@egil.codesourcery.com> <87u0z78ni8.fsf@egil.codesourcery.com> <97crFbBHw-B@khms.westfalen.de> Date: Mon, 26 Apr 2004 19:45:00 -0000 In-Reply-To: <97crFbBHw-B@khms.westfalen.de> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-04/txt/msg00701.txt.bz2 kaih@khms.westfalen.de (Kai Henningsen) writes: > ian@wasabisystems.com (Ian Lance Taylor) wrote on 26.04.04 in : > > > 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