Re: open ia64 issues

Re: open ia64 issues

[Jan Beulich]

>There has been a bit of talk about making a branch for the binutils-2.16
>release.  If we know that we need an intrusive change, it should
>probably wait until after the branch is made.  That would give us
>roughly a year to work out problems before it appears in an official
>release.  It would also avoid unnecessary delays with the binutils-2.16
>release.  There might be an issue if HJ tries to create a release from a
>snapshot of mainline, but that would be HJ's problem.

OK, then I'll put this on my mid-term todo list. Once the branch is done (and I have time), I'll see how invasive the change would be.

>> 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).
>
>I don't see how this follows from what you said.  However, in the
>section on name spaces, it says that a symbol can not occur more than
>once in any name space, and in the section on symbols, it says things
>like @pause are reserved symbols.  That means that both .global @pause
>and .global @pause# should be invalid.

That's at least not the way ias seems to behave; I don't think separating register and symbol name spaces makes a lot of sense, and from ias behavior it doesn't seem like they do it.

>If we do have to change how directives work, then we could always add
>them to md_pseudo_table in tc-ia64.c to avoid changing common code. 
>This might create long term maintenance problems though, as then
>tc-ia64.c would have to change every time the list of supported
>directives changed, which would be a hassle.  Not clear if this is a
>better solution.

I was specifically intending to avoid this, for exactly these foreseeable maintenance problems.

>It isn't clear why we can't just change ia64_canonicalize_symbol_name to
>reject reserved symbol names.  That seems like a simpler solution, and
>no less efficient.  Hmm, the new @mutex, @clear, and @imply reserved
>names probably need to be put into the pseudo_func array to make this
>work.  The rest of the @ reserved words should already be in there.

It could reject reserved symbols, but as I said above that's not how ias appears to behave; instead the # operator seems to be taken as an escape from the reserved set of symbols (not from the register name space, since otherwise you had no way to refer to registers defined through .rotX and colliding with predefined register names; see the pound testcase, which works fine with ias).
However, the current way ia64_canonicalize_symbol_name gets used is improper for another reason, which I tried to point to before., but perhaps wasn't clear enough: This gets called (a) perhaps multiple times on a symbol and (b) regardless of whether the symbol appeared as an operand or a label.

>The asm language manual does allow newline white space in between a qp
>and an instruction mnemonic, so this is something we should accept.

Right. But it doesn't know about macros, so the effect of a (qp) followed by a macro invocation can't be defined there. We need to try to make the most sense of it. What I'd like to see is that the (qp) applies to all instructions generated by the macro (provided the expansion contains nothing disallowing the (continued) use of a (qp), like as you point out a label, tag, or stop, and of course no other (qp); I'm not sure whether directives should generally be excluded here, I would think only those that can alter the current location should be * exclusion of conditionals would be especially bad).

Jan

Re: open ia64 issues

[James E Wilson]

On Tue, 2005-02-15 at 00:51, Jan Beulich wrote:
> OK, then I'll put this on my mid-term todo list.

You could always document bugs by filing them into bugzilla.  Though
realistically, if you aren't fixing these problems yourself, you will
have a long wait before anyone else does.

> It could reject reserved symbols, but as I said above that's not how ias appears to behave;

So that's another case where IAS doesn't follow its own documentation,
sigh.

> What I'd like to see is that the (qp) applies to all instructions generated by the macro

That sounds like an odd definition to me.  I'd expect macros to just be
a text to text translation, not something that has special side effects
such as treating the (qp) differently than normal.  I can see how this
would be useful, but I can also see how this might confuse end users. 
This would have to be well documented as an exception to normal macro
processing.

Another matter to consider here is the -am option, which includes macro
expansions in the listing file.  If we are treating (qp) specially with
macros, then we will also have to update this code, otherwise the
listing files will be wrong with -am.  This may require some hackery in
the macro processing code, which is probably not desirable.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: open ia64 issues

[H. J. Lu]

On Mon, Feb 14, 2005 at 05:25:48PM -0800, James E Wilson wrote:

> probably wait until after the branch is made.  That would give us
> roughly a year to work out problems before it appears in an official
> release.  It would also avoid unnecessary delays with the binutils-2.16
> release.  There might be an issue if HJ tries to create a release from a
> snapshot of mainline, but that would be HJ's problem.
> 

I can deal with that. I am preparing a new Linux binutils branched
from 2.15.94.0.2 now since the mainline isn't very stable for me.


H.J.

Re: open ia64 issues

[James E Wilson]

On Mon, 2005-02-14 at 01:37, Jan Beulich wrote:
> 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:

There has been a bit of talk about making a branch for the binutils-2.16
release.  If we know that we need an intrusive change, it should
probably wait until after the branch is made.  That would give us
roughly a year to work out problems before it appears in an official
release.  It would also avoid unnecessary delays with the binutils-2.16
release.  There might be an issue if HJ tries to create a release from a
snapshot of mainline, but that would be HJ's problem.

> 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).

I don't see how this follows from what you said.  However, in the
section on name spaces, it says that a symbol can not occur more than
once in any name space, and in the section on symbols, it says things
like @pause are reserved symbols.  That means that both .global @pause
and .global @pause# should be invalid.

If we do have to change how directives work, then we could always add
them to md_pseudo_table in tc-ia64.c to avoid changing common code. 
This might create long term maintenance problems though, as then
tc-ia64.c would have to change every time the list of supported
directives changed, which would be a hassle.  Not clear if this is a
better solution.

It isn't clear why we can't just change ia64_canonicalize_symbol_name to
reject reserved symbol names.  That seems like a simpler solution, and
no less efficient.  Hmm, the new @mutex, @clear, and @imply reserved
names probably need to be put into the pseudo_func array to make this
work.  The rest of the @ reserved words should already be in there.

I agree that accepting more than one # operator is invalid.  I doubt
that anyone is relying on this gas behaviour.

If we really do need invasive changes to get this right, it isn't clear
whether it is worth the trouble.  

> efficient addp4) it would be necessary to weaken the rejection of
> 'orphan' qualifying predicates:

The asm language manual does allow newline white space in between a qp
and an instruction mnemonic, so this is something we should accept.

The issue here is making sure that we don't accept something like
	(p1)
label:
	mov r1 = r2
If anything other than an instruction mnemonic follows a qp, then we
have to reject it.  Unfortunately, labels get parsed in machine
independent code, so there is no obvious easy way to give an error for
this case.  It was just easier to handle this by giving an error if we
still have an unused qp at the beginning of a line.

There are also some parsing difficulty with the ;; stop bit and tags,
but since we use tricks to handle them in the tc-ia64.c file, we should
be able to give errors for them easily.  So
	(p1)
	;;
needs an error check which is trivial, and we already give an error for
	(p1)
	[debug:]

We also need to worry about directives here.
	(p1)
	.directive
should be an error also.  That one is probably just as tricky as getting
the label case right.

This stuff is probably easy for IAS as their asm parser understands the
form of IA-64 assembly code, whereas our target independent parser
doesn't.  Maybe some hooks can be added to the parser to support the
IA-64 specific tags and qps?

Now that you made me think about this, I remembered that we handle tags
wrong also.  A tag is only legal as part of an instruction statement,
which means all of the above examples are also invalid if you replace
the qp with a tag, but we don't warn for any of them.  Fixing gcc to
place the tags in the proper place will be a bit of work, which means we
probably can't fix this part of gas anytime soon.  This came up recently
on the gcc list.  That was even a thread that you started.
	http://gcc.gnu.org/ml/gcc/2005-01/msg01398.html
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

open ia64 issues

[Jan Beulich]

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