Home Original page

open ia64 issues

Jan Beulich JBeulich@novell.com
Mon Feb 14 12:42:00 GMT 2005 
Jim,

assuming the remaining pending patches get either accepted or rejected
for an understandable (to me) reason, and beyond the .xdata issue
mentioned in an earlier mail today and the pc-relative one talked about
before (for which I'm in the process of creating a fix), I currently see
two open issues, addressing of which however seems to be more intrusive
so I'd like to check whether there are objections to fix these prior to
starting to work on them:

(1) While the just approved and commited 'pound' patch makes the
situation with handling # suffixes better, things are still fairly
broken. According to the specification, # is an operator, not part of
the symbol name. This means ias (a) doesn't accept two of them in a row
(and I believe this is the correct behavior), (b) there is a strict
separation that it may (must) appear in symbols used as operands (of
opcodes or directives), but not in labels. The latter also implies that
you cannot use un-suffixed reserved symbols in directives (i.e. .global
@pause ought to be invalid).
Fixing this requires that no directive ever tries to parse an operand
which may/must be a symbol by using get_symbol_end; instead, this must
always be parsed as an expression (to allow the tc-ia64 routines to
filter out reserved symbols and deal with the # suffix). Consequently, a
lot of common code will need to be changed.

(2) In order to allow the creation of instruction-like macros (i.e. to
account for the lack of quite a number of pseudo ops in the Intel
language spec, but also to hide things like replacing zxt4 with the more
efficient addp4) it would be necessary to weaken the rejection of
'orphan' qualifying predicates: Currently, as soon as the next input
line is seen, any unused qp gets a diagnostic (and gets cleared out).
Obviously, if you place a (qp) in front of a macro invocation, it thus
won't apply to the instruction(s) resulting from the macro expansion.
The change I have in mind is to make the diagnostic/clearing dependent
upon macro nesting depth; of course, if a macro expansion itself uses
any (qp), then the macro invocation cannot be predicated (this should be
simple to catch).

Jan
More information about the Binutils mailing list