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:

I already mentioned some difficulties, here are just a few more.

> Eh, that doesn't look so bad to me, if the set of opcodes and the set
> of prefixes is made available to the generic parser.  The basic
> grammar is something like
> 
> line: label
>     | label? WS (prefix WS)* opcode WS operands
>     | WS? directive operands
> 
> operands: operand
>         | operands WS? ',' WS? operand

You left out lines like "foo = 4".  You left out TI label pseudo-op
syntax: "foo: .struct ..." in which the label must be handled
differently.  You left out MIPS .loc which does not use commas between
operands.  You left out operand syntax like ', (single quote followed
by comma) which is supported by some targets but not others.  You left
out the truly dreadful ARM .symver, in which '@' starts a comment at
any time--except when it appears in the operand of .symver.  And,
repeating myself, MRI mode.

> where the sets of prefixes, opcodes, and directives are known well in
> advance - this might be a good application for perfect hashing.

The set of opcodes varies at run time, sometimes significantly as for
PPC or MIPS 32-bit mode vs. 64-bit mode.  However, it would probably
be acceptable to build a perfect hash and handle the results after
lookup.

> I would handle this by treating those as directives, which is why the
> above grammar doesn't separate the '.' from the directive.

A good thing, too, since on m88k, and MRI mode, and some m68k
variants, the '.' is optional.

> Macro handling (I mean .macro, not the built-in pseudo-opcodes that
> some architectures have) is awkward because you can override opcodes
> with macros.  Not sure what to do about that.  

Actually, that is relatively easy.  If any macros have been defined,
you have to look up the directive name in the macro hash table before
you look it up in the other hash table.  Macros don't normally appear
in compiler output, so speed is not as important here.

Again, can these issues be solved?  Yes.  Is this obviously going to
make everything better?  No.

Ian