.align behavior in gas

.align behavior in gas

[Bryan Ford]

In recent gas snapshots, it seems that for some i386 targets
(e.g. i386-mach, i386-gnu), gas interprets the .align directive
as a number of bytes; whereas for other targets (e.g. i386-linux)
it is interpreted as log2(nbytes).  Has this always been the case?
Are there any other directives that perform the same function but
have a consistent behavior?  (I looked at gas/read.c, but couldn't
find anything.)  If not, it would be very useful to have a new directive
called, say, '.balign' that always takes a number of bytes, and/or a new
directive called something like '.p2align' that always takes a power of
two.  (I don't care what it is, as long as it's consistent!)   This
should be trivial to do; just a matter of adding a new line or two
to read.c, right?

Thanks!

				Bryan
---
Bryan Ford	baford@cs.utah.edu	University of Utah, CSS
`finger baford@schirf.cs.utah.edu' for PGP key and other info.

Re: .align behavior in gas

[Ken Raeburn]

   Date: Tue, 25 Apr 95 17:16:18 MDT
   From: Bryan Ford <baford@schirf.cs.utah.edu>

   In recent gas snapshots, it seems that for some i386 targets
   (e.g. i386-mach, i386-gnu), gas interprets the .align directive
   as a number of bytes; whereas for other targets (e.g. i386-linux)
   it is interpreted as log2(nbytes).  Has this always been the case?

Yup.

   Are there any other directives that perform the same function but
   have a consistent behavior?  (I looked at gas/read.c, but couldn't

Not yet...

   find anything.)  If not, it would be very useful to have a new directive
   called, say, '.balign' that always takes a number of bytes, and/or a new
   directive called something like '.p2align' that always takes a power of
   two.  (I don't care what it is, as long as it's consistent!)   This
   should be trivial to do; just a matter of adding a new line or two
   to read.c, right?

Plus the update to the documentation...

.align behavior in gas

[Mike Meissner]

| In recent gas snapshots, it seems that for some i386 targets
| (e.g. i386-mach, i386-gnu), gas interprets the .align directive
| as a number of bytes; whereas for other targets (e.g. i386-linux)
| it is interpreted as log2(nbytes).  Has this always been the case?

Yes.  At least it was the case for i386-mach 6 years ago when we used
that version of gas for the i486 on OSF/1.  Elf assemblers
interpretted as log2 bytes.  I believe that in either case, gas is
attempting to be compatible with the native assembler.

| Are there any other directives that perform the same function but
| have a consistent behavior?  (I looked at gas/read.c, but couldn't
| find anything.)  If not, it would be very useful to have a new directive
| called, say, '.balign' that always takes a number of bytes, and/or a new
| directive called something like '.p2align' that always takes a power of
| two.  (I don't care what it is, as long as it's consistent!)   This
| should be trivial to do; just a matter of adding a new line or two
| to read.c, right?

Yep.

-- 
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com,	617-629-3016 (office),	617-629-3010 (fax)

Re: .align behavior in gas

[Bryan Ford]

>   In recent gas snapshots, it seems that for some i386 targets
>   (e.g. i386-mach, i386-gnu), gas interprets the .align directive
>   as a number of bytes; whereas for other targets (e.g. i386-linux)
>   it is interpreted as log2(nbytes).  Has this always been the case?
>
>Yup.
>
>   Are there any other directives that perform the same function but
>   have a consistent behavior?  (I looked at gas/read.c, but couldn't
>
>Not yet...
>
>   find anything.)  If not, it would be very useful to have a new directive
>   called, say, '.balign' that always takes a number of bytes, and/or a new
>   directive called something like '.p2align' that always takes a power of
>   two.  (I don't care what it is, as long as it's consistent!)   This
>   should be trivial to do; just a matter of adding a new line or two
>   to read.c, right?
>
>Plus the update to the documentation...

OK, OK, I get the point - I'll do it. :-)
(Actually, it seems the documentation was pretty badly inaccurate already.)
Here's the patch...

diff -ur old/doc/as.texinfo ./doc/as.texinfo
--- old/doc/as.texinfo	Wed Apr 26 10:09:57 1995
+++ ./doc/as.texinfo	Wed Apr 26 10:37:39 1995
@@ -2650,6 +2650,8 @@
 @end ifset
 
 * Align::                       @code{.align @var{abs-expr} , @var{abs-expr}}
+* Balign::                      @code{.balign @var{abs-expr} , @var{abs-expr}}
+* P2align::                     @code{.p2align @var{abs-expr} , @var{abs-expr}}
 * App-File::                    @code{.app-file @var{string}}
 * Ascii::                       @code{.ascii "@var{string}"}@dots{}
 * Asciz::                       @code{.asciz "@var{string}"}@dots{}
@@ -2774,17 +2776,56 @@
 @cindex @code{align} directive
 Pad the location counter (in the current subsection) to a particular
 storage boundary.  The first expression (which must be absolute) is the
+alignment required, as described below.
+The second expression (also absolute) gives the value to be stored in
+the padding bytes.  It (and the comma) may be omitted.  If it is
+omitted, the padding bytes are zero.
+
+The way the required alignment is specified varies from system to system.
+For the a29k, HPPA, m86k, m88k, w65, sparc, and i386 using ELF format,
+the first expression is the
+alignment request in bytes.  For example @samp{.align 8} advances
+the location counter until it is a multiple of 8.  If the location counter
+is already a multiple of 8, no change is needed.
+
+For other systems, including the i386 using a.out format, it is the
 number of low-order zero bits the location counter must have after
 advancement.  For example @samp{.align 3} advances the location
 counter until it a multiple of 8.  If the location counter is already a
 multiple of 8, no change is needed.
 
-@ifset HPPA
-For the HPPA, the first expression (which must be absolute) is the
-alignment request in bytes.  For example @samp{.align 8} advances
+This inconsistency is due to the different behaviors of the various
+native assemblers for these systems which GAS must emulate.
+GAS also provides @code{.balign} and @code{.p2align} directives,
+described below, which have a consistent behavior across all
+architectures (but are specific to GAS).
+
+@node Balign
+@section @code{.balign @var{abs-expr} , @var{abs-expr}}
+
+@cindex padding the location counter given number of bytes
+@cindex @code{balign} directive
+Pad the location counter (in the current subsection) to a particular
+storage boundary.  The first expression (which must be absolute) is the
+alignment request in bytes.  For example @samp{.balign 8} advances
 the location counter until it is a multiple of 8.  If the location counter
 is already a multiple of 8, no change is needed.
-@end ifset
+
+The second expression (also absolute) gives the value to be stored in
+the padding bytes.  It (and the comma) may be omitted.  If it is
+omitted, the padding bytes are zero.
+
+@node P2align
+@section @code{.p2align @var{abs-expr} , @var{abs-expr}}
+
+@cindex padding the location counter given a power of two
+@cindex @code{p2align} directive
+Pad the location counter (in the current subsection) to a particular
+storage boundary.  The first expression (which must be absolute) is the
+number of low-order zero bits the location counter must have after
+advancement.  For example @samp{.p2align 3} advances the location
+counter until it a multiple of 8.  If the location counter is already a
+multiple of 8, no change is needed.
 
 The second expression (also absolute) gives the value to be stored in
 the padding bytes.  It (and the comma) may be omitted.  If it is
diff -ur old/read.c ./read.c
--- old/read.c	Wed Apr 26 10:09:36 1995
+++ ./read.c	Wed Apr 26 10:11:13 1995
@@ -193,6 +193,8 @@
 {
   {"abort", s_abort, 0},
   {"align", s_align_ptwo, 0},
+  {"balign", s_align_bytes, 0},
+  {"p2align", s_align_ptwo, 0},
   {"ascii", stringer, 0},
   {"asciz", stringer, 1},
 /* block */

Re: .align behavior in gas

[Ken Raeburn]

I made minor changes to keep things in alphabetical order, but it's
in.  Should be available in tomorrow morning's snapshot.

Thanks.

Ken