Contents|Previous|Next
NEC V850 development
The following documentation discusses the NEC V850 family of processors for GNUPro tools.
For more specific information on the V850 processor, see V850 User's Manual, V851 Hardware User's Manual (NEC document #U10954EU1V0UM00, January 1996), V850_EVA (Revision C), and System V Application Binary Interface (Prentice Hall, 1990).
Toolchain features for V850
 
The following documentation describes the main features of the tools addressing the V850 family of processors.
 
The V851 version of the V850 family of processors is supported with the GNUPro tools.
 
The V850 tools support the ELF object file format. To produce S-records, use the GNU linker, ld (see Using ld in GNUPro Utilities for more information) or objcopy (see Using binutils in GNUPro Utilities for more information).
 
For the V850 processor, file names are case sensitive under Unix. Case sensitivity for Windows 95 and Windows NT is dependent on system configuration. By default, file names under Windows 95 and Windows NT are not case sensitive for the V850 processor.
 
The following case sensitive issues under Unix, Windows 95, and Windows NT apply to the V850 processor.
The following case sensitive issues under Unix, Windows 95, or Windows NT do not apply to the V850 processor.
GNUPro Toolkit includes tools for converting legacy source code, originally written for other compilers, into GNUPro compiler (GCC) compliant code.
 
For the Windows 95/NT toolchain, the libraries install in different locations. Therefore, the Windows 95/NT hosted toolchain requires the following environmental settings to function properly. Assume the release is installed in C:\USR\CYGNUS . The <yymmdd> variable indicates the release date found on the CD.
Programs may be developed for and debugged on the GNUPro Instruction Set Simulator. The ICE (In-circuit Emulator) for V8511 is in development.  
1. See IE-703000-MC-A In-circuit Emulator for V851 User's Manual (from NEC Electronics Inc.) for details.
Cross-development tools in GNUPro Toolkit normally have names that reflect the target processor and the object file format output by the tools (ELF). This makes it possible to install more than one set of tools in the same binary directory, including both native and cross-development tools.
 
The complete tool name is a three-part hyphenated string. The first part indicates the processor or processor family (V850). The second part indicates the file format output by the tool (elf). The third part is the generic tool name (gcc). For example, the GCC compiler for the NEC V850 family of processors is V850-elf-gcc.
 
The V850 package includes the following supported tools.
ABI summary for the V850
 
The following documentation discusses the ABI for the V850 processor.
Data types and alignment for V850
 The following table describes the data types and their alignment sizes for the V850 processor.
 
char : 
1 byte 
short : 
2 bytes 
int : 
4 bytes 
long : 
4 bytes 
long long : 
4 bytes 
float : 
4 bytes 
double : 
4 bytes 
long double : 
8 bytes 
pointer : 
4 bytes 
 
The stack is aligned to a four byte boundary. One byte is used for characters (including structure/unions made entirely of chars), and two byte alignment for everything else. Basic data types shorter than a word are promoted to a word when passed as arguments or return values.
Calling conventions for V850 

 
GCC will use up to four registers for passing parameters (r6 through r9). A parameter may be split between registers and memory if it does not fit within the remaining available parameter registers. Alignment of parameters within the parameter list is the same as their basic alignment. This implies that doubles and long long types need not be 8-byte aligned in parameter lists.
 
Calling a varargs or stdarg function does not change how parameters are passed. However, the callee will flush all parameter registers back to a caller allocated parameter flush back area in the stack. This allows the callee to then treat all parameters as if they had been passed in the stack. The caller is responsible for allocating the 16-byte parameter flush back area at the bottom of the current stack. The callee is free to use that 16-byte area for any purpose in a non-varargs or a non-stdarg function.
 
Structures greater than 8 bytes in length, passed by value, are automatically converted into pass-by-invisible-reference structures (i.e., the compiler arranges to pass a pointer instead of the entire structure). The callee must make a copy of the structure if the callee modifies the pass-by-invisible reference structure.
 
Values are returned in the same manner as the GHS compilers, including the use of r6 as a return-structure-pointer when returning large structures. r31, also known as lp (link pointer), is used as a return pointer during a call instruction; the callee is responsible for saving r31 into the stack if the callee performs any additional function calls or uses r31 as a scratch register.
Stack arguments are located at increasing addresses from entry_sp. The varargs flush back area uses:
The callee can use the flush back area for any purposes if the callee does not use varargs or stdarg facilities.
Register allocation for V850

 
Fixed registers are never available for register allocation in the compiler. By default the following registers are fixed in GCC: r0 (zero), r1 and r3 (sp), r4 (gp), r30 (ep). Caller saved registers can be used by the compiler to hold values that do not live across function calls. The caller saved registers are r2, r5 through r19, and r31. Callee saved registers retain their value across function calls. The callee saved registers are r20 through r2 .
r29 is used as the frame pointer in some functions.
 
GCC will always create a frame pointer when not optimizing. The frame pointer will be eliminated when optimizing, except for functions which allocate dynamic stack space (functions which call alloca). Interrupt functions can never have a frame pointer; so, when compiling an interrupt function, you must either specify optimization (using the -O option) or by explicitly making the compiler not generate a frame pointer (by using the -fomit-frame-pointer option). Interrupt functions can not use alloca calls, nor can they have very large stacks (less than 32K, in size).
Stack frame information for V850

 
The following documentation discusses the stack frame for the V850 processor's usage, especially for the debugging processes. See stack frame and also stack frames for functions taking a variable number of arguments.
Stack frame for V850
 
* FP points to the same location as SP.
 
Stack frames for functions that take a variable number of arguments have usage as shown by Stack frames for functions taking a variable number of arguments.
 

Stack frames for functions taking a variable number of arguments
 
* FP points to the same location as SP.
Argument passing for V850
Arguments are passed to a function using (1) registers and (2) memory, if the argument passing registers are depleted. Each register is assigned an argument until all are used. Unused argument registers have undefined values on entry. Use the following rules.
Function return values for V850
Scalar or pointer return values are returned in r10 and sign-extended or zero-extended to 32 bits for types smaller than 32 bits.
To call a function which returns a structure or union in C and C++, the address of a temporary of the return type is passed by the caller in r6. The function returns the structure value by copying the return value to the address pointed to by r6, and copies r6 into r10 before returning to the caller.
Compiler issues for V850

 
The following documentation discusses the ABI for the V850 processor.
V850-specific command-line options for GCC

 

For a list of available generic compiler options, see GNU CC command options in Using GNU CC in GNUPro Compiler Tools.

The V850-specific command-line options are supported.

For more detailed information on the use of the following three compiler options, see Special data areas on the V850.
Preprocessor symbols for V850

 
By default, the compiler defines the preprocessor symbols as __v850__, __v851__, and __v850.
 
Special data areas on the V850

 There are 3 distinct data areas on the V850: zda (zero data area), sda (small data area), and tda (tiny data area).

It is also possible to use GCC attribute extension to the C language to explicitly specify which data area will contain a given variable. For example, the following declaration's syntax will put the integer variable, fred, into the zero data area.
If no special attributes or switches are used, it normally takes two 32-bit instructions to reference any global/static variable (one to get the high bits of the address into a register, and the other to do the memory reference). Both zda and sda static/global references take one 32-bit instruction, while tda references take one 16-bit instruction. Thus, you can put the most frequently used variables in the tiny data area and put most of the remaining variables into either the zero or small data areas to cut down on the size of the code space.
The variable, <n> in -mzda= <n>, -msda= <n>, and -mtda= <n> compiler options indicates variable size in bytes. Variables that aren't put into a specific section with an attribute, and whose size is less than or equal to <n> bytes, are put into the indicated data section. For -mtda= <n>, the maximum for <n> is 256 bytes. For -mzda= <n>, the maximum for <n> is 32768 bytes. The maximum for -msda= <n> is 65536 bytes. You can combine these switches, and the compiler first looks at tda, then sda, and finally, zda. The following example's input shows the appropriate declaration to provide.
This combination would indicate all static or global variables less than or equal to 4 bytes, which would become tda references, while all static or global variables less than 4 and greater than or equal to 256 bytes become sda references.
 
Consider the following code.
If compiled with no options, the compiler will put the fred structure into the normal data section of the program. This means that it will take two 32-bit instructions to fetch the contents of fred.a, and another two 32-bit instructions to fetch the contents of fred.b for the program. If the program is compiled with a -msda=8 declaration, then the compiler will put the fred structure into the small data area (since fred is 8 bytes in length, and the -msda=8 option tells the compiler to put all variables of size 8 or less into the small data area). Now it will only take one 32-bit instruction to fetch fred.a, and one to fetch fred.b for compiling. If the program had been compiled with the -mtda=8 declaration, then fred would have been put into the tiny data area, and fetching fred.a would have required only one 16-bit instruction.
As an alternative, the following code has been changed.
When this code is compiled (with or without any special command line options), the fred structure is placed into the zero data area and fetching either fred.a or fred.b requires one 32-bit instruction apiece.
The default behaviour is to place variables into the (ordinary) data section. Adding _attribute__ ((zda)) forces that particular variable to go into the zero data area, but has no effect on other variables. Specifying -mzda= <n> on the command line forces all variables whose size is less than or equal to <n> bytes into the zero data area. It is up to the programmer to determine what value to use for <n>. If the value is too large, then too many variables will be put into the zero data area and error messages will be produced by the linker (after all, the zda only has room for 32K bytes of data).
depragmaize for V850

 
depragmaize modifies source code and associated header files. depragmaize converts uses of certain pragmas in C code to uses of equivalent GCC attributes. Pragmas, often used to implement vendor specific features, are in many circumstances very difficult to maintain both in the compiler and in the source code that maintains them. For those machine-specific features affecting declarations or symbols, attributes are a much better way to implement these features, again both for the compiler maintainer and for the source code maintainer. GCC has a well defined mechanism for adding new attributes to the compiler.
For more information about GCC's attributes, see Using GNU CC or use the gcc.info on-line help file.
In order to convert a particular source file, the source file must contain C code compilable by GCC (which, of course, includes ANSI C code as well as any GCC extensions). depragmaize only converts a limited set of pragmas; see Conversions for a current list.
depragmaize is intended to be simple to use. The following descriptions for suggestions of the conversion process will answer most questions. For instance, see depragmaize options  for the options that depragmaize accepts.
Conversions
 
#pragma ghs startXXX
#pragma ghs endXXX 
XXX is tda, sda, or zda. depragmaize will add the __attribute__((section("tda"))) pragma to the appropriate symbols between the start and end pragmas. If the -R option is specified, depragmaize will also remove these pragmas from the source. 
#pragma ghs interrupt 
To the function containing the pragma, __attribute__((interrupt)), depragmaize will add __attribute__((interrupt)). If the -R option is specified, depragmaize will also remove this pragma from the source. 
To do the conversion, depragmaize makes use of GCC to find all the parts of the source that need changing. That's why the source code must be compatible with the GCC compiler source code in order for depragmaize to convert it. Unfortunately, most real source code is not just compilable. Usually, some number of compile time options must be passed to the compiler in order for the particular source code to be properly compiled by the compiler. Also, source code is often compiled under a number of different sets of compile time options to produce different executables. See the following documentation for further discussion of such issues. In the simplest case (if your source code is very simple) you would invoke depragmaize as the following example declaration suggests (where <file.c> is the name of the source code file to be converted).
depragmaize and <file.c> must be in the current working directory. depragmaize will convert <file.c> and any header files that the <file.c> includes, if those header files reside in the current working directory. The actual conversions done are described in the following discussions. depragmaize only converts files that are in the current working directory unless the -d option is used. depragmaize will save a copy of the unconverted source file in  <file.c>save, unless the -N option is used. Any number of source files can be specified on a single invocation of depragmaize.

If a source file, or set of source files, uses header files that are not in the current working directory, and those header files also must be converted, specify with the -d option. For instance, the following declaration specifies that depragmaize should convert <file.c> and any headers used by <file.c>, if those headers are in the current working directory or in another directory, other_directory.

Often your source code will require some compile time options to successfully compile.
The previous declaration will pass -DMACRO1=1 and -I../include_files to GCC. Typically, the kinds of options that will need to be passed to GCC will be -D options and -I options. Someone familiar with building the source code involved will need to determine the exact list of options required to compile that source.
For some source code, the list of symbols actually seen by the compiler is affected by the options given to the compiler. For instance, use the following example to generate symbol lists.
If MACRO1 is defined on the command line, the compiler will see the symbol, a, but not b; and the opposite if MACRO1 is not defined. depragmaize can only convert code actually seen by the compiler. In a case like this depragmaize must be invoked twice, once with MACRO1 defined, once without such a declaration. Of course, if MACRO1 does not make code converted, you need not use this definition. For some source code, the actual conversion required will depend on the command line arguments. The most likely example of this would be cases where the tokens of the #pragmas changed, depending on the command line arguments. Unfortunately, the complexity of the conversions required by these cases is beyond depragmaize's ability to handle automatically. You will need to make these conversions by hand first, and then let depragmaize handle the other more common cases.
 
Finally, because of the possibility that some source code may need to be run through depragmaize more than once to effect complete conversion, and depragmaize does not remove the pragma's from the source code until the -R option is specified. If your source code does not need to be run through depragmaize more than once, you can use -R on that invocation, otherwise use -R on the last invocation.
depragmaize options

 
The following documentation discusses the depragmaize options. The following example shows the standard approach for a depragmaize declaration.
Each file and any header files it includes are converted.
 
Files and headers are only converted if they reside in the current directory or a directory specified by the -d option. For each file that is converted, and for which some change is actually made, depragmaize will create a copy of the original unconverted file under the name, XXX.save, where XXX is the name of the converted file (so  file.c is saved under file.c.save). If XXX.save already exists, depragmaize will not overwrite it, and simply does not do this copy. The -N option tells depragmaize not to make these copies.
 
Structure conversion for V850
Structure conversion is done, using the GCC offset-info option.
The -offset-info output-file option simplifies access to C struct's from the assembler.
For each member of each structure, the compiler will output a .equ directive to associate a symbol with the member's offset in bytes into the structure.
The symbol itself is the concatenation of the structure's tag name and the member's name, separated by an underscore. This option will output to the specified output-file an assembler .equ directive for each member of each structure found in each compilation. The .equ directives for the structures in a single header file can be obtained as follows, where m.h is the header containing the structures, and m.s is where the directives are output.
The following is a short example of output produced by the -offset-info option.
 
The -offset-info option has the following caveats.
Assembler information for V850

 
The following documentation discusses the assembler issues for the V850 tools.
For a list of available generic assembler options, see Command-line options in Using as in GNUPro Utilities. There are no V850-specific assembler command-line options. The V850 syntax is based on the syntax in NEC's V850 User's Manual.
Register names for V850

 
You can use the predefined symbols, r0 through r31, to refer to the V850 registers. V850 also has predefined symbols for the following general registers.
 
ep 
element ptr, synonym for r30 
gp global ptr, synonym for ` r4 '
hp 
synonym for ` r2 handler stack ptr, ' 
lp 
link ptr, synonym for ` r31 ' 
sp 
stack ptr, synonym for ` r3 ' 
tp 
text ptr, synonym for ` r5 ' 
zero 
zero register, synonym for ` r0 ' 
 

Addressing modes for V850
 

The assembler understands the following addressing modes for the V850. The symbol, Rn, in the following examples refers to any of the specifically numbered registers or register pairs, but not the control registers (where n signifies the actual number to specify; see the V850 User's Manual for actual specifications).
Floating point values for V850
 
Although the V850 has no hardware floating point, the assembler supports software floating point. The .float and .double directives generate IEEE-format floating-point values for compatibility with other development tools.
 
Opcodes for V850
 
For detailed information on the V850 machine instruction set, see V850 User's Manual. The assembler implements all the standard V850 opcodes.
Assembler error messages for V850
 
The following messages output as assembler error messages.
Linker information for V850
 
For a list of available generic linker options, see Linker scripts in Using ld in GNUPro Utilities. In addition, the following V850-specific command-line option is supported:
See also linker script for the V850 processor and Producing S-records for V850.

The initial value for the stack pointer is defined in the linker script with the PROVIDE linker command. This allows the user to specify a new value on the command line with the standard linker option, --defsym.
 

Linker script for V850

 
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 the symbol in the executable that will be 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.

For the V850 tools, the following example shows the default script for the V850.

Although this script is somewhat lengthy, it is a generic script that will support all ELF situations. In practice, generation of sections like .rela.dtors are unlikely when compiling using embedded ELF tools.

Producing S-records for V850
 
The following command reads the contents of hello.x, converts the code and data into S-records, and puts the result into hello.srec.
Here are the first few lines of hello.srec:
Debugger issues for V850
 
There are no V850-specific debugger command-line options.
 
For all available debugger options, see Debugging with GDB in GNUPro Debugging Tools.
GDB's built-in software simulation of the V850 processor allows the debugging of programs compiled for the V850 without requiring any access to actual hardware. Activate this mode in GDB by the command, target sim. Then load code into the simulator by the command, load, and debug it in the normal fashion.
 
The Target Selection window for the GNUPro visual debugger, Cygnus Insight, has additional functionality. Accessible from Insight's Source Window, V850 users developing with ICE select a target by entering the name of the ICE target into the Target Selection window's dialog box.
 
Stand-alone simulator issues for V850
The simulator supports general registers, r0 through r31, PC (program counter, low 24 bits only), and PSW (low 5 bits only). It does not support any of the additional system registers or memory mapped registers.
Registers are all uninitialized at startup.
There are no V850-specific stand-alone simulator command-line options.
Top|Contents|Previous|Next