Re: ia64 gas default mode

Re: ia64 gas default mode

[Jan Beulich]

Thanks for this detailed explanation. It in parituclar also hints at why
I, within the first few hours of trying to use gas to translate assembly
sources, ran into so many (non-DV-related) problems that I didn't even
get to see many DV-related ones, yet. I hope to be able to provide
patches for most/all of them within a few days...

Nevertheless, the whole thing worries me when I'm thinking of both
using gas for translating actual assembly sources (immediately) as well
as (mid-term) getting gcc to make better use of predication (and other
hardware features). I would hope that I don't have to switch back to
using the Intel assembler, in part because it's not available as cross
assembler for Linux.

Jan

>>> James E Wilson <wilson@specifixinc.com> 20.01.05 01:05:52 >>>
On Wed, 2005-01-19 at 01:38, Jan Beulich wrote:
> c-ia64.texi says that dependency violation checking is being turned
on
> by default...

As for the docs, the IA-64 port was contributed in April 2000 without
docs.  In February 2002, David Mosberger contributed a patch to fix a
problem with some options, Nick Clifton pointed out that we were
lacking
docs, and so David threw some together as a starting point.  David got
the documentation wrong for -x at this point.  Perhaps because gcc
defaults to passing -x to the assembler?  You were the first to notice
the mistake.  See the thread that ends at
	http://sources.redhat.com/ml/binutils/2002-02/msg00826.html 
It would be trivial to correct the docs to match the source code if
that
is what you want.

As for why the DV checking support behaves strangely, this is more
complicated.  There are a number of problems here.  Two in particular
are:
1) Ideally, the assembler/compiler should have been implemented before
end users started using it.  Unfortunately, Intel started a kernel
project before they started an assembler/compiler project, so we were
forced into the position of providing something minimal that worked
for
kernel development, and then fixing it to be correct later.  This
caused
a number of problems with development, one of which was with the DV
checking support.  The original assembler had no DV checking support
at
all; this had to be added in later without breaking kernel
development,
and that constrained what we could do.
2) The DV checking support turns out to be far more complicated than
anyone thought.  What it does is very straight forward, but once you
start implementing it, you discover that there are so many special
cases
to get right that it is a nightmare to implement correctly.  The
current
gas DV checking support has serious bugs that can not be fixed.  It
needs to be ripped out and replaced with a better implementation.  I
have a plan for how to do this, but I estimate that it will take me
1-man month.  IA-64 work is a hobby for me.  This isn't something that
I
can easily do in my spare time on weekends.  And this work is probably
2-man months if done by someone else, who doesn't already have a good
understanding of all of the pitfalls.  It isn't clear when this will
get
fixed.  The only positive part of this is that the gcc predication
support is so limited that gcc isn't smart enough to generate any of
the
problematic cases that the assembler doesn't handle correctly.  So if
you don't have any asms, it will be very rare for you to see an
assembler DV problem when compiling code.  If gcc ever gets smarter,
this assembler problem will become much more serious.

So here is the situation, we have DV checking support, but it is known
to have bugs that can't be fixed.  Sometimes, it reports problems that
aren't real.  Sometimes, it fails to find problems that are real.  We
need to work around these problems some how.

One thing we do is that we emit warnings instead of errors.  Ideally,
if
we find a provable DV, then we should emit an error.  However, if we
do
emit an error, then some valid programs will fail to assemble, and
some
valid programs will fail to compile, and the user will be stuck.  So
instead we emit warnings, and if the assembler is wrong, then you can
still get object code.  If and when the DV support is fixed, these
warnings for provable DVs should be turned into errors.  Warning for
suspected but not provable DVs should remain warnings.

The other issue is what to do by default.  If we enable the DV support
by default, then that means some programs might be broken when the
assembler detects a false DV and tries to correct.  So we have three
choices here:
1) Do nothing.  Assembly programs with correct stop bits will always
work.  Assembly programs without correct stop bits will not work, and
the user won't be told anything is wrong, unless a -x option is used.
2) Enable -xauto by default.  Assembly programs with correct stop bits
will almost always work, but a few may be incorrectly assembled. 
Assembly programs without correct stop bits will almost always work,
but
a few may be incorrect assembled.
3) Enable -xexplicit by default.  Assembler programs with correct stop
bits will always work, but a few may get false DV warnings.  Assembler
programs without correct stop bits will never work, and most but not
all
will get assembler warnings.

Now the question is, which is the lesser of three evils?  I would
argue
that 3 is the least worst choice, even though it is different from the
Intel assembler default.  I don't think 2 will be a practical choice
until the gas DV checking support is fixed.

So I'd suggest that we fix the source code to match the docs here.

Another point to keep in mind that there may be assumptions in linux
kernel and/or glibc about how the assembler DV support works.  So if
we
make changes to gas, we will need to check to make sure we don't
accidentally break the linux kernel and/or glibc.  I think both
default
to using -x (-xexplicit) in ASFLAGS, so there is probably no problem
here.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com 

Re: ia64 gas default mode

[James E Wilson]

On Wed, 2005-01-19 at 23:56, Jan Beulich wrote:
> I, within the first few hours of trying to use gas to translate assembly
> sources, ran into so many (non-DV-related) problems that I didn't even
> get to see many DV-related ones, yet.

Gas works fine for glibc, linux kernel, gcc etc.  So there really
shouldn't be any serious problems other than the DV problems.  That is
the only important part left that is unfinished.  There are probably the
usual minor bugs in poorly exercised parts of the port though.

There are however a number of differences between Intel and gas syntax. 
At the beginning, we tried to be completely compatible with the Intel
syntax, as described by the documentation, but we have run into a number
of problems.

The Intel assembler did not behave as specified by the assembler and
architecture documentation in some cases, and in many such cases, we
have decided to follow the documentation.  Thus there are known cases
where stuff accepted by one assembler isn't accepted by the other.  An
example of this is ".restore sp".  The docs clearly indicate that
restore takes an argument, so gas did it this way, and we only later
learned that the Intel assembler only accepted .restore without any
argument at all.  We firmly believe that Intel got this wrong, but we
could perhaps accept both, and hope that the Intel assembler will accept
both too.  We can't just switch to the (broken) Intel syntax, as we have
too much code using the (correct) current syntax.  Likewise, Intel can't
switch syntax as it would break their assembly code.

Gas followed the syntax described in the early pre-release Intel
manuals.  Some of this syntax changed before Itanium was released, and
in some cases, gas has been slow to catch up to the changes.  This is
why for instance we have two different syntaxes for describing a mutex. 
There is the pre-release syntax and the post-release syntax.  We really
should drop the old one, but no one has tried that yet, it might be too
difficult if there are still too many people using the old syntax.

The Intel assembler has a number of interesting features that may never
be implemented in the gas port, automatic register allocation for
instance.  Intel changed the docs to state that some features were
optional, and register allocation is one of them, so we stopped worrying
about this.

There are probably some other issues.  I used to have a list of them,
but I eventually stopped caring.  There are so few people that care
about Intel/gas syntax compatibility that it wasn't worth the trouble of
trying to fix.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: ia64 gas default mode

[James E Wilson]

On Wed, 2005-01-19 at 16:05, James E Wilson wrote:
> 3) Enable -xexplicit by default.  Assembler programs with correct stop
> bits will always work, but a few may get false DV warnings.  Assembler
> programs without correct stop bits will never work, and most but not all
> will get assembler warnings.

If we do enable this or -xauto by default, we should probably also add a
-xnone or similar option to disable the DV checking code.  No one in
their right mind should disable DV checking, but it might be useful if
someone runs into a DV checking bug, and can't figure out how to work
around it except by turning off the DV checking.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: ia64 gas default mode

[James E Wilson]

On Wed, 2005-01-19 at 01:38, Jan Beulich wrote:
> c-ia64.texi says that dependency violation checking is being turned on
> by default...

As for the docs, the IA-64 port was contributed in April 2000 without
docs.  In February 2002, David Mosberger contributed a patch to fix a
problem with some options, Nick Clifton pointed out that we were lacking
docs, and so David threw some together as a starting point.  David got
the documentation wrong for -x at this point.  Perhaps because gcc
defaults to passing -x to the assembler?  You were the first to notice
the mistake.  See the thread that ends at
	http://sources.redhat.com/ml/binutils/2002-02/msg00826.html
It would be trivial to correct the docs to match the source code if that
is what you want.

As for why the DV checking support behaves strangely, this is more
complicated.  There are a number of problems here.  Two in particular
are:
1) Ideally, the assembler/compiler should have been implemented before
end users started using it.  Unfortunately, Intel started a kernel
project before they started an assembler/compiler project, so we were
forced into the position of providing something minimal that worked for
kernel development, and then fixing it to be correct later.  This caused
a number of problems with development, one of which was with the DV
checking support.  The original assembler had no DV checking support at
all; this had to be added in later without breaking kernel development,
and that constrained what we could do.
2) The DV checking support turns out to be far more complicated than
anyone thought.  What it does is very straight forward, but once you
start implementing it, you discover that there are so many special cases
to get right that it is a nightmare to implement correctly.  The current
gas DV checking support has serious bugs that can not be fixed.  It
needs to be ripped out and replaced with a better implementation.  I
have a plan for how to do this, but I estimate that it will take me
1-man month.  IA-64 work is a hobby for me.  This isn't something that I
can easily do in my spare time on weekends.  And this work is probably
2-man months if done by someone else, who doesn't already have a good
understanding of all of the pitfalls.  It isn't clear when this will get
fixed.  The only positive part of this is that the gcc predication
support is so limited that gcc isn't smart enough to generate any of the
problematic cases that the assembler doesn't handle correctly.  So if
you don't have any asms, it will be very rare for you to see an
assembler DV problem when compiling code.  If gcc ever gets smarter,
this assembler problem will become much more serious.

So here is the situation, we have DV checking support, but it is known
to have bugs that can't be fixed.  Sometimes, it reports problems that
aren't real.  Sometimes, it fails to find problems that are real.  We
need to work around these problems some how.

One thing we do is that we emit warnings instead of errors.  Ideally, if
we find a provable DV, then we should emit an error.  However, if we do
emit an error, then some valid programs will fail to assemble, and some
valid programs will fail to compile, and the user will be stuck.  So
instead we emit warnings, and if the assembler is wrong, then you can
still get object code.  If and when the DV support is fixed, these
warnings for provable DVs should be turned into errors.  Warning for
suspected but not provable DVs should remain warnings.

The other issue is what to do by default.  If we enable the DV support
by default, then that means some programs might be broken when the
assembler detects a false DV and tries to correct.  So we have three
choices here:
1) Do nothing.  Assembly programs with correct stop bits will always
work.  Assembly programs without correct stop bits will not work, and
the user won't be told anything is wrong, unless a -x option is used.
2) Enable -xauto by default.  Assembly programs with correct stop bits
will almost always work, but a few may be incorrectly assembled. 
Assembly programs without correct stop bits will almost always work, but
a few may be incorrect assembled.
3) Enable -xexplicit by default.  Assembler programs with correct stop
bits will always work, but a few may get false DV warnings.  Assembler
programs without correct stop bits will never work, and most but not all
will get assembler warnings.

Now the question is, which is the lesser of three evils?  I would argue
that 3 is the least worst choice, even though it is different from the
Intel assembler default.  I don't think 2 will be a practical choice
until the gas DV checking support is fixed.

So I'd suggest that we fix the source code to match the docs here.

Another point to keep in mind that there may be assumptions in linux
kernel and/or glibc about how the assembler DV support works.  So if we
make changes to gas, we will need to check to make sure we don't
accidentally break the linux kernel and/or glibc.  I think both default
to using -x (-xexplicit) in ASFLAGS, so there is probably no problem
here.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

ia64 gas default mode

[Jan Beulich]

c-ia64.texi says that dependency violation checking is being turned on
by default. This being different than the native (Intel) assembler
(which by default is in automatic mode) seems questionable already, but
the statement doesn't even appear to be true: Dependencies are neither
checked for nor eliminated without any -x option and none of the
.auto/.explicit directives used. Is this intentional? If so, what value
does this mode have, and what specifically is the purpose of the most
dangerous of all possible modes being the default?

Thanks, Jan