From 3b37fd66739329ee8493b9c2abb494757802316e Mon Sep 17 00:00:00 2001 From: Kazu Hirata Date: Thu, 11 Oct 2001 12:20:25 +0000 Subject: * app.c: Fix comment typos. * bit_fix.h: Likewise. * expr.c: Likewise. * itbl-ops.c: Likewise. --- gas/expr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'gas/expr.c') diff --git a/gas/expr.c b/gas/expr.c index 499f9a3..74c49d9 100644 --- a/gas/expr.c +++ b/gas/expr.c @@ -759,7 +759,7 @@ current_location (expressionp) /* In: Input_line_pointer points to 1st char of operand, which may be a space. - Out: A expressionS. + Out: An expressionS. The operand may have been empty: in this case X_op == O_absent. Input_line_pointer->(next non-blank) char after operand. */ @@ -1342,7 +1342,7 @@ operand (expressionP) /* Internal. Simplify a struct expression for use by expr (). */ -/* In: address of a expressionS. +/* In: address of an expressionS. The X_op field of the expressionS may only take certain values. Elsewise we waste time special-case testing. Sigh. Ditto SEG_ABSENT. @@ -1399,7 +1399,7 @@ clean_up_expression (expressionP) Unary operators and parenthetical expressions are treated as operands. As usual, Q==quantity==operand, O==operator, X==expression mnemonics. - We used to do a aho/ullman shift-reduce parser, but the logic got so + We used to do an aho/ullman shift-reduce parser, but the logic got so warped that I flushed it and wrote a recursive-descent parser instead. Now things are stable, would anybody like to write a fast parser? Most expressions are either register (which does not even reach here) -- cgit v1.1