bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU/Linux on DEC Alpha: gas assembler woes


From: Nelson H. F. Beebe
Subject: GNU/Linux on DEC Alpha: gas assembler woes
Date: Fri, 11 May 2001 09:59:14 -0600 (MDT)

Earlier this week, we installed GNU/Linux 2.2.19-6.2.1 (Red Hat 6.2)
on an old (purchased July 1995) DEC Alpha Alphastation 200 4/100 (100
MHz Alpha 21064 EV4 CPU) workstation, in order to have a GNU/Linux
Alpha development platform for software testing.

I've successfully built, validated, and installed several large
GNUware packages on it, including

        emacs-21.0.103
        fileutils-4.1
        gawk-3.0.97
        gcc (2.95.3 and 3.0 (20010507 snapshot))
        sh-utils-2.0
        textutils-2.0.14

The O/S distribution came with egcs-2.91.66 as the default gcc
installation, but I've done most builds with gcc-2.95.3.

I've been working on porting the AT&T/Princeton lcc C compiler to this
platform, based on work I've done over the last two months in
autoconfigurizing lcc, and porting it to several new platforms.  The
last snapshot of that work is available at

        ftp://ftp.math.utah.edu/pub/lcc/lcc-4.1.beta.8.tar.gz
        http://www.math.utah.edu/pub/lcc/lcc-4.1.beta.8.tar.gz

lcc works just fine on DEC Alpha OSF/1, but alas, the port to
GNU/Linux on the Alpha has not yet been successful, because of what I
believe are either bugs, or misfeatures, in GNU gas.  They are present
in both the default version (/usr/bin/as: GNU assembler 2.9.5), and
the latest one from binutils-2.10.1 (/usr/local/bin/as: GNU assembler
2.10.1), released on 25-Nov-2000, and built and installed here this
morning.

For reference, I've downloaded and printed the Digital UNIX Assembly
Language Programmer's Guide, Order number AA-PS31D-TE, March 1996),
from

        
http://www.tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTATION/V40E_PDF/APS31DTE.PDF

I also have eleven PDF files on the Alpha from

        http://gatekeeper.dec.com/pub/Digital/info/semiconductor/literature/

and I have these three Alpha architecture books:

@String{pub-DP                  = "Digital Press"}
@String{pub-DP:adr              = "12 Crosby Drive, Bedford, MA 01730, USA"}

@Book{Bhandarkar:1996:AIA,
  author =       "Dileep P. Bhandarkar",
  title =        "{Alpha} implementations and architecture: complete
                 reference and guide",
  publisher =    pub-DP,
  address =      pub-DP:adr,
  pages =        "xviii + 328",
  year =         "1996",
  ISBN =         "1-55558-130-7",
  LCCN =         "QA76.8.A176B47 1996",
  bibdate =      "Thu Aug 07 13:42:54 1997",
  price =        "US\$41.95",
  acknowledgement = ack-nhfb,
}

@Book{DEC:AAH92,
  author =       "Digital Equipment Corporation",
  title =        "Alpha Architecture Handbook",
  publisher =    pub-DP,
  address =      pub-DP:adr,
  year =         "1992",
  bibdate =      "Mon Jan 18 15:08:40 1993",
}

@Book{Sites:1995:AAA,
  author =       "Richard L. Sites and Richard L. Witek",
  title =        "{Alpha AXP} architecture reference manual",
  publisher =    pub-DP,
  address =      pub-DP:adr,
  edition =      "Second",
  pages =        "various",
  year =         "1995",
  ISBN =         "1-55558-145-5",
  LCCN =         "QA76.9.A73A46 1995",
  bibdate =      "Thu Aug 07 13:41:17 1997",
  price =        "US\$52.95",
  acknowledgement = ack-nhfb,
}

First, there are gratuitous changes in assembly file syntax in
GNU/Linux compared to DEC OSF/1; these were easy to handle by changing
the lcc code generator like this:

#if defined(__linux)
        case DATA: print(".section .sdata,\"aw\"\n"); break;
        case CODE: print(".text\n");  break;
        case LIT:  print(".section .rodata\n"); break;
#else
        case DATA: print(".sdata\n"); break;
        case CODE: print(".text\n");  break;
        case LIT:  print(".rdata\n"); break;
#endif

I also had to change all instances of code operands of the form
"reg1,(reg2)" to ""reg1,0(reg2)".  This is another gratuitous
limitation of gas.

However, I still get numerous fatal assembly errors from both versions
of gas, from code that the OSF/1 assembler (/usr/ccs/bin/as (Digital
UNIX Compiler Driver 3.11)) happily accepts, and which, from the
assembly language descriptions in the books, ought to be acceptable.
I've distilled them down to this simple file:

        % cat foo.s
                .globl main
                .text
                .ent main
        main:
                addl $27,0x80000000,$27
                divq $25,4,$25
                and $25,0xffffffc7,$25
                lds $f28,28($14)
                reml $14,10,$27
                addq $1,-8,$1
                subl $14,1001,$27
                subl $14,-1,$27
                ret
                .end main

The instructions are pulled from much larger .a files, totaling over
44K lines from the lcc validation suite.  All of them assemble just
fine with the OSF/1 assembler, once this filter has been applied:

        sed -e 's/.section .rodata/.rdata/' -e 's/.section .sdata,"aw"/.sdata/'

The code in the foo.s test file does not correspond to any usable
program.

The OSF/1 assembler handles this file without complaint, but gas
produces these errors:

        % /usr/bin/as foo.s
        foo.s: Assembler messages:
        foo.s:5: Warning: operand out of range (2147483648 not between 0 and 
255)
        foo.s:6: Error: inappropriate arguments for opcode `divq'
        foo.s:7: Warning: operand out of range (4294967239 not between 0 and 
255)
        foo.s:8: Warning: Used $at without ".set noat"
        foo.s:9: Error: inappropriate arguments for opcode `reml'
        foo.s:10: Warning: operand out of range (-8 not between 0 and 255)
        foo.s:11: Warning: operand out of range (1001 not between 0 and 255)
        foo.s:12: Warning: operand out of range (-1 not between 0 and 255)

        % /usr/local/bin/as foo.s
        foo.s: Assembler messages:
        foo.s:5: Warning: operand out of range (2147483648 not between 0 and 
255)
        foo.s:6: Error: inappropriate arguments for opcode `divq'
        foo.s:7: Warning: operand out of range (4294967239 not between 0 and 
255)
        foo.s:9: Error: inappropriate arguments for opcode `reml'
        foo.s:10: Warning: operand out of range (-8 not between 0 and 255)
        foo.s:11: Warning: operand out of range (1001 not between 0 and 255)
        foo.s:12: Warning: operand out of range (-1 not between 0 and 255)

The Alpha architecture has a few reserved general registers:

        $28 == $at      assembler macro expansion scratch register
        $29 == $gp      global pointer
        $30 == $sp      spack pointer
        $31             hardwired zero

However, the floating-point register $f0 .. $f30 have no restriction,
and the highest, $f31, is hardwired to zero, like $31.

The error diagnosed at line 8 "Use $at..." is evidently a bug caused
by confusion between general and floating-point registers ($f28 is NOT
$at), and appears to have been fixed in the more recent gas version.

However, the remaining warnings, and fatal error in the divq and reml
instructions, prevent continuing the porting work of lcc to this
platform.

This is frustating, because I've been able to compile a few small
programs with lcc, and demonstrate that they work just fine.
Unfortunately, I know of no other source for an assembler for
GNU/Linux than gas.

I'll be happy to work with the GNU gas maintainers to resolve these
problems, and if needed, can even provide a guest login account.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 585 1640, +1 801 581 4148 -
- University of Utah                    Internet e-mail: address@hidden  -
- Department of Mathematics, 322 INSCC      address@hidden  address@hidden -
- 155 S 1400 E RM 233                       address@hidden                    -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]