Developing
for the VR4100, VR4300,
and VR5xxx
processors
The following documentation
details the V
R4100,
V
R4300,
and V
R5
xxx
processors.
Developing
for the VR4100
processors
The following documentation
describes developing with the V
R4100
MIPS processors.
The following documentation
can serve as additional resource for working with the V
R4100
processors.
-
DDB-VR4100
Evaluation Board
(NEC document #U11852EU1V0UM00, September 1996)
-
VR4100 MIPS Microprocessor User's Manual
(MIPS Technologies, Inc., 1995)
-
MIPS R4000 User's Manual
(Joseph Heinrich, Prentice-Hall, 1993, ISBN 0-13-105925-4)
-
MIPS RISC Architecture
(Gerry Kane & Joe Heinrich, Prentice-Hall, 1992, ISBN 0-13-590472-2)
-
Address Allocation for Private Internets,
RFC
1918
(de Groot, G. J. and Lear, E., February 1996)
-
System V Application Binary Interface
(Prentice-Hall, 1991, ISBN 0-13-880170-3)
-
System V Application Binary Interface
MIPS Processor Supplement
(Prentice-Hall, 1991, ISBN 0-13-880170-3)
Compiler features
for VR4100
processors
For
a list of available generic compiler options, see GNU
CC command options and Option
summary for GCC in Using
GNU CC in GNUPro Compiler Tools. In addition, the following
VR4100-specific
command-line options are supported.
Compile code for the processor in little endian mode.
Compile code for the processor in big-endian mode.
Preprocessor symbols for VR4100
processors
See
Preprocessors
symbols and their definitions for VR4100
processors for
preprocessors
symbols and their definitions with the GNU compiler options.
Preprocessors
symbols and their definitions for VR4100
processors
|
Compiler options which
define the symbol
|
|
Only if `-ansi'
not used.
|
|
Only if `-ansi'
not used.
|
|
|
|
|
|
Only if `-ansi'
and `-EL' are not used.
|
|
Only if `-EL'
is not used.
|
|
Only if `-EL'
is not used.
|
|
Only if `-EL'
is not used.
|
|
Only if `-ansi'
not used.
|
|
|
|
Only if `-ansi'
is not used and `-EL' is used.
|
|
|
|
|
|
|
note:
If neither `-EL'
or `-EB' are defined, big-endian is the default.
ABI
summary for VR4100
processors
The following documentation
discusses the
Application Binary Interface (
ABI)
issues for the VR4100 processors.
GNUPro Toolkit for the
MIPS16 does not comply with the proposed MIPS Embedded Application Binary
Interface (EABI) because that EABI has not yet been finalized.
Data
types and alignment for VR4100
processors
See Data
type sizes and alignments for VR4100
processors for the data type sizes and alignments for
VR4100
processors.
Data type
sizes and alignments for VR4100
processors
Register
allocation for VR4100
processors
See for
register
allocation for the
VR4100
processors.
Register
allocation for the VR4100
processors
General purpose
(integer) register
|
|
|
|
|
$1 through $15
, $24 , $25
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
note:
Do not depend on this order.
Instead, use GCC's `asm( )' extension and allow the compiler
to schedule registers.
The
stack frame for VR4100
processors
The stack frame specifics
for the VR4100
processors have the following guidelines. See
Stack frame guidelines for the VR4100
processors for stack frame specifics for the VR4100
processors.
-
The stack grows downwards from high addresses
to low addresses.
-
A leaf function need not allocate a stack frame
if it does not need one.
-
A frame pointer need not be allocated.
-
The stack pointer shall always be aligned to
8 byte boundaries.
Argument passing for VR4100
processors
The compiler passes
arguments
to a function using a combination of integer general registers, and the
stack. The number, type, and relative position of arguments in the calling
functions argument list define the combination of registers and memory
used. The general registers `
$4..$7' pass the first few arguments.
If the function being called
returns a structure or union, the calling function passes the address of
an area large enough to hold the structure to the function in `$4'.
The function being called copies the returned structure into this area
before returning. The address in `$4' becomes the first
argument to the function for the purpose of argument register allocation.
All user arguments are then shifted down by one.
The compiler always allocates
space on the stack for all arguments even when some or all of the arguments
to a function are passed in registers. This stack space is a large enough
structure to contain all the arguments. After promotion and structure return
pointer insertion, the arguments are aligned according to normal structure
rules. Locations used for arguments within the stack frame are referred
to as the home locations.
Floating point numbers are
handled the same way as integers of equivalent size.
The compiler passes structures
and unions as if they were very wide integers with their size rounded up
to an integral number of words. The "fill bits" necessary for rounding
up are undefined. A structure can be split so that a portion is passed
in registers and the remainder passed on the stack. In this case, the first
words are passed in `$4', `$5', `$6',
and `$7' as needed, with additional words passed on the
stack.
The rules for assigning which
arguments go into registers and which arguments must be passed on the stack
can be explained by considering the list of arguments itself as a structure,
aligned according to normal structure rules. Mapping of this structure
into the combination of registers and stack is as follows: the first four
words go into the integer registers $4..$7; everything
else with a structure offset greater than or equal to 16 is passed on the
stack.
Function return values for VR4100
processors
A function can return "no
value", an integral or pointer value, a floating-point value (single or
double precision), or a structure; unions are treated the same as structures.
A function that returns
no value puts no particular value in any register.
A function that returns
an integral, a pointer value, or a floating-point value places its result
in register `$2'.
The caller to a function
that returns a structure or a union passes the address of an area large
enough to hold the structure in register `$4'. The function
returns a pointer to the returned structure in register `$2'.
Assembler
features for VR4100
processors
For a list of available
generic assembler options, see Command-line
options in Using
as
in
GNUPro Utilities.
Any MIPS configuration of the assembler can select big-endian
or little-endian output at run time.
Use `-EB'
to select big-endian output, and `-EL' for little-endian.
The default is big-endian.
For information about the
MIPS instruction set, see MIPS RISC Architecture (Kane
and Heindrich, Prentice-Hall). For an overview of MIPS assembly conventions,
see "Appendix D: Assembly Language Programming" in MIPS RISC Architecture.
There are 32 64-bit general
(integer) registers, named `$0 ' through `
$31'.
For specific assembler mnemonics,
see MIPS RISC Architecture or MIPS R4000 User's
Manual.
Linker
issues for VR4100
processors
For a list of available
generic linker options, see Linker
scripts in Using
ld
in
GNUPro Utilities. In addition, the following VR4100-specific
command-line options are supported.
Link objects for the processor in little endian mode.
Link objects for the processor in big-endian mode.
Linker
script for VR4100
processors
The GNU linker uses a linker
script to determine how to process each section in an object file, and
how to lay out the executable. The linker script is a declarative program
consisting of a number of directives. For instance, the ENTRY(
) directive specifies which symbol in the executable will be designated
the executable's entry point. Since linker scripts can be complicated to
write, the linker includes one built-in script that defines the default
linking process.
The following `pmon.ld'
linker script should be used when linking programs for the NEC DDB- VR4100
board. It can also be used to link programs for execution in the MIPS simulator.
/*
The following TEXT start address leaves space for the monitor workspace.
*/
ENTRY(_start)
OUTPUT_ARCH("mips:4000")
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-littlemips")
GROUP(-lc -lpmon -lgcc)
SEARCH_DIR(.)
__DYNAMIC = 0;
/* Allocate the stack to be at the top of memory, since the stack grows down
*/
PROVIDE (__stack = 0);
/* PROVIDE (__global = 0); */
/*Initalize some symbols to be zero so we can reference them in the crt0 without core dumping. These functions are all optional, but we do this so we can have our crt0 always use them if they exist. This is so BSPs work better when using the crt0 installed with gcc. We have to initalize them twice, so we multiple object file formats, as some prepend an underscore.
*/
PROVIDE (hardware_init_hook = 0);
PROVIDE (software_init_hook = 0);
SECTIONS
{
. = 0xA0020000;
.text : {
_ftext = . ;
*(.init)
eprol = .;
*(.text)
*(.mips16.fn.*)
*(.mips16.call.*)
PROVIDE (__runtime_reloc_start = .);
*(.rel.sdata)
PROVIDE (__runtime_reloc_stop = .);
*(.fini)
etext = .;
_etext = .;
}
. = .;
.rdata : {
*(.rdata)
}
_fdata = ALIGN(16);
.data : {
*(.data)
CONSTRUCTORS
}
. = ALIGN(8);
_gp = . + 0x8000;
__global = _gp;
.lit8 : {
*(.lit8)
}
.lit4 : {
*(.lit4)
}
.sdata : {
*(.sdata)
}
. = ALIGN(4);
edata = .;
_edata = .;
_fbss = .;
.sbss : {
*(.sbss)
*(.scommon)
}
.bss : {
_bss_start = . ;
*(.bss)
*(COMMON)
}
end = .;
_end = .;
}
Debugger
issues for VR4100
processors
The following documentation
discusses
debugging with
VR4100
processors.
To
connect GDB to the DDB-VR4100
board, start GDB with the `ddb'
target. DDB boards are little-endian and use the PMON monitor. GDB uses
the MIPS remote debugging protocol to talk to this target via a serial
port. Additionally, the `ddb' target supports network downloading
using the TFTP protocol.
To run a program on the
DDB-VR4100 board, start up GDB with the name of your program as the argument.
To connect to the DDB-VR4100
board, for instance, use the `target ddb <port>' command,
where `<port>'is the name of the serial port connected to the board.
If the program has not already
been downloaded to the board, you can use the `load' command
to download it. You can then use all the usual GDB commands. For example,
the following example's input connects the target board through a Unix
serial port, and loads and runs a program called `prog'
through the debugger.
% mips64vr4100-elf-gdb
prog
GDB is free software and . . .
(gdb)target ddb /dev/ttyb
(gdb)load prog
(gdb)run
On PC platforms substitute
the specific COM port, using the following example's input.
C:\> gdb
prog
GDB is free software and . . .
(gdb)target ddb com3
(gdb)load prog
(gdb)run
You can speed up loading
of programs on the DDB board by installing a network card on the board
and using TFTP (trivial file transfer protocol) to download programs to
the board. You must first configure the DDB board manually for network
use.
Target command
options for VR4100
processors
The following documentation
discusses debugger commands for targeting with
VR4100
board s.
target ddb <hostname>:<portnumber>
On all GDB Unix host configurations, you can specify a TCP connection
(for instance, to a serial line managed by a terminal concentrator) instead
of a serial port, using the syntax `<hostname>:<portnumber>'.
target ddb <port>
<remote-tftp-name>
target ddb <hostname>:<portnumber>
<remote-tftp-name>
Specify a `<remote-tftp-name>' in the target command to enable
TFTP downloading in GDB. This name must be in the format: `<host>:<filename>'.
Here `<host>' is either the name or the IP address of the host system
that is running a TFTP server (typically your host Unix workstation). Here
`<filename>' is the name of a temporary file that GDB will create during
downloading. The directory containing the temporary file must be world-readable;
the `/tmp' directory is usually a good choice.
target ddb <port>
<remote-tftp-name> <local-tftp-name>
target ddb <hostname>:<portnumber>
<remote-tftp-name> <local-tftp-name>
You can also specify an optional `<local-tftp-name>', which is
a simple filename (without the `<host>' prefix). This tells GDB the
name of the temporary filename as seen by the host machine that is running
GDB. This is necessary only if the name of the file as seen by the host
machine is different from the name of that same file as seen via TFTP from
the target board. This might be the case if the TFTP server is running
on a different machine than the GDB host, and has a different name for
the same temporary file because of NFS mounting or symbolic links.
The following example
shows input for a TFTP download. The host machine running the TFTP server
has the IP address `192.168.1.1'. The temporary file that
GDB will create for TFTP downloading is `/tmp/download.tmp'.
% mips64vr4100-elf-gdb
prog
GDB is free software and . . .
(gdb)target ddb /dev/ttyb 192.168.1.1:/tmp/download.tmp
(gdb)load prog
(gdb)run
In the next example,
both a remote TFTP name and a local TFTP are specified, because the TFTP
server is running on a different machine, and has a different name for
the same temporary file than the host machine that is running GDB. The
name of the temporary file as seen by the TFTP server is `/mymachine/tmp/download.tmp',
but the name of that same file as seen by the host running GDB is `/tmp/download.tmp'.
% mips64vr4100-elf-gdb
prog
GDB is free software and . . .
(gdb)target ddb /dev/ttyb \
192.168.1.1:/mymachine/tmp/download.tmp /tmp/download.tmp
(gdb)load prog
(gdb)run
Special
debugging commands for VR4100
boards
GDB also supports the following
special commands for MIPS targets.
For this to be useful, you must know something about the MIPS debugging
protocol, also called `rmtdbg'. An informal description
can be found in the GDB source files, specifically in the file:
`remote-mips.c'.
You can see some
debugging information about communications with the board by setting the
`remotedebug'variable. If you set it to 1 using
`set remotedebug 1', every packet is displayed.
If you set it to 2, every character is displayed. You can check the current
value at any time with the command `showremotedebug'.
set timeout seconds
set retransmit-timeout
seconds
show timeout
show retransmit-timeout
You can control the timeout used while waiting for a packet, in
the MIPS debugging protocol, with the `set timeout seconds'
command. The default is 5 seconds. Similarly, you can control the timeout
used while waiting for an acknowledgment of a packet with:
set retransmit-timeout
seconds
The default is 3 seconds. You can inspect both values with `show
timeout' and `show retransmit-timeout'.
The timeout set
by `set timeout' does not apply when GDB is waiting for
your program to stop. In that case, GDB waits forever because it has no
way of knowing how long the program is going to run before stopping.
Stand-alone
simulator issues for VR4100
processors
The following documentation
discusses the three run-time command-line options for the stand-alone simulator:
-t,
-vand
-m. Before you can download a program to the DDB board,
without GDB, the program must be converted into S-records. See also Producing
S-records for VR4100
boards.
-
The `-t' command-line option
to the stand-alone simulator turns on tracing of all memory fetching and
storing in the simulator:
C:\>
The simulator writes
the trace information to the file `trace.din'. Here are
the first few lines of a trace file:
2 00000000a0020000
; width 4 ; load instruction
2 00000000a0020004 ; width 4 ; load instruction
2 00000000a0020008 ; width 4 ; load instruction
2 00000000a002000c ; width 4 ; load instruction
2 00000000a0020010 ; width 4 ; load instruction
2 00000000a0020014 ; width 4 ; load instruction
2 00000000a0020018 ; width 4 ; load instruction
-
The `-v' command-line option
prints some simple statistics.
Hello, world!
3 + 4 = 7
MIPS 64-bit simulator
Big endian memory model
0x00100000 bytes of memory at 0x00000000A0000000
Instruction fetches = 20653
Pipeline ticks = 20653
-
The `-m' command-line option
sets the size of the simulated memory area. The default size is 1048576
bytes (1 megabyte). The simulator rounds up the size you request to the
next power of two.
C:\>run
-v -m 200000 hello.xl
Hello, world!
3 + 4 = 7
MIPS 64-bit simulator
Big endian memory model
0x00040000 bytes of memory at 0x00000000A0000000
Instruction fetches = 20341
Pipeline ticks = 20341
Producing
S-records for VR4100
boards
The following documentation
describes how to download and run directly on the DDB board. Before you
can download a program to the DDB board, without GDB, the program must
be converted into S-records.
First, compile a little-endian
executable (`hello.xl') using the `-EL'
option to GCC.
mips64vr4100-elf-gcc
-g hello.c -o hello.xl -EL
Then, with the following
command, read the contents of the `hello.x1'executable,
convert the code and data into S-records, and put the result into the `hello.srec'
file.
mips64vr4100-elf-objcopy
-O srec hello.x1 hello.srec
The following first few lines
are from the resulting `hello.srec' download.
S00D000068656C6C6F2E7372656303
S31AA00200001024023CE00042340060824000688040AAAA0A3C5534
S31AA0020015554A3500008A44000880440000084400080944000011
S31AA002002A000005000A1500000000030020150000000014000497
S31AA002003F08000000001004023CE00042340060824010A0023C36
Downloading
to the DDB board for VR4100
boards
You can download programs
to the DDB board for execution directly on the board, without GDB. The
DDB board has a standalone ROM monitor called PMON that supports loading
of programs via a serial port or Ethernet.
Use the Unix `tip'
program to download a program to the DDB. In the following example, the
DDB board is connected to serial port `/dev/ttya' on a
Unix host.
NEC010>load tty0
Downloading from tty0, ^C to abort
~>hello.srec
NEC010> g
Downloading a program via
Ethernet is similar. First, convert the program to S-records; see Producing
S-records for VR4100
boards (above). Then, copy the S-record file to a directory
that is readable by all users, and use the `chmod o+r'
Unix command to make the S-record file readable. A good choice is a `/tmp'
directory, since it is likely to be already readable by all users.
PMON uses the TFTP protocol
to download programs via Ethernet. You must have a TFTP server running
on your Unix host in order to use net downloads. This server can be installed
by your system administrator.
The following example shows
a net download (`%' being a shell prompt). Substitute your
Unix host's name or IP address for `host' in the `load'
command.
%cp hello.srec
/tmp
%chmod o+r /tmp/hello.srec
%tip /dev/ttya
NEC010>load host:/tmp/hello.srec
Downloading from host:/tmp/hello.srec, ^C to abort
~>hello.srec
Entry address is a0020000
total = 0x7588 bytes
NEC010>g
Developing
for the VR4300
processors
The following documentation
describes
developing with the V
R4300
MIPS processors.
The following documentation
serves as reference material for using the V
R4300
MIPS processors.
-
DDB-VR4300
Evaluation Board
(NEC document #U11852EU1V0UM00 September 1996)
-
VR4300
MIPS Microprocessor User's Manual
(MIPS Technologies, Inc. 1995)
-
MIPS R4000 User's Manual
(Joseph Heinrich, Prentice-Hall, 1993,
ISBN 0-13-105925-4)
-
MIPS RISC Architecture
(Gerry Kane & Joe Heinrich, Prentice-Hall, 1992, ISBN 0-13-590472-2)
-
Address Allocation for Private Internets,
RFC 1918
(de Groot, G. J. and Lear, E. , February 1996)
-
System V Application Binary Interface
(Prentice-Hall, 1991, ISBN 0-13-880170-3)
-
System V Application Binary Interface
MIPS Processor Supplement
(Prentice-Hall, 1991, ISBN 0-13-880170-3)
Compiler features for
the VR4300
processors
The following documentation
discusses the compiler features for the VR4300
processors.
For a list of available
generic compiler options, GNU
CC command options and Option
summary for GCC in Using
GNU CC in GNUPro Compiler Tools. In addition, the following
VR4300-specific
command-line options are supported.
Compile code for the processor in little endian mode.
Compile code for the processor in big-endian mode.
GNUPro Toolkit for the
VR4300
does not comply with the proposed MIPS Embedded Application Binary Interface
(EABI) because that EABI has not yet been finalized.
Preprocessor symbols for VR4300
processors
See
Preprocessors
symbols and their definitions for the VR4300
processor for
preprocessor
symbols and their definitions with the GNU compiler options.
Preprocessors
symbols and their definitions for the VR4300
processor
|
Compiler options
which define the symbol
|
|
Only if `-ansi'
not used.
|
|
Only if `-ansi'
not used.
|
|
|
|
|
|
Only if `-ansi'
and `-EL' are not used.
|
|
Only if `-EL'
is not used.
|
|
Only if `-EL'
is not used.
|
|
Only if `-EL'
is not used.
|
|
Only if `-ansi'
not used.
|
|
|
|
Only if `-ansi'
is not used and `-EL' is used.
|
|
|
|
|
|
|
Note:
If neither
`-EL' or `-EB' are defined, big-endian
is the default.
Data
types and alignment for VR4300
processors
See Data
type sizes and alignments for VR4300 processors
for data type sizes and alignments for VR4300processor
s.
Data
type sizes and alignments for VR4300 processors
The stack is aligned on eight-byte
boundaries.
Argument passing for VR4300
processors
The compiler passes arguments
to a function using a combination of integer general registers, floating-point
registers, and the stack. The number, type, and relative position of arguments
in the calling functions argument list define the combination of registers
and memory used. The general registers `$4..$7' and the
floating-point registers `$f12' and `$f13'
pass the first few arguments.
If the function being called
returns a structure or union, the calling function passes the address of
an area large enough to hold the structure to the function in `$4'.
The function being called copies the returned structure into this area
before returning. The address in `$4' becomes the first
argument to the function for the purpose of argument register allocation.
All user arguments are then shifted down by one.
The compiler always allocates
space on the stack for all arguments even when some or all of the arguments
to a function are passed in registers. This stack space is a large enough
structure to contain all the arguments. After promotion and structure return
pointer insertion, the arguments are aligned according to normal structure
rules. Locations used for arguments within the stack frame are referred
to as the home locations.
Whenever possible, arguments
declared in variable argument lists, as with those defined using a `va_list'
declaration, are passed in the integer registers, even when they are floating-point
numbers.
If the first argument is
an integer, remaining arguments are passed in the integer registers.
The compiler passes structures
and unions as if they were very wide integers with their size rounded up
to an integral number of words. The "fill bits" necessary for rounding
up are undefined. A structure can be split so that a portion is passed
in registers and the remainder passed on the stack. In this case, the first
words are passed in `$4', `$5', `$6',
and `$7' as needed, with additional words passed on the
stack.
The rules for assigning which
arguments go into registers and which arguments must be passed on the stack
can be explained by considering the list of arguments itself as a structure,
aligned according to normal structure rules. Mapping of this structure
into the combination of registers and stack is as follows: up to two leading
floating-point (but not `va_list') arguments can be passed
in `$f12' and `$f13'; everything else with
a structure offset greater than or equal to 32 is passed on the stack.
The remainder of the arguments are passed in `$4..$7' based
on their structure offset. Any holes left in the structure for alignment
are unused, whether in registers or on the stack.
Function return values for VR4300
processors
A function can return no
value, an integral or pointer value, a floating-point value (single or
double precision), or a structure; unions are treated the same as structures.
A function that returns no value puts no particular value in any register.
A function that returns an integral or pointer value places its result
in register `$2'. A function that returns a floating-point
value places its result in floating-point register `$f0'.
The caller to a function
that returns a structure or a union passes the address of an area large
enough to hold the structure in register `$4'. The function
returns a pointer to the returned structure in register `$2'.
Register allocation for VR4300
processors
See
Register
allocation for VR4300 processors for
register
allocations for
VR4300
processor
s .
Register
allocation for VR4300
processors
General purpose
(integer) register
|
|
|
|
|
$1 through $15
, $24 , $25
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See Floating
point register usage for VR4300 processors
for floating point register usage for VR4300
processors.
Floating
point register usage for VR4300
processors
Do not depend on this order.
Instead, use GCC's `asm( )' extension and allow the compiler
to schedule registers.
Assembler
issues
for the VR4300
processors
For a list of available
generic assembler options, see Command-line
options in Using
as
in
GNUPro Utilities.
Any MIPS configuration of the assembler can select big-endian
or little-endian output at run time.
Use `-EB'
to select big-endian output, and `-EL' for little-endian.
The default is big-endian.
For information about the
MIPS instruction set, see MIPS RISC Architecture (Kane
and Heindrich, Prentice-Hall). For an overview of MIPS assembly conventions,
see "Appendix D: Assembly Language Programming" in MIPS RISC Architecture.
There are 32 64-bit general
(integer) registers, named `$0 ' through `
$31'.
For specific assembler mnemonics,
see MIPS RISC Architecture or MIPS R4000 User's
Manual.
Linker
issues for the VR4300
processors
For a list of available
generic linker options, see Linker
scripts in Using ldin
GNUPro Utilities. In addition, the following VR4300-specific
command-line options are supported.
Link objects for the processor in little endian mode.
-EB
Link objects for the processor in big-endian mode.
Linker
script for VR4300
processors
The GNU linker uses a linker
script to determine how to process each section in an object file, and
how to lay out the executable. The linker script is a declarative program
consisting of a number of directives. For instance, the ENTRY(
) directive specifies which symbol in the executable will be designated
the executable's entry point. Since linker scripts can be complicated to
write, the linker includes one built-in script that defines the default
linking process.
This linker script (`ddb.ld')
should be used when linking programs for the NEC DDB-VR4300 board. It can
also be used to link programs for execution in the MIPS simulator.
/* The following TEXT start address leaves space for the monitor workspace. */
ENTRY(_start)
OUTPUT_ARCH("mips:4000")
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-littlemips")
GROUP(-lc -lpmon -lgcc)
SEARCH_DIR(.)
__DYNAMIC = 0;
/* Allocate the stack to be at the top of memory, since the stack grows down.
*/
PROVIDE (__stack = 0);
/* PROVIDE (__global = 0); */
/* Initialize some symbols to be zero so we can reference them in the crt0 without core dumping. These functions are all optional, but we do this so we can have our crt0 always use them if they exist. This is so BSPs work better when using the crt0 installed with gcc. We have to initialize them twice, so we multiple object file formats, as some prepend an underscore.
*/
PROVIDE (hardware_init_hook = 0);
PROVIDE (software_init_hook = 0);
SECTIONS
{
. = 0xA0100000;
.text : {
_ftext = . ;
*(.init)
eprol = .;
*(.text)
PROVIDE (__runtime_reloc_start = .);
*(.rel.sdata)
PROVIDE (__runtime_reloc_stop = .);
*(.fini)
etext = .;
_etext = .;
}
. = .;
.rdata : {
*(.rdata)
}
_fdata = ALIGN(16);
.data : {
*(.data)
CONSTRUCTORS
}
_gp = ALIGN(16) + 0x8000;
__global = _gp;
.lit8 : {
*(.lit8)
}
.lit4 : {
*(.lit4)
}
.sdata : {
*(.sdata)
}
edata = .;
_edata = .;
_fbss = .;
.sbss : {
*(.sbss)
*(.scommon)
}
.bss : {
_bss_start = . ;
*(.bss)
*(COMMON)
}
end = .;
_end = .;
}
Debugger
issues for VR
4300 processors
To connect GDB to the DDB-VR4300
board start GDB with the `ddb'
target. DDB boards are little-endian and use the PMON monitor. GDB uses
the MIPS remote debugging protocol to talk to this target via a serial
port. Additionally, the `ddb' target supports network downloading
using the TFTP protocol.
To run a program on the
DDB-VR4300 board, start up GDB with the name of your program as the argument.
To connect to the DDB-VR4300 board, use the `target ddb <port>'
command , where `<port>'is the name of the serial port connected to
the board.
If the program has not
already been downloaded to the board, you can use the `load'
command to download it. You can then use all the usual GDB commands.
For example, the following
sequence connects to the target board through a Unix serial port, and loads
and runs a program called `prog' through the debugger:
mips64vr4300-elf-gdb
prog
GDB is free software and . . .
(gdb)target ddb /dev/ttyb
(gdb)load prog
(gdb)run
On PC platforms substitute
the specific COM port:
C:\> gdb
prog
GDB is free software and . . .
(gdb)target ddb com3
(gdb)load prog
(gdb)run
You can speed up loading
of programs on the DDB board by installing a network card on the board
and using TFTP (trivial file transfer protocol) to download programs to
the board. You must first configure the DDB board manually for network
use.
Target
command options for VR4300
processors
The following command options
are available for the VR4300 processors.
target ddb <hostname>:<portnumber>
On all GDB Unix host configurations, you can specify a TCP connection
(for instance, to a serial line managed by a terminal concentrator) instead
of a serial port, using the `<hostname>:<portnumber>' syntax.
target ddb <port>
<remote-tftp-name>
target ddb <hostname>:<portnumber>
<remote-tftp-name>
Specify a `<remote-tftp-name>' in the target command to enable
TFTP downloading in GDB. This name must be in the format: `<host>:<filename>'.
Here `<host>' is either the name or the IP address of the host system
that is running a TFTP server (typically your host Unix workstation). Here
`<filename>' is the name of a temporary file that GDB will create during
downloading. The directory containing the temporary file must be world-readable;
the `/tmp' directory is usually a good choice.
target ddb <port>
<remote-tftp-name> <local-tftp-name>
target ddb <hostname>:<portnumber>
<remote-tftp-name> <local-tftp-name>
You can also specify an optional `<local-tftp-name>', which is
a simple filename (without the `<host>' prefix). This tells GDB the
name of the temporary filename as seen by the host machine that is running
GDB. This is necessary only if the name of the file as seen by the host
machine is different from the name of that same file as seen via TFTP from
the target board. This might be the case if the TFTP server is running
on a different machine than the GDB host, and has a different name for
the same temporary file because of NFS mounting or symbolic links.
The following example
shows a TFTP download. The host machine running the TFTP server has the
`192.168.1.1' IP address . The temporary file that GDB
will create for TFTP downloading is the `/tmp/download.tmp'
file.
mips64vr4300-elf-gdb
prog
GDB is free software and . . .
(gdb)target ddb /dev/ttyb 192.168.1.1:/tmp/download.tmp
(gdb)load prog
(gdb)run
In the next example
both a remote TFTP name and a local TFTP are specified, because the TFTP
server is running on a different machine, and has a different name for
the same temporary file than the host machine that is running GDB. The
name of the temporary file as seen by the TFTP server is `/mymachine/tmp/download.tmp',
but the name of that same file as seen by the host running GDB is `/tmp/download.tmp'.
mips64vr4300-elf-gdb
prog
GDB is free software and . . .
(gdb)target ddb /dev/ttyb \
192.168.1.1:/mymachine/tmp/download.tmp /tmp/download.tmp
(gdb)load prog
(gdb)run
Special commands
for V R 4300 processors
GDB also supports the following
special commands for MIPS targets.
For this to be useful, you must know something about the MIPS debugging
protocol, also called `rmtdbg'. An informal description
can be found in the GDB source files, specifically in the file:
`remote-mips.c'.
You can see some
debugging information about communications with the board by setting the
`remotedebug'variable. If you set it to 1 using
`set remotedebug 1', every packet is displayed.
If you set it to 2, every character is displayed. You can check the current
value at any time with the command `showremotedebug'.
set timeout seconds
set retransmit-timeout
seconds
show timeout
show retransmit-timeout
You can control the timeout used while waiting for a packet, in
the MIPS debugging protocol, with the `set timeout seconds'
command. The default is 5 seconds. Similarly, you can control the timeout
used while waiting for an acknowledgment of a packet with:
set retransmit-timeout
seconds
The default is 3 seconds. You can inspect both values with `show
timeout' and `show retransmit-timeout'.
The timeout set
by `set timeout' does not apply when GDB is waiting for
your program to stop. In that case, GDB waits forever because it has no
way of knowing how long the program is going to run before stopping.
Stand-alone
simulator features for VR4300
processors
The following three run-time
command-line options are for the stand-alone simulator: -t,
-v,
and -m.
-
The `-t' command-line option
to the stand-alone simulator turns on tracing of all memory fetching and
storing in the simulator:
C:\>
The simulator writes
the trace information to the file `trace.din'. The following
example shows the first few lines of a trace file.
2 00000000a0020000
; width 4 ; load instruction
2 00000000a0020004 ; width 4 ; load instruction
2 00000000a0020008 ; width 4 ; load instruction
2 00000000a002000c ; width 4 ; load instruction
2 00000000a0020010 ; width 4 ; load instruction
2 00000000a0020014 ; width 4 ; load instruction
2 00000000a0020018 ; width 4 ; load instruction
2 00000000a002001c ; width 4 ; load instruction
2 00000000a0020020 ; width 4 ; load instruction
2 00000000a0020024 ; width 4 ; load instruction
-
The `-v' command-line option
prints some simple statistics.
Hello, world!
3 + 4 = 7
MIPS 64-bit simulator
Big endian memory model
0x00100000 bytes of memory at 0x00000000A0000000
Instruction fetches = 20653
Pipeline ticks = 20653
-
The `-m' command-line option
sets the size of the simulated memory area. The default size is 1048576
bytes (1 megabyte). The simulator rounds up the size you request to the
next power of two.
C:\>run
-v -m 200000 hello.xl
Hello, world!
3 + 4 = 7
MIPS 64-bit simulator
Big endian memory model
0x00040000 bytes of memory at 0x00000000A0000000
Instruction fetches = 20341
Pipeline ticks = 20341
Producing
S-records for VR4300
processors
Before you can download
a program to the DDB board, without GDB, the program must be converted
into S-records.
First, compile a little-endian
executable (`hello.xl') using the `-EL'
option to GCC, as the following example input shows.
mips64vr4300-elf-gcc
-g hello.c -o hello.xl -EL
The following command reads
the contents of the `hello.x1' file, converts the code
and data into S-records, and puts the result into the `hello.srec'
file.
mips64vr4300-elf-objcopy
-O srec hello.x1 hello.srec
The following example output
shows the first few lines of the `hello.srec' file.
S00D000068656C6C6F2E7372656303
S31AA01000001024023CE00042340060824000688040AAAA0A3C5534
S31AA0100015554A3500008A44000880440000084400080944000011
S31AA010002A000005000A1500000000030020150000000014000497
S31AA010003F08000000001004023CE00042340060824010A0023C36
Downloading
to the DDB board for VR4300
processors
You can download programs
to the DDB board for execution directly on the board, without GDB. The
DDB board has a standalone ROM monitor called PMON that supports loading
of programs via a serial port or Ethernet. Use the Unix `tip'
program to download a program to the DDB. In the following example, the
DDB board is connected to serial port `/dev/ttya' on a
Unix host.
NEC010>load tty0
Downloading from tty0, ^C to abort
~>hello.srec
NEC010> g
Downloading a program via
Ethernet is similar. First, convert the program to S-records as described
earlier. Then copy the S-record file to a directory that is readable by
all users, and use the Unix command `chmod o+r' to make
the S-record file readable. A good choice for a directory is `/tmp',
since it is likely to be already readable by all users. PMON uses the TFTP
protocol to download programs via Ethernet. You must have a TFTP server
running on your Unix host in order to use net downloads. This server can
be installed by your system administrator. The following example shows
a net download. Substitute your Unix host's name or IP address for `host'
in the `load' command:
% cp hello.srec
/tmp
% chmod o+r /tmp/hello.srec
% tip /dev/ttya
NEC010> load host:/tmp/hello.srec
Downloading from host:/tmp/hello.srec, ^C to abort
~>hello.srec
Entry address is a0100000
total = 0x7588 bytes
NEC010> g
Developing
for the VR5xxx
processors
The following documentation
describes
developing
with V
R5
xxx
MIPS processors. The actual development targets that have support are the
5000, 5400, 5432 and 5464 series processors.
Compiler
issues for the VR5xxx
processors
The following documentation
discusses the
compiler
features and issues for the VR5
xxx processors.
For a list of available
generic compiler options, GNU
CC command options and Option
summary for GCC in Using
GNU CC in GNUPro Compiler Tools.
The following V
R5
xxx-specific
command-line options have support.
Targets the VR5xxx
processors.
This is the default setting for all VR5xxx
processors.
-mcpu=vr5400
Targets the VR5400
processor.
-mabi=o64
Uses O32-extended for 64 bit registers.
-mips2
Generates code for 32-bit registers. If combined with `-mabi=eabi'
this will use 32-bit mode EABI. If combined with one of the above `-mcpu'
options, the combination allows the use of those machine specific instructions,
which are not reserved in 32-bit mode.
-EL
Generate little-endian code.
-EB
Generate big-endian code.
If neither `-EL'
nor `-EB' are defined, little-endian is the default.
Preprocessor issues for
V R 5 xxx processors
The compiler supports the
following preprocessor symbols:
Defines the symbol when preprocessing.
__R5400__
Defines the symbol when preprocessing if specifying `-mcpu=vr5400'
for VR5 xxx processors .
__R5000__
Defines the symbol when preprocessing if specifying `-mcpu=vr5000'
for VR5 xxx processors , or if no other `-mcpu='
option has been specified.
__MIPSEB__
Defines the symbol when preprocessing if specifying `-EB'
for big-endian code.
__MIPSEL__
Defines the symbol when preprocessing if specifying `-EL'
for little-endian code, or if not specifying `-EB' for
big-endian code.
Attributes
for VR5xxxprocessors
ABI issues
for the VR5xxx
processors
The V
R 5
xxxprocessors
have the following issues for its ABI.
V
R 5
xxxsupports
two types of ABI depending on the value of the `-mabi='
compiler flag (see also Compiler
issues for the VR5xxx processors ).
032
ABI summary for VR5xxx
processors
The following documentation
describes the 032 ABI for V
R5
xxx
processors.
Size and
alignment for VR5xxx processors using 032
ABI shows the size and alignment for all data types of V
R5
xxx
processors
with the 032 ABI.
Size
and alignment for VR5xxxprocessors
using 032 ABI
The stack is aligned on eight-byte
boundaries.
Calling
conventions for VR5xxx
processors using 032
The following documentation
discusses the
calling
conventions for the V
R5
xxx
processors.
Argument
passingfor VR5xxx
processors using 032 ABI
The compiler passes arguments
to a function using a combination of integer general registers, floating-point
registers, and the stack. The number, type, and relative position of arguments
in the calling functions argument list define the combination of registers
and memory used. The general registers `$4'
through `$7' and the floating-point registers `$f12'
and `$f13' pass the first few arguments.
If the function being called
returns a structure or union, the calling function passes the address of
an area large enough to hold the structure to the function in `$4'.
The function being called copies the returned structure into this area
before returning. The address in `$4' becomes the first
argument to the function for the purpose of argument register allocation.
All user arguments are then shifted down by one.
The compiler always allocates
space on the stack for all arguments even when some or all of the arguments
to a function are passed in registers. This stack space is a large enough
structure to contain all the arguments. After promotion and structure return
pointer insertion, the arguments are aligned according to normal structure
rules. Locations used for arguments within the stack frame are referred
to as the home locations.
Whenever possible, arguments
declared in variable argument lists, as with those defined using a `va_list'
declaration, are passed in the integer registers, even when they are floating-point
numbers.
If the first argument is
an integer, remaining arguments are passed in the integer registers.
The compiler passes structures
and unions as if they were very wide integers with their size rounded up
to an integral number of words. The "fill bits" necessary for rounding
up are undefined. A structure can be split so that a portion is passed
in registers and the remainder passed on the stack. In this case, the first
words are passed in `$4', `$5', `$6',
and `$7' as needed, with additional words passed on the
stack.
The rules for assigning which
arguments go into registers and which arguments must be passed on the stack
can be explained by considering the list of arguments itself as a structure,
aligned according to normal structure rules. Mapping of this structure
into the combination of registers and stack is as follows: up to two leading
floating-point (but not `va_list') arguments can be passed
in `$f12' and `$f13'; everything else with
a structure offset greater than or equal to 32 is passed on the stack.
The remainder of the arguments are passed in `$4' through
`$7', based on their structure offset. Any holes left in
the structure for alignment are unused, whether in registers or on the
stack.
Function
return values for
VR5xxx
processors with 032 ABI
A function can return no
value, an integral or pointer value, a floating-point value (single or
double precision), or a structure; unions are treated the same as structures.
The following documentation describes the return values in more detail.
-
A function that returns no value puts no
particular value in any register.
-
A function that returns an integral or pointer
value places its result in a `$2' register.
-
A function that returns a floating-point
value places its result in a `$f0' floating-point register.
-
The caller to a function that returns a structure
or a union passes the address of an area large enough to hold the structure
in a `$4' register. The function returns a pointer to the
returned structure in a `$2' register.
Register
allocation for VR5xxx
processors with 032 ABI
The following documentation
describes register allocation for the V
R5
xxx
processors using 032 ABI.
General
purpose (integer) registers and usage for V
R5
xxx
with 032 ABI
General purpose
(integer) register
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Floating
point registers and usage for VR5xxx
with
032 ABI
|
|
Volatile
|
$f0 through $f11
, $f14 through $f19
|
Parameter
|
|
Saved
|
|
Note:
Do not depend on the order
shown in Floating point
registers. Instead, use the `asm( )' compiler extension
to schedule registers.
EABI
summary for VR5xxx
processors
The following documentation
describes the MIPS EABI for V
R5
xxx
processors.
Data type sizes and alignments for
V R 5 xxx using MIPS EABI
Size
and alignment for data types with V
R5
xxx
processors
using MIPS ABI
The following rules also apply
for data types for VR5xxx
processors
using MIPS ABI.
-
Alignment within aggregates (structs and unions)
is as above, with padding added if needed
-
Aggregates have alignment equal to that of their
most aligned member
-
Aggregates have sizes which are a multiple of
their alignment
Subroutine
calls for VR5xxx
processors using MIPS ABI
The following documentation
describes the calling conventions for
subroutine
calls for V
R5
xxxprocessors
using MIPS ABI.
Parameter
registers and their usage for V
R5
xxxprocessors
using MIPS ABI
|
|
|
Floating point (hard-float
mode)
|
|
General
registers and their usage for V
R5
xxx
with
032 ABI
Use the following rules for
subroutine calls.
-
General-purpose and floating-point parameter
registers allocate independently.
-
Structures that are less than or equal to
32 bits pass as values.
-
Structures that are greater than 32 bits pass
as pointers.
-
In 32-bit mode, aggregates that are less
than or equal to 32 bits pass as values. In 64-bit mode, aggregates that
are less than or equal to 64 bits pass as values.
-
Otherwise, larger aggregates pass as pointers.
The stack frame for
VR5xxx
processors
T he following documentation
describes the
stack frame for V
R5
xxxprocessors.
-
The stack grows downwards from high addresses
to low addresses.
-
A leaf function does not need to allocate a
stack frame if it does not need one.
-
A frame pointer does not need allocating.
-
The stack pointer should always have alignment
with 8 byte boundaries.
*If no `alloca
' region the frame pointer (
FP) points
to the same place as
SP.
*If no `alloca
' region the frame pointer (
FP) points
to the same place as
SP.
Parameter
assignment to registers for VR5xxx
processors
Consider the parameters
in a function call as ordered from left (first parameter) to right. In
this algorithm, `FR' contains the number of the next available
floating-point register (or register pair for modes in which floating-point
registers hold only 32 bits). `GR' contains the number
of the next available general-purpose register. `STARG'
is the address of the next available stack parameter word.
INITIALIZE
Set GR=r4,
FR=f12,
and STARG to point to parameter word, 1.
SCAN
If there are no more parameters,
terminate. Otherwise, select one of the following depending on the type
of the next parameter: DOUBLEor FLOAT,
SIMPLE
ARG, LONG LONG, or STACK.
DOUBLEor FLOAT
If FR > f19,
go to STACK. Otherwise, load the parameter value into the
`FR' floating-point register and advance `FR'
to the next floating-point register (or register pair in 32-bit mode).
Then go to SCAN.
SIMPLE ARG
A SIMPLE ARGis
one of the following types:
-
One of the simple integer types which will
fit in 32 bits in 32-bit mode, or which will fit in 64 bits in 64-bit mode
-
A pointer to an object of any type
-
A struct or union small enough to fit in
a register
-
A larger struct or union, which shall be
treated as a pointer to the object or to a copy of the object; see Structure
passing for VR5xxx
for when copies are made
If GR > r11,
go to STACK. Otherwise, load the parameter value into the
`GR' general-purpose register and advance `GR'
to the next general-purpose register. Values shorter than the register
size are sign-extended or zero-extended depending on whether they are signed
or unsigned. Then go to SCAN.
LONG LONGin 32-bit mode
If GR > r10,
go to STACK. Otherwise, if `GR' is odd,
advance `GR' to the next register. Load the 64-bit `long
long' value into register pair, GRand GR+1.
Advance `GR' to `GR+2' and go to SCAN.
STACK
Parameters not otherwise
handled like DOUBLEor FLOAT, SIMPLE
ARG, LONG LONG, or SCANare passed
in the parameter words of the caller's stack frame. SIMPLE ARG,
(see SIMPLE ARGdefinition), is considered to have size
and alignment equal to the size of a general-purpose register, with simple
argument types shorter than this sign- or zero-extended to this width.
Float arguments are considered to have size and alignment equal to the
size of a floating-point register. In 64-bit mode, floats are stored in
the low-order 32 bits of the 64-bit space allocated to them. `double'
and `long long' are considered to have 64-bit size and
alignment. Round `STARG' up to a multiple of the alignment
requirement of the parameter and copy the argument byte-for-byte into STARG,
STARG+1,
and son through STARG+size-1. Set `STARG'
to `STARG+size' and go to SCAN.
Structure
passing for VR5xxx
Code that passes structures
and unions by value is implemented specially. (In this documentaion, structwill
refer to structs and unions inclusively.) Structs small enough to fit in
a register are passed by value in a single register or in a stack frame
slot which is the size of a register. Larger structs are handled by passing
the address of the structure. In this case, a copy of the structure will
be made if necessary in order to preserve the pass-by-value semantics.
See also Parameter
assignment to registers for VR5xxx.
See Structure
passing for the rules for copies of large structs for V
R5
xxx
processors.
Structure
passing for the V
R5
xxx
processors
In the case of normal (non-varargs)
large-struct parameters in ANSI mode, the callee is responsible for producing
the same effect as if a copy of the structure were passed, preserving the
pass-by-value semantics. Have the callee make a copy; however, in some
cases, the callee can determine that a copy is unnecessary to produce the
same results. In such cases, the callee can choose to avoid making a copy
of the parameter.
Varargs
handling for VR5xxx
No special changes are
needed for handling varargs parameters other than the caller knowing that
a copy is needed on struct parameters larger than a register (see Structure
passing).
The varargs macros set
up a two-part register save area, one part for the general-purpose registers
and one part for floating-point registers. Maintain separate pointers for
these two areas and for the stack parameter area. The register save area
lies between the caller and callee stack frame areas.
In the case of software
floating-point, only the general-purpose registers need saving. Because
the save area lies between the two stack frames, the saved register parameters
are contiguous with parameters passed on the stack, simplifying the varargs
macros. Only one pointer is needed, which advances from the register save
area into the caller's stack frame.
Function
return values for VR5xxx
Data
types and register usage for return values for V
R5
xxx
processors
|
|
|
|
|
|
|
|
|
r2 through r3
(32-bit
mode)
|
|
|
|
|
|
f0 through f1 (32-bit
mode)
|
|
|
|
|
Software floating-point
for VR5xxx
For software floating-point
implementations, floats shall be passed and returned like int,
and double passes and returns like long long.
This implies that, in 32-bit mode, floatwill pass in a
single integer register and doublewill pass in an even/odd
register pair. Similarly, float will return in a single
register, r2, and double will return in
a r2/r3 register pair.
Assembler
issues for the VR5xxx
processors
The following documentation
describes V
R5
xxx-specific
features of the assembler.
For a list of available
generic assembler options, see Command-line
options in Using asin
GNUPro Utilities. The assembler accepts the same set of 5xxx options
as the compiler.
Targets the VR5000. Default setting.
-mcpu=vr5400
Targets the VR5400.
-mabi=o64
Uses O32 extended for 64 bit registers.
-mips2
Generates code for 32-bit registers. If combined with `-mabi=eabi'
this will use 32-bit mode EABI. If combined with one of the above `-mcpu'
options, the combination allows the use of those machine specific instructions,
which are not reserved in 32-bit mode.
-EL
Generates little-endian code.
-EB
Generates big-endian code.
If neither `-EL'
nor `-EB' are defined, little-endian is the default.
For information about the
MIPS instruction set, see MIPS RISC Architecture (Kane and Heindrich,
Prentice-Hall). For an overview of MIPS assembly conventions, see "Appendix
D: Assembly Language Programming" in MIPS RISC Architecture.
There are 32 64-bit general
(integer) registers, named `$0 through$31'.
There are 32 64-bit floating-point registers, named `$f0 through$f31'.
The `$0'
through `$31' symbols refer to the general-purpose registers.
Symbols
and registers for the VR5xxx
processors
See Symbols
and registers for definitions of symbols used as aliases for
individual registers.
Symbols
and registers for
V
R5
xxx
Assembler directives for VR5xxx
See theAssembler
directives for the V
R5
xxx
processors.
V
R5
xxx
assembler
directives
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MIPS
synthetic instructions for the VR5xxx
For the V
R5
xxx
processors,
the assembler supports the typical MIPS synthetic instructions (macros).
See a list of synthetic instructions
supported by the assembler, as well as an example expansion of each instruction.
The following information serves as a guide to the corresponding code in
the the list.
R3
Integer registers
F1
F2
F3
Floating point registers
I1
I2
I3
Immediate integer values
MIPS synthetic instructions
for the assembler for V
R5
xxx
|
|
|
move R1,R2
neg R1,R2
abs_1
|
|
|
|
|
|
|
|
beq R1,$at,+I2
|
|
beql R1,$at,+I2
|
|
beqz $at,+I1
|
|
beqz $at,+I2
|
|
beqzl $at,+I1
|
|
beqzl $at,+I2
|
|
beqz $at,+I1
|
|
beqz $at,+I2
|
|
beqzl $at,+I1
|
|
beqzl $at,+I2
|
|
bnez $at,+I1
|
|
beqz $at,+I2
|
|
bnezl $at,+I1
|
|
beqzl $at,+I2
|
|
bnez $at,+I1
|
|
beqz $at,+I2
|
|
bnezl $at,+I1
|
|
beqzl $at,+I2
|
|
beqz $at,+I1
|
|
bnez $at,+I2
|
|
beqzl $at,+I1
|
|
bnezl $at,+I2
|
|
beqz $at,+I1
|
|
bnez $at,+I2
|
|
beqzl $at,+I1
|
|
bnezl $at,+I2
|
|
bnez $at,+I1
|
|
bnez $at,+I2
|
|
bnezl $at,+I1
|
|
bnezl $at,+I2
|
|
bnez $at,+I1
|
|
bnez $at,+I2
|
|
bnezl $at,+I1
|
|
bnezl $at,+I2
|
|
bne R1,$at,+I2
|
|
bnel R1,$at,+I2
|
|
move R1,R2
dneg R1,R2
dabs_1:
|
|
|
|
|
|
ddiv $zero,R2,R3
break 0x7
ddiv_1:
daddiu $at,$zero,-1
bne R3,$at,ddiv_2
daddiu $at,$zero,1
dsll32 $at,$at,0x1f
bne R2,$at,ddiv_2
nop
break 0x6
ddiv_2
mflo R1
|
|
ddiv $zero,R2,$at
mflo R1
|
|
ddivu $zero,R2,R3
break 0x7
ddivu_1:
mflo R1
|
|
ddivu $zero,R2,$at
mflo R1
|
|
div $zero,R2,R3
break 0x7
div_1:
li $at,-1
bne R3,$at,div_2
lui $at,0x8000
bne R2,$at,div_2
nop
break 0x6
div_2:
mflo R1
|
|
div $zero,R2,$at
mflo R1
|
|
divu $zero,R2,R3
break 0x7
divu_1:
mflo R1
|
|
divu $zero,R2,$at
mflo R1
|
|
daddu R1,R1,R2
|
|
|
|
ddiv $zero,R2,R3
break 0x7
drem_1:
daddiu $at,$zero,-1
bne R3,$at,drem_2
daddiu $at,$zero,1
dsll32 $at,$at,0x1f
bne R2,$at,drem_2
nop
break 0x6
drem_2:
mfhi R1
|
|
ddiv $zero,R2,$at
mfhi R1
|
|
ddivu $zero,R2,R3
break 0x7
dremu_1:
mfhi R1
|
|
ddivu $zero,R2,$at
mfhi R1
|
|
|
|
|
|
|
|
|
|
daddu R1,R1,R2
|
|
|
|
|
|
dsll32 R1,R1,0xf
|
|
dsll32 $at,$at,0xf
dmtc1 $at,F1
|
|
|
|
mtc1 $at,F1
|
|
|
|
|
|
|
|
|
|
nor R1,R1,$zero
|
|
|
|
div $zero,R2,R3
break 0x7
rem_1:
li $at,-1
bne R3,$at,rem_2
lui $at,0x8000
bne R2,$at,rem_2
nop
break 0x6
rem_2:
mfhi R1
|
|
div $zero,R2,$at
mfhi R1
|
|
divu $zero,R2,R3
break 0x7
remu_1:
mfhi R1
|
|
divu $zero,R2,$at
mfhi R1
|
|
srlv $at,R2,$at
sllv R1,R2,R3
or R1,R1,$at
|
|
srl R1,R2,32-I1
or R1,R1,$at
|
|
sllv $at,R2,$at
srlv R1,R2,R3
or R1,R1,$at
|
|
sll R1,R2,32-I1
or R1,R1,$at
|
|
|
|
|
|
sltiu R1,R1,1
|
|
sltiu R1,R1,1
|
|
xori R1,R1,0x1
|
|
xori R1,R1,0x1
|
|
xori R1,R1,0x1
|
|
xori R1,R1,0x1
|
|
|
|
slt R1,$at,R2
|
|
|
|
sltu R1,$at,R2
|
|
xori R1,R1,0x1
|
|
slt R1,$at,R2
xori R1,R1,0x1
|
|
xori R1,R1,0x1
|
|
sltu R1,$at,R2
xori R1,R1,0x1
|
|
|
|
|
|
sltu R1,$zero,R1
|
|
sltu R1,$zero,R1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ldr R1,I1+7(R2)
|
|
lbu $at,I1+1(R2)
sll R1,R1,0x8
or R1,R1,$at
|
|
lbu $at,I1+1(R2)
sll R1,R1,0x8
or R1,R1,$at
|
|
lwr R1,I1+3(R2)
|
|
sdr R1,I1+7(R2)
|
|
srl $at,R1,0x8
sb $at,I1(R2)
|
|
swr R1,I1+3(R2)
|
|
|
Linker
issues for VR5xxx
processors
The following documentation
describes V
R5
xxx-specific
features when working with ld, the GNUPro linker.
For a list of available
generic linker options, see Linker
scripts in Using ld
in GNUPro Utilities. There are no V
R5
xxx-specific
command-line linker options.
Linker
script for VR5xxx
targets
The linker uses a linker
script to determine how to process each section in an object file, and
how to lay out the executable. The linker script is a declarative program
consisting of a number of directives. For instance, the `ENTRY()'
directive specifies the symbol in the executable that will be the executable's
entry point.
The following linker script
is `ddb.ld', a linker script for the V
R5
xxx.
/* The following TEXT start address leaves space for the monitor workspace. */
ENTRY(_start)
OUTPUT_ARCH("mips:4000")
OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-littlemips")
GROUP(-lc -lpmon -lgcc)
SEARCH_DIR(.)
__DYNAMIC = 0;
/* Allocate the stack to be at the top of memory, since the stack grows down.
*/
PROVIDE (__stack = 0);
/* PROVIDE (__global = 0); */
/* Initialize some symbols to be zero so we can reference them in the crt0 without core dumping. These functions are all optional, but we do this so we can have our crt0 always use them if they exist. This is so BSPs work better when using the crt0 installed with gcc. We have to initialize them twice, so we multiple object file formats, as some prepend an underscore.
*/
PROVIDE (hardware_init_hook = 0);
PROVIDE (software_init_hook = 0);
SECTIONS
{
. = 0xA0100000;
.text : {
_ftext = . ;
*(.init)
eprol = .;
*(.text)
PROVIDE (__runtime_reloc_start = .);
*(.rel.sdata)
PROVIDE (__runtime_reloc_stop = .);
*(.fini)
etext = .;
_etext = .;
}
. = .;
.rdata : {
*(.rdata)
}
_fdata = ALIGN(16);
.data : {
*(.data)
CONSTRUCTORS
}
_gp = ALIGN(16) + 0x8000;
__global = _gp;
.lit8 : {
*(.lit8)
}
.lit4 : {
*(.lit4)
}
.sdata : {
*(.sdata)
}
edata = .;
_edata = .;
_fbss = .;
.sbss : {
*(.sbss)
*(.scommon)
}
.bss : {
_bss_start = . ;
*(.bss)
*(COMMON)
}
end = .;
_end = .;
}
Debugger features for the
VR5xxx
processors
The following documentation
describes V
R5
xxx-specific
features of the GNUPro debugger. There are three ways for GDB to talk to
a V
R5
xxx
target, depending upon the configuration of the specific evaluation board.
-
Simulator
GDB's built-in software simulation of the VR5xxx
processor allows the debugging of programs compiled for the VR5xxx
without requiring any access to actual hardware. To activate this mode
in GDB type `target sim'. Then load the code into the simulator
by typing `load' and debug it in the normal fashion.
-
Remote target board by serial connection
To connect to the target board in GDB, using the command
`target remote<devicename>' where `<devicename>'
will be a serial device such as `/dev/ttya' (Unix) or `com2'
(Windows NT). Then load the code onto the target board by typing 'load'.
After being downloaded, the program can be executed.
-
Remote target board by ethernet connection
Connecting to the ethernet port with GDB is very similar to connecting
to a serial port.
If the system
administrator has assigned a host name to the board, you can use that name
in the target command instead of the dotted IP address. It is important
to specify the port number. The exact number is not important, but it must
be the same number that you used to configure the board.
No special GDB
commands are necessary to perform fast downloading of programs via the
ethernet. Simply use the normal `load' command. GDB recognizes that the
board is connected via ethernet, and will use a fast binary downloading
method.
For the available generic
debugger options, see Debugging
with GDB in GNUPro Debugging Tools. There are no V
R5
xxx-specific
debugger command-line options.
Simulator features for the VR5xxx
processors
The simulator implements
the 64 bit MIPS ISA, which includes 32 64-bit integer registers and 32
64-bit floating-point registers. The user program is provided with a single
2mb block of memory at address `0xa0000000'
(shadowed at address `0x80000000').
The following general options,
are supported by the simulator:
This selects a specific MIPS instruction set architectur (ISA).
Valid ISAs are `mips:5000' and `mips:5400'. By default the `mips:5000'
is simulated.
--help
This provides a complete list of options recognized simulators.
Some specific options in the list may not be applicable to this simulator.
--dinero-trace=[on|off]
This creates a file called `trace.din' that contains tracing information.
Use the `--dinero-file' switch (discussed below) to change
the name of the output file.
%mips64vr5xxxel-elf-run
--dinero-trace hello
Hello, world!
3 + 4 = 7
The resulting first
10 lines of the file produced by the previous output file's input:
2 a0040004 ; width
4 ; load instruction
2 a0040008 ; width 4 ; load instruction
2 a004000c ; width 4 ; load instruction
2 a0040010 ; width 4 ; load instruction
2 a0040014 ; width 4 ; load instruction
2 a0040018 ; width 4 ; load instruction
2 a004001c ; width 4 ; load instruction
2 a0040020 ; width 4 ; load instruction
2 a0040024 ; width 4 ; load instruction
2 a0040028 ; width 4 ; load instruction
--dinero-file=<file>
This changes the name of the file to which trace information will
be written.
%mips64vr5xxxel-elf-run
--dinero-trace --dinero-file=trace.out hello
Placing trace information into file "trace.out"
Hello, world!
3 + 4 = 7
--profile-pc
This option creates a file called `gmon.out' that contains profiling
information. This file can be used as input to gprof, the GNU profiler.
%mips64vr5xxxel-elf-run
--profile-pc hello
Hello, world!
3 + 4 = 7
--profile-pc-frequency=<frequency>
By default, the simulator samples the running program every 256
instructions. This option allows you to change this profiling frequency
to some other number. Smaller numbers increasing the accuracy of the profile,
but make the simulator run slightly slower. Also, because the counters
used in the profile are only 16 bits, a high sampling frequency may cause
the counters to overflow.
%mips64vr5xxxel-elf-run
--profile-pc --profile-pc-frequency=128 hello
Hello, world!
3 + 4 = 7
--profile-pc-size=<size>
By default, the simulator uses a profiling sample size of 131072
(128K). This option allows you to change the sample size. Increasing the
sample size will make the profile more accurate, but will also increase
the size of the profile output file, `gmon.out'. The simulator rounds the
sample size up the next power of two.
%mips64vr5xxxel-elf-run
--profile-pc --profile-pc-size=20000 hello
Hello, world!
3 + 4 = 7