🚀 go-pugleaf

http://www.gnu.org/manual/gas-2.9.1/

The Vax version of the assembler accepts two options when compiled for VMS. 
They are `-h', and `-+'. The `-h' option prevents as from modifying the 
symbol-table entries for symbols that contain lowercase characters (I 
think). The `-+' option causes as to print warning messages if the FILENAME 
part of the object file, or any symbol name is larger than 31 characters. 
The `-+' option also inserts some code following the `_main' symbol so that 
the object file is compatible with Vax-11 "C". 

VAX Floating Point
Conversion of flonums to floating point is correct, and compatible with 
previous assemblers. Rounding is towards zero if the remainder is exactly 
half the least significant bit. 

D, F, G and H floating point formats are understood. 

Immediate floating literals (e.g. `S`$6.9') are rendered correctly. Again, 
rounding is towards zero in the boundary case. 

The .float directive produces f format numbers. The .double directive 
produces d format numbers. 

Vax Machine Directives
The Vax version of the assembler supports four directives for generating 
Vax floating point constants. They are described in the table below. 


dfloat 
This expects zero or more flonums, separated by commas, and assembles Vax d 
format 64-bit floating point constants. 
ffloat 
This expects zero or more flonums, separated by commas, and assembles Vax f 
format 32-bit floating point constants. 
gfloat 
This expects zero or more flonums, separated by commas, and assembles Vax g 
format 64-bit floating point constants. 
hfloat 
This expects zero or more flonums, separated by commas, and assembles Vax h 
format 128-bit floating point constants. 
VAX Opcodes
All DEC mnemonics are supported. Beware that case... instructions have 
exactly 3 operands. The dispatch table that follows the case... instruction 
should be made with .word statements. This is compatible with all unix 
assemblers we know of. 

VAX Branch Improvement
Certain pseudo opcodes are permitted. They are for branch instructions. 
They expand to the shortest branch instruction that reaches the target. 
Generally these mnemonics are made by substituting `j' for `b' at the start 
of a DEC mnemonic. This feature is included both for compatibility and to 
help compilers. If you do not need this feature, avoid these opcodes. Here 
are the mnemonics, and the code they can expand into. 

jbsb 
`Jsb' is already an instruction mnemonic, so we chose `jbsb'. 
(byte displacement) 
bsbb ... 
(word displacement) 
bsbw ... 
(long displacement) 
jsb ... 
jbr 
jr 
Unconditional branch. 
(byte displacement) 
brb ... 
(word displacement) 
brw ... 
(long displacement) 
jmp ... 
jCOND 
COND may be any one of the conditional branches neq, nequ, eql, eqlu, gtr, 
geq, lss, gtru, lequ, vc, vs, gequ, cc, lssu, cs. COND may also be one of 
the bit tests bs, bc, bss, bcs, bsc, bcc, bssi, bcci, lbs, lbc. NOTCOND is 
the opposite condition to COND. 
(byte displacement) 
bCOND ... 
(word displacement) 
bNOTCOND foo ; brw ... ; foo: 
(long displacement) 
bNOTCOND foo ; jmp ... ; foo: 
jacbX 
X may be one of b d f g h l w. 
(word displacement) 
OPCODE ... 
(long displacement) 
OPCODE ..., foo ;
brb bar ;
foo: jmp ... ;
bar:

jaobYYY 
YYY may be one of lss leq. 
jsobZZZ 
ZZZ may be one of geq gtr. 
(byte displacement) 
OPCODE ... 
(word displacement) 
OPCODE ..., foo ;
brb bar ;
foo: brw destination ;
bar:

(long displacement) 
OPCODE ..., foo ;
brb bar ;
foo: jmp destination ;
bar:

aobleq 
aoblss 
sobgeq 
sobgtr 
(byte displacement) 
OPCODE ... 
(word displacement) 
OPCODE ..., foo ;
brb bar ;
foo: brw destination ;
bar:

(long displacement) 
OPCODE ..., foo ;
brb bar ;
foo: jmp destination ;
bar:

VAX Operands
The immediate character is `$' for Unix compatibility, not `#' as DEC 
writes it. 

The indirect character is `*' for Unix compatibility, not `@' as DEC writes 
it. 

The displacement sizing character is ``' (an accent grave) for Unix 
compatibility, not `^' as DEC writes it. The letter preceding ``' may have 
either case. `G' is not understood, but all other letters (b i l s w) are 
understood. 

Register names understood are r0 r1 r2 ... r15 ap fp sp pc. Upper and lower 
case letters are equivalent. 

For instance 

tstb *w`$4(r5)

Any expression is permitted in an operand. Operands are comma separated. 

Not Supported on VAX
Vax bit fields can not be assembled with as. Someone can add the required 
code if they really need it. 

v850 Dependent Features

Options
as supports the following additional command-line options for the V850 
processor family: 


-wsigned_overflow 
Causes warnings to be produced when signed immediate values overflow the 
space available for then within their opcodes. By default this option is 
disabled as it is possible to receive spurious warnings due to using exact 
bit patterns as immediate constants. 
-wunsigned_overflow 
Causes warnings to be produced when unsigned immediate values overflow the 
space available for then within their opcodes. By default this option is 
disabled as it is possible to receive spurious warnings due to using exact 
bit patterns as immediate constants. 
-mv850 
Specifies that the assembled code should be marked as being targeted at the 
V850 processor. This allows the linker to detect attempts to link such code 
with code assembled for other processors. 
Syntax
Special Characters
`#' is the line comment character. 

Register Names
as supports the following names for registers: 

general register 0 
r0, zero 
general register 1 
r1 
general register 2 
r2, hp 
general register 3 
r3, sp 
general register 4 
r4, gp 
general register 5 
r5, tp 
general register 6 
r6 
general register 7 
r7 
general register 8 
r8 
general register 9 
r9 
general register 10 
r10 
general register 11 
r11 
general register 12 
r12 
general register 13 
r13 
general register 14 
r14 
general register 15 
r15 
general register 16 
r16 
general register 17 
r17 
general register 18 
r18 
general register 19 
r19 
general register 20 
r20 
general register 21 
r21 
general register 22 
r22 
general register 23 
r23 
general register 24 
r24 
general register 25 
r25 
general register 26 
r26 
general register 27 
r27 
general register 28 
r28 
general register 29 
r29 
general register 30 
r30, ep 
general register 31 
r31, lp 
system register 0 
eipc 
system register 1 
eipsw 
system register 2 
fepc 
system register 3 
fepsw 
system register 4 
ecr 
system register 5 
psw 
Floating Point
The V850 family uses IEEE floating-point numbers. 

V850 Machine Directives

offset <expression> 
Moves the offset into the current section to the specified amount. 
section "name", <type> 
This is an extension to the standard .section directive. It sets the 
current section to be <type> and creates an alias for this section called 
"name". 
v850 
Specifies that the assembled code should be marked as being targeted at the 
V850 processor. This allows the linker to detect attempts to link such code 
with code assembled for other processors. 
Opcodes
as implements all the standard V850 opcodes. 

as also implements the following pseudo ops: 

hi0() 
Computes the higher 16 bits of the given expression and stores it into the 
immediate operand field of the given instruction. For example: `mulhi 
hi0(here - there), r5, r6' computes the difference between the address of 
labels 'here' and 'there', takes the upper 16 bits of this difference, 
shifts it down 16 bits and then mutliplies it by the lower 16 bits in 
register 5, putting the result into register 6. 
lo() 
Computes the lower 16 bits of the given expression and stores it into the 
immediate operand field of the given instruction. For example: `addi 
lo(here - there), r5, r6' computes the difference between the address of 
labels 'here' and 'there', takes the lower 16 bits of this difference and 
adds it to register 5, putting the result into register 6. 
hi() 
Computes the higher 16 bits of the given expression and then adds the value 
of the most significant bit of the lower 16 bits of the expression and 
stores the result into the immediate operand field of the given 
instruction. For example the following code can be used to compute the 
address of the label 'here' and store it into register 6: `movhi hi(here), 
r0, r6' `movea lo(here), r6, r6' The reason for this special behaviour is 
that movea performs a sign extention on its immediate operand. So for 
example if the address of 'here' was 0xFFFFFFFF then without the special 
behaviour of the hi() pseudo-op the movhi instruction would put 0xFFFF0000 
into r6, then the movea instruction would takes its immediate operand, 
0xFFFF, sign extend it to 32 bits, 0xFFFFFFFF, and then add it into r6 
giving 0xFFFEFFFF which is wrong (the fifth nibble is E). With the hi() 
pseudo op adding in the top bit of the lo() pseudo op, the movhi 
instruction actually stores 0 into r6 (0xFFFF + 1 = 0x0000), so that the 
movea instruction stores 0xFFFFFFFF into r6 - the right value. 
sdaoff() 
Computes the offset of the named variable from the start of the Small Data 
Area (whoes address is held in register 4, the GP register) and stores the 
result as a 16 bit signed value in the immediate operand field of the given 
instruction. For example: `ld.w sdaoff(_a_variable)[gp],r6' loads the 
contents of the location pointed to by the label '_a_variable' into 
register 6, provided that the label is located somewhere within +/- 32K of 
the address held in the GP register. [Note the linker assumes that the GP 
register contains a fixed address set to the address of the label called 
'__gp'. This can either be set up automatically by the linker, or 
specifically set by using the `--defsym __gp=<value>' command line option]. 
tdaoff() 
Computes the offset of the named variable from the start of the Tiny Data 
Area (whoes address is held in register 30, the EP register) and stores the 
result as a 7 or 8 bit unsigned value in the immediate operand field of the 
given instruction. For example: `sld.w tdaoff(_a_variable)[ep],r6' loads 
the contents of the location pointed to by the label '_a_variable' into 
register 6, provided that the label is located somewhere within +256 bytes 
of the address held in the EP register. [Note the linker assumes that the 
EP register contains a fixed address set to the address of the label called 
'__ep'. This can either be set up automatically by the linker, or 
specifically set by using the `--defsym __ep=<value>' command line option]. 
zdaoff() 
Computes the offset of the named variable from address 0 and stores the 
result as a 16 bit signed value in the immediate operand field of the given 
instruction. For example: `movea zdaoff(_a_variable),zero,r6' puts the 
address of the label '_a_variable' into register 6, assuming that the label 
is somewhere within the first 32K of memory. (Strictly speaking it also 
possible to access the last 32K of memory as well, as the offsets are 
signed). 
For information on the V850 instruction set, see V850 Family 32-/16-Bit 
single-Chip Microcontroller Architecture Manual from NEC. Ltd. 

@raisesections 

Reporting Bugs

Your bug reports play an essential role in making as reliable. 

Reporting a bug may help you by bringing a solution to your problem, or it 
may not. But in any case the principal function of a bug report is to help 
the entire community by making the next version of as work better. Bug 
reports are your contribution to the maintenance of as. 

In order for a bug report to serve its purpose, you must include the 
information that enables us to fix the bug. 

Have you found a bug?

If you are not sure whether you have found a bug, here are some guidelines: 

If the assembler gets a fatal signal, for any input whatever, that is a as 
bug. Reliable assemblers never crash. 
If as produces an error message for valid input, that is a bug. 
If as does not produce an error message for invalid input, that is a bug. 
However, you should note that your idea of "invalid input" might be our 
idea of "an extension" or "support for traditional practice". 
If you are an experienced user of assemblers, your suggestions for 
improvement of as are welcome in any case. 
How to report bugs

A number of companies and individuals offer support for GNU products. If 
you obtained as from a support organization, we recommend you contact that 
organization first. 

You can find contact information for many support companies and individuals 
in the file `etc/SERVICE' in the GNU Emacs distribution. 

In any event, we also recommend that you send bug reports for as to 
`bug-gnu-utils@gnu.org'. 

The fundamental principle of reporting bugs usefully is this: report all 
the facts. If you are not sure whether to state a fact or leave it out, 
state it! 

Often people omit facts because they think they know what causes the 
problem and assume that some details do not matter. Thus, you might assume 
that the name of a symbol you use in an example does not matter. Well, 
probably it does not, but one cannot be sure. Perhaps the bug is a stray 
memory reference which happens to fetch from the location where that name 
is stored in memory; perhaps, if the name were different, the contents of 
that location would fool the assembler into doing the right thing despite 
the bug. Play it safe and give a specific, complete example. That is the 
easiest thing for you to do, and the most helpful. 

Keep in mind that the purpose of a bug report is to enable us to fix the 
bug if it is new to us. Therefore, always write your bug reports on the 
assumption that the bug has not been reported previously. 

Sometimes people give a few sketchy facts and ask, "Does this ring a bell?" 
Those bug reports are useless, and we urge everyone to refuse to respond to 
them except to chide the sender to report bugs properly. 

To enable us to fix the bug, you should include all these things: 

The version of as. as announces it if you start it with the `--version' 
argument. Without this, we will not know whether there is any point in 
looking for the bug in the current version of as. 
Any patches you may have applied to the as source. 
The type of machine you are using, and the operating system name and 
version number. 
What compiler (and its version) was used to compile as---e.g. "gcc-2.7". 
The command arguments you gave the assembler to assemble your example and 
observe the bug. To guarantee you will not omit something important, list 
them all. A copy of the Makefile (or the output from make) is sufficient. 
If we were to try to guess the arguments, we would probably guess wrong and 
then we might not encounter the bug. 
A complete input file that will reproduce the bug. If the bug is observed 
when the assembler is invoked via a compiler, send the assembler source, 
not the high level language source. Most compilers will produce the 
assembler source when run with the `-S' option. If you are using gcc, use 
the options `-v --save-temps'; this will save the assembler source in a 
file with an extension of `.s', and also show you exactly how as is being 
run. 
A description of what behavior you observe that you believe is incorrect. 
For example, "It gets a fatal signal." Of course, if the bug is that as 
gets a fatal signal, then we will certainly notice it. But if the bug is 
incorrect output, we might not notice unless it is glaringly wrong. You 
might as well not give us a chance to make a mistake. Even if the problem 
you experience is a fatal signal, you should still say so explicitly. 
Suppose something strange is going on, such as, your copy of as is out of 
synch, or you have encountered a bug in the C library on your system. (This 
has happened!) Your copy might crash and ours would not. If you told us to 
expect a crash, then when ours fails to crash, we would know that the bug 
was not happening for us. If you had not told us to expect a crash, then we 
would not be able to draw any conclusion from our observations. 
If you wish to suggest changes to the as source, send us context diffs, as 
generated by diff with the `-u', `-c', or `-p' option. Always send diffs 
from the old file to the new file. If you even discuss something in the as 
source, refer to it by context, not by line number. The line numbers in our 
development sources will not match those in your sources. Your line numbers 
would convey no useful information to us. 
Here are some things that are not necessary: 

A description of the envelope of the bug. Often people who encounter a bug 
spend a lot of time investigating which changes to the input file will make 
the bug go away and which changes will not affect it. This is often time 
consuming and not very useful, because the way we will find the bug is by 
running a single example under the debugger with breakpoints, not by pure 
deduction from a series of examples. We recommend that you save your time 
for something else. Of course, if you can find a simpler example to report 
instead of the original one, that is a convenience for us. Errors in the 
output will be easier to spot, running under the debugger will take less 
time, and so on. However, simplification is not vital; if you do not want 
to do this, report the bug anyway and send us the entire test case you 
used. 
A patch for the bug. A patch for the bug does help us if it is a good one. 
But do not omit the necessary information, such as the test case, on the 
assumption that a patch is all we need. We might see problems with your 
patch and decide to fix the problem another way, or we might not understand 
it at all. Sometimes with a program as complicated as as it is very hard to 
construct an example that will make the program follow a certain path 
through the code. If you do not send us the example, we will not be able to 
construct one, so we will not be able to verify that the bug is fixed. And 
if we cannot understand what bug you are trying to fix, or why your patch 
should be an improvement, we will not install it. A test case will help us 
to understand. 
A guess about what the bug is or what it depends on. Such guesses are 
usually wrong. Even we cannot guess right about such things without first 
using the debugger to find the facts. 
Acknowledgements
If you have contributed to as and your name isn't listed here, it is not 
meant as a slight. We just don't know about it. Send mail to the 
maintainer, and we'll correct the situation. Currently the maintainer is 
Ken Raeburn (email address raeburn@cygnus.com). 

Dean Elsner wrote the original GNU assembler for the VAX.(1) 

Jay Fenlason maintained GAS for a while, adding support for GDB-specific 
debug information and the 68k series machines, most of the preprocessing 
pass, and extensive changes in `messages.c', `input-file.c', `write.c'. 

K. Richard Pixley maintained GAS for a while, adding various enhancements 
and many bug fixes, including merging support for several processors, 
breaking GAS up to handle multiple object file format back ends (including 
heavy rewrite, testing, an integration of the coff and b.out back ends), 
adding configuration including heavy testing and verification of cross 
assemblers and file splits and renaming, converted GAS to strictly ANSI C 
including full prototypes, added support for m680[34]0 and cpu32, did 
considerable work on i960 including a COFF port (including considerable 
amounts of reverse engineering), a SPARC opcode file rewrite, DECstation, 
rs6000, and hp300hpux host ports, updated "know" assertions and made them 
work, much other reorganization, cleanup, and lint. 

Ken Raeburn wrote the high-level BFD interface code to replace most of the 
code in format-specific I/O modules. 

The original VMS support was contributed by David L. Kashtan. Eric 
Youngdale has done much work with it since. 

The Intel 80386 machine description was written by Eliot Dresselhaus. 

Minh Tran-Le at IntelliCorp contributed some AIX 386 support. 

The Motorola 88k machine description was contributed by Devon Bowen of 
Buffalo University and Torbjorn Granlund of the Swedish Institute of 
Computer Science. 

Keith Knowles at the Open Software Foundation wrote the original MIPS back 
end (`tc-mips.c', `tc-mips.h'), and contributed Rose format support (which 
hasn't been merged in yet). Ralph Campbell worked with the MIPS code to 
support a.out format. 

Support for the Zilog Z8k and Hitachi H8/300 and H8/500 processors (tc-z8k, 
tc-h8300, tc-h8500), and IEEE 695 object file format (obj-ieee), was 
written by Steve Chamberlain of Cygnus Support. Steve also modified the 
COFF back end to use BFD for some low-level operations, for use with the 
H8/300 and AMD 29k targets. 

John Gilmore built the AMD 29000 support, added .include support, and 
simplified the configuration of which versions accept which directives. He 
updated the 68k machine description so that Motorola's opcodes always 
produced fixed-size instructions (e.g. jsr), while synthetic instructions 
remained shrinkable (jbsr). John fixed many bugs, including true tested 
cross-compilation support, and one bug in relaxation that took a week and 
required the proverbial one-bit fix. 

Ian Lance Taylor of Cygnus Support merged the Motorola and MIT syntax for 
the 68k, completed support for some COFF targets (68k, i386 SVR3, and SCO 
Unix), added support for MIPS ECOFF and ELF targets, wrote the initial 
RS/6000 and PowerPC assembler, and made a few other minor patches. 

Steve Chamberlain made as able to generate listings. 

Hewlett-Packard contributed support for the HP9000/300. 

Jeff Law wrote GAS and BFD support for the native HPPA object format (SOM) 
along with a fairly extensive HPPA testsuite (for both SOM and ELF object 
formats). This work was supported by both the Center for Software Science 
at the University of Utah and Cygnus Support. 

Support for ELF format files has been worked on by Mark Eichin of Cygnus 
Support (original, incomplete implementation for SPARC), Pete Hoogenboom 
and Jeff Law at the University of Utah (HPPA mainly), Michael Meissner of 
the Open Software Foundation (i386 mainly), and Ken Raeburn of Cygnus 
Support (sparc, and some initial 64-bit support). 

Richard Henderson rewrote the Alpha assembler. Klaus Kaempf wrote GAS and 
BFD support for openVMS/Alpha. 

Several engineers at Cygnus Support have also provided many small bug fixes 
and configuration enhancements. 

Many others have contributed large or small bugfixes and enhancements. If 
you have contributed significant work and are not mentioned on this list, 
and want to be, let us know. Some of the history has been lost; we are not 
intentionally leaving anyone out. 

 
--
�� ��Դ:��UNIX��� apue.dhs.org��[FROM: 211.69.197.129]