Motorola 68000 Family C Cross Compiler B3640 97001_68000_C_Cross Compiler_Jan94 97001 Jan94

B3640-97001_68000_C_Cross-Compiler_Jan94 B3640-97001_68000_C_Cross-Compiler_Jan94

User Manual: B3640-97001_68000_C_Cross-Compiler_Jan94

Open the PDF directly: View PDF .
Page Count: 364 [warning: Documents this large are best viewed by clicking the View PDF Link!]

User’s Guide

HP B3640 Motorola 68000

Family C Cross Compiler

Notice

Hewlett-Packard makes no warranty of any kind with regard to this material,

including, but not limited to, the implied warranties of merchantability and

fitness for a particular purpose. Hewlett-Packard shall not be liable for errors

contained herein or for incidental or consequential damages in connection with the

furnishing, performance, or use of this material.

Hewlett-Packard assumes no responsibility for the use or reliability of its software

on equipment that is not furnished by Hewlett-Packard.

This document contains proprietary information, which is protected by copyright.

All rights are reserved. No part of this document may be photocopied, reproduced

or translated to another language without the prior written consent of

Hewlett-Packard Company. The information contained in this document is subject

to change without notice.

UNIX is a registered trademark of UNIX System Laboratories Inc. in the U.S.A.

and other countries.

MS-DOS and Windows are U.S. registered trademarks of Microsoft Corporation.

Hewlett-Packard Company

P.O . Box 2197

1900 Garden of the Gods Road

Colorado Springs, CO 80901-2197, U.S.A.

RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S.

Government is subject to restrictions set forth in subparagraph (C) (1) (ii) of the

Rights in Technical Data and Computer Software Clause in DFARS 252.227-7013.

Hewlett-Packard Company, 3000 Hanover Street, Palo Alto, CA 94304 U.S.A.

Rights for non-DOD U.S. Government Departments and Agencies are set forth in

FAR 52.227-19(c)(1,2).

About this edition

Many product updates and fixes do not require manual changes, and manual

corrections may be done without accompanying product changes. Therefore, do

not expect a one-to-one correspondence between product updates and manual

revisions.

Edition dates and the corresponding HP manual part numbers are as follows:

Edition 1 B3640-97000, May 1993

Edition 2 B3640-97001, January 1994

B3640-97000 incorporates information which previously appeared in

64902-92003, 64902-97000, 64902-97001, 64903-92004, 64903-97000,

64903-97001, 64907-92002, 64907-97000, 64907-97001, 64908-92002,

64908-97000, 64908-97001, 64909-92002, 64909-97000, and 64909-97001.

Certification and Warranty

Certification and warranty information can be found at the end of this manual on

the pages before the back cover.

iii

Features

The Motorola 68000 Family C Cross Compiler translates C source code into 68000

family assembly language which can be accepted by the HP B3641 assembler. This

compiler has special features to help meet the needs of the embedded system

designer:

•ANSI standard C compiler and preprocessor.

•Standard command line interface for compatibility with make and other

utilities.

•Complete C support and math libraries from ANSI standard for nonhosted

environments.

•In-line code generation and libraries to support the 68881/2 floating point unit.

•Three ways to embed assembly language in C source.

•Named section specification in C source.

•Choice of address modes for function calls and static data access.

•Option to copy initial value data from ROM to RAM at load time.

•Listings with generated assembly language, C source, and cross references.

•Fully reentrant generated code.

•Optimization for either time or space.

•Constant folding, automatic register variable selection, and other global

optimizations.

•Full symbol information and C source line numbers provided for debugging,

emulation, simulation, and analysis tools.

•Compiler reliability ensured through object-oriented design and exhaustive

testing.

Contents

Part 1 Quick Start Guide

1 Getting Started

In this chapter 2

What you need to know 2

Parts of the compiler 3

Summary of compiler options 4

Summary of file extensions 6

To install the software on a UNIX workstation 7

To install the software on a PC (Windows) 8

To remove unnecessary files (UNIX only) 10

To create a simple C program 11

To compile a simple program 12

To generate an assembly listing 13

To specify addressing modes 14

To specify the target microprocessor 19

To compile for a debugger 20

To use a makefile (UNIX systems only) 21

To modify environment libraries 23

About environment libraries 26

To view the on-line man (help) pages 27

vii

Part 2 Compiler Reference

2 C Compilation Overview

Execution Environment Dependencies 32

C Compilation Overview 33

Compilation Control Routine 35

C Preprocessor 35

C Compiler 35

Peephole Optimizer 35

Assembler 36

Source File Lister 36

Librarian 36

Linker 36

ANSI Extensions to C 37

Assignment Compatibility 37

Function Prototypes 37

Pragmas 38

The void Type 39

The volatile Type Modifier 40

The const Type Modifier 41

Translation Limits 42

3 Internal Data Representation

Arithmetic Data Types 44

Floating-Point Data Types 44

Characters 47

Derived Data Types 48

Pointers 48

Arrays 48

Structures 51

Unions 53

Enumeration Types 53

Contents

viii

Alignment Considerations 54

Alignment Examples 56

Byte Ordering 57

4 Compiler Generated Assembly Code

Assembly Language Symbol Names 61

Symbol Prefixes 61

Situations Where C Symbols are Modified 62

#pragma ALIAS 63

Compiler Generated Symbols 63

Debug Directives 64

Stack Frame Management 64

Structure Results 66

Parameter Passing 67

Pushing the Old Frame Pointer and Allocating Space 67

Buffering Registers Used for Register Variables 68

Accessing Parameters 68

Accessing Locals 69

Using the Stack for Temporary Storage 69

Function Results 70

Function Exit 70

Example 79

Run-Time Error Checking 80

Using Assembly Language in the C Source File 81

#pragma ASM

#pragma END_ASM 82

__asm ("C_string") 84

#pragma FUNCTION_ENTRY, #pragma FUNCTION_EXIT,

#pragma FUNCTION_RETURN 86

Assembly Language in Macros 89

Contents

5 Optimizations

Universal Optimizations 92

Constant Folding 93

Expression Simplification 94

Operation Simplification 94

Optimizing Expressions in a Logical Context 95

Loop Construct Optimization 95

Switch Statement Optimization 96

Automatic Allocation of Register Variables 96

String Coalescing 96

The Optimize Option 98

Time vs. Space Optimization 98

Multiplication Simplification 100

Maintaining Debug Code 100

Peephole Optimization 100

Effect of volatile Data on Peephole Optimizations 104

Function Entry and Exit 104

In-Line Expansion of Standard Functions 104

What to do when optimization causes problems 106

6 Embedded Systems Considerations

Execution Environments 108

Monitor and mon_stub 108

Common problems when compiling for an emulator 109

Loading supplied emulation configuration files 109

Using the "-d" option 110

Section Names 111

#pragma SECTION 111

Addressing Modes 114

Specifying addressing modes 115

When to use certain addressing modes 115

Short vs. long 116

Absolute addressing modes 117

Contents

PC relative addressing modes 117

A5 relative addressing modes 118

Other addressing mode considerations 122

RAM and ROM Considerations 122

Initialized data 122

Where to load constants 123

Embedded Systems with Mass Storage 123

The "volatile" Type Modifier 124

Reentrant Code 126

Nonreentrant library routines 126

Implementing Functions as Interrupt Routines 127

#pragma INTERRUPT 127

Loading the vector address 127

Eliminating I/O 128

7 Libraries

Addressing Modes Used in Libraries 130

Run-Time Library Routines 132

Support Library and Math Library Routines 132

Library Routines Not Provided 133

Include (Header) Files 134

List of All Library Routines 136

Support Library and Math Library Descriptions 141

abs, labs 142

assert 143

atexit 144

bsearch 145

div, ldiv 147

exp 148

Contents

fclose, fflush 149

ferror, feof, clearerr 150

fgetpos, fseek, fsetpos, rewind, ftell 150

floor, ceil, fmod, frem, fabs 153

fopen, freopen 154

_fp_error 156

fread, fwrite 161

frexp, ldexp, modf 162

getc, getchar, fgetc 163

gets, fgets 164

interpolateS, interpolateSN, interpolateU, interpolateUN 165

isalpha, isupper, islower, ... 166

localeconv 168

log, log10 173

malloc, free, realloc, calloc 174

mblen, mbstowcs, mbtowc, wcstombs, wctomb, strxfrm 176

memchr, memcmp, memcpy, memmove, memset 178

perror, errno 179

pow 180

printf, fprintf, sprintf 181

putc, putchar, fputc 186

puts, fputs 188

qsort 189

rand, srand 189

remove 191

scanf, fscanf, sscanf 192

setbuf, setvbuf 197

setjmp, longjmp 199

setlocale 201

sin, cos, tan, asin, acos, atan, atan2 203

sinh, cosh, tanh 205

sqrt 206

strcat, strncat, ... 207

strtod, atof 210

strtol, strtoul, atol, atoi 211

tableS, tableSN, tableU, tableUN 213

toupper, tolower, _toupper, _tolower 214

ungetc 215

va_list, va_start, va_arg, va_end 216

vprintf, vfprintf, vsprintf 218

Contents

xii

8 Environment-Dependent Routines

Supported Environments 222

Program Setup 223

Differences Between "crt0" and "crt1" 223

The "_display_message()" Routine 226

Monitor Considerations 226

Linking the Program Setup Routines 227

Emulator Configuration Files 228

Default Memory Map 228

Dynamic Allocation 229

Rewriting the "_getmem" Function 229

Input and Output 229

Environment-Dependent I/O Functions 230

clear_screen 231

close 232

exec_cmd 233

exit, _exit 235

_getmem 236

initsimio 238

kill 239

lseek 240

open 242

pos_cursor 245

sbrk 248

unlink 248

write 250

Contents

xiii

9 Compile-Time Errors

Errors 254

Warnings 262

10 Run-Time Errors

Floating-Point Error Messages 266

68881/2 Libraries: 266

Processor Libraries: 267

Debug Error Messages 268

Pointer Faults: 268

Range Faults: 268

Startup Error Messages 269

11 Run-Time Library Description

Conversion Routines 272

dtof 272

dtoi 272

dtoui 273

ftod 273

ftoi 273

ftoui 274

itod 274

uitod 274

itof 274

uitof 275

Floating-Point Routines 275

add32 275

add32z 275

add64 276

add64p 277

add64pp 277

add64z 278

Contents

xiv

cmp32 278

cmp32r 278

cmp64 279

cmp64r 279

div32 279

div32r 280

div32z 280

div64 280

div64p 281

div64pp 281

div64r 282

div64rp 282

div64rpp 283

div64z 283

mul32 283

mul32z 284

mul64 284

mul64p 284

mul64pp 285

mul64z 285

sub32 286

sub32r 286

sub32z 286

sub64 287

sub64p 287

sub64pp 288

sub64r 288

sub64rp 288

sub64rpp 289

sub64z 289

Debug Routines 290

rangefault 290

rangefaultu 290

ptrfault 291

Contents

12 Behavior of Math Library Functions

13 Comparison to C/64000

General C/64000 Options 302

AMNESIA 302

ASM_FILE 302

ASMB_SYM 302

DEBUG 302

EMIT_CODE 303

END_ORG 303

ENTRY 303

EXTENSIONS 303

FIXED_PARAMETERS 303

FULL_LIST 303

INIT_ZEROS 303

LINE_NUMBERS 304

LIST 304

LIST_CODE 304

LIST_OBJ 304

LONG_NAMES 304

OPTIMIZE 304

ORG 304

PAGE 304

RECURSIVE 305

SEPARATE 305

SHORT_ARITH 305

STANDARD 305

TITLE 305

UPPER_KEYS 305

USER_DEFINED 305

WARN 305

WIDTH 306

68000 Specific C/64000 Options 306

INTERRUPT 306

TRAP 306

BASE_PAGE , FAR, COMMON, CALL_ABS_LONG, CALL_ABS_SHORT,

CALL_PC_SHORT, CALL_PC_LONG, LIB_ABS_LONG, LIB_ABS_SHORT,

LIB_PC_SHORT, LIB_PC_LONG 307

Contents

xvi

Differences from HP 64819 Code 308

14 ASCII Character Set

15 About this Version

Version 4.01 318

PC Platform Support 318

Version 4.00 318

Compilers have been combined 318

New product number 318

New command-line options 319

New default environments 319

PC-relative libraries 319

More floating-point support 319

Using the correct version of "as68k" 319

Re-organized manual 320

Version 3.50 320

Behavior of sprintf 320

Bit fields 320

Formatted printing 320

Streams 320

Void pointers 320

Implicit casts 321

qsort function 321

Environment library modules 321

Improved performance 321

68040 function return values 321

New optimizations 322

Code sharing 322

__asm ("C_string") function 322

Modifying function entry/exit code 322

Contents

xvii

Contents

xviii

Part 1

Quick Start Guide

Part 1

Getting Started

How to get started using the compiler.

Chapter 1: Getting Started

In this chapter

This chapter contains the following information:

•An overview of the C compiler.

•Instructions for common tasks, such as compiling a simple program.

•Short examples so you can practice the common tasks.

What you need to know

Before you begin to learn how to use this compiler, you should be familiar with the

following:

•The C programming language.

•The Motorola 68000 family microprocessor architecture.

•Basic host operating system commands (such as cp, mv, ls, mkdir, rm, and cd

in UNIX or copy, dir, mkdir, del, and cd in DOS) and a text editor (such as vi

in UNIX or edit in DOS).

In addition, most sections in this manual assume that you are familiar with 68000

family assembly language.

Chapter 1: Getting Started

Parts of the compiler

The "compiler" is really a set of programs:

•cc68k, the C compilation control command.

•cpp68k, the C preprocessor.

•clst68k, the lister.

•ccom68xxx, the C compiler. (ccm68xxx for DOS.)

•opt68xxx, the peephole optimizer.

The compiler makes use of several assembler programs:

•as68k, the assembler.

•ld68k, the linking loader.

To compile a C program, you can use just the cc68k C compilation control

command. The cc68k command will run the other programs as needed.

Chapter 1: Getting Started

Summary of compiler options

-b Invoke Basis Branch Analyzer preprocessor. (UNIX only)

-B Cause generation of big switch tables for > 32K byte

switch bodies.

-c Do not link programs (object files are generated).

-C Do not strip C-style comments in preprocessor.

-d Separate data into initialized and uninitialized sections.

-D name[=def] Define name to the preprocessor.

-e Fast error checking (no code is generated).

-E Preprocess only (send result to standard output).

-f Generate code to use the 68881/2 coprocessor.

-g Generate run-time error checking code (overrides -O).

-h Generate HP 64000 format (.X) files.

-I dir Change include file search algorithm.

-k linkcomfile Link using the linkcomfile linker command file.

-K Enforce strict section consistency.

-lxSearch libx.a (libx.lib for DOS) when linking.

-L[i][x] Generate ".O" (".lst" for DOS) listing(s). The -i option

causes include files to be expanded and included in the

listing. The -x option causes cross-reference tables to be

included in the listings. (Overridden by -e, -E, and -P.)

-m Specify addressing mode.

Chapter 1: Getting Started

Summary of compiler options

-M Cause generation of more warning messages than are

generated by default.

-N Cause linking with linkcom.k (no I/O) rather than

iolinkcom.k (iolinkco.k for DOS).

-o outfile Name absolute file outfile instead of a.out.x. (aout.abs for

DOS).

-O[G][T] Optimize. -O for space, -OT for time, -OG for debugging.

-p processor Compile code for the specified processor.

-P Preprocess only (send result to .i files).

-Q Word align data in memory instead of default quad (double

word) alignment.

-r dir Use default linker command file in /usr/hp64000/env/dir

(\hpcc68k\env\dir for DOS) instead of the default.

-s Strip symbol table information (overridden by -g and -L).

-S Only generate assembly source files (with .s extensions).

-t c,name Insert subprocess c whose full path is name.

-u Consider non-constant static data uninitialized.

-U name Undefine name to the preprocessor.

-v Verbose (produce step-by-step description on stderr).

-w Suppress warning messages.

-W c,args Pass args as parameters to subprocess c.

Chapter 1: Getting Started

Summary of compiler options

Summary of file extensions

UNIX

Extension DOS

Extension Meaning Where generated

.a .lib Archive (library) file ar68k

.A .a HP 64000 format assembler symbol file as68k

.c .c C source file editor

.EA, .EB .ea, .eb Emulator configuration file emulator interface or

editor

.h .h Include (header) file provided or editor

.i .i "Preprocess only" output cc68k -P

.k .k Linker command file (default extension used by

cc68k) editor

.L .l HP 64000 format linker symbol file ld68k -h

.1 .txt On-line manual page provided

.o .obj HP-MRI IEEE-695 format relocatable object file as68k

.O .lst Listing file cc68k -L

.s .s Assembly language source file cc68k or editor

.x .abs HP-MRI IEEE-695 or Motorola S-Record absolute

object file (executable) ld68k

.X .x HP 64000 format absolute file (executable) ld68k -h (via cc68k -h)

.Ys — Symbol file directory emulator interface

Chapter 1: Getting Started

Summary of file extensions

To install the software on a UNIX workstation

1Load the software from the software media.

Instructions for installing the software are provided with the software media, or in

your operating system’s system administration guide.

2Set the HP64000 environment variable.

Set this variable to the location of the software, usually /usr/hp64000.

3Set the MANPATH environment variable.

Add $HP64000/man to this variable so that you can read the on-line "man pages."

4Set the PATH environment variable.

Add $HP64000/bin to your path so that you can run the compiler programs.

You should add these commands to your .login, .vueprofile, or .profile file (if they

are not there already) so that you won’t need to re-enter them every time you log in.

Examples If you installed the compiler in the root directory on an HP-UX system, enter:

export HP64000=/usr/hp64000

export PATH=$PATH:$HP64000/bin

export MANPATH=$MANPATH:$HP64000/man

On a Sun system, you would enter:

setenv HP64000 /usr/hp64000

setenv PATH $PATH:$HP64000/bin

setenv MANPATH $MANPATH:$HP64000/man

Chapter 1: Getting Started

To install the software on a UNIX workstation

To install the software on a PC (Windows)

To install from MS Windows:

1Start MS Windows in the 386 enhanced mode.

2Insert compiler Disk 1 into floppy disk drive A or B.

3Choose the File→Run... (ALT, F, R) command in the Windows Program Manager.

Enter "a:\setup" (or "b:\setup" if you inserted the floppy disk into drive B) in the

Command Line text box.

4Choose the OK button. Follow the instructions on the screen.

You will be asked to enter the installation path. The default installation path is

c:\hpcc68k. The default installation path is shown wherever files are discussed in

this manual.

5Edit your AUTOEXEC.BAT file.

The Setup program will create a file called AUTOEXEC.AXL which shows how to

set the PATH, HPCC68K, and HPAS68K variables in your AUTOEXEC.BAT file.

If you have multiple configurations or your AUTOEXEC.BAT file starts a shell or

Windows, be careful to place the SET and PATH commands at the appropriate

place in the file.

When you have edited the AUTOEXEC.BAT file, you need to reboot your

computer to set these environment variables.

Notes To follow the examples in this chapter, you need to get to a DOS prompt. You can

do this by leaving Windows or by opening an MS-DOS window.

You must use the Windows Setup program to install the compiler.

Unless otherwise noted, the example listings, file names, and paths in this manual

are for HP-UX systems. Use c:\hpcc68k in place of /usr/hp64000 or $HP64000.

DOS file extensions are listed on page .

Chapter 1: Getting Started

To install the software on a PC (Windows)

System requirements

The compiler requires the following configuration:

•An IBM Personal Computer, HP Vectra, or 100 percent compatible

•MS-DOS version 3.3 or later

•MS Windows version 3.0 or later

•An 80386 processor or higher

•4 Mbytes of available memory (RAM)

•Hard disk with at least 4 Mbytes of free space. At least 11 Mbytes is

recommended.

•A 1.2 Mbyte, 5.25-inch floppy disk drive or a 1.44 Mbyte, 3.5-inch floppy disk

drive

Chapter 1: Getting Started

To install the software on a PC (Windows)

To remove unnecessary files (UNIX only)

•If the compiler is using too much disk space, you can remove files for any

processors you will not be using.

You may remove the following files from the $HP64000 directory:

•lib/ccomprocessor

•lib/optprocessor

•lib/processor/*

•include/processor/*

where processor is any processor for which you will not need to compile any code.

Chapter 1: Getting Started

To remove unnecessary files (UNIX only)

To create a simple C program

•Use a text editor to create the file simple.c:

#include <stdio.h>

main()

{

char *str = "a string";

printf("\nThe string is: \"%s\"\n", str);

}

Figure 1-1. The "simple.c" Example Program

Chapter 1: Getting Started

To create a simple C program

To compile a simple program

•Use the cc68k comand at your host operating system prompt.

Example To compile the "simple.c" example program, enter the following command:

cc68k simple.c

This command generates the executable file a.out.x (or aout.abs for DOS) by

default. The compiler will generate the code for the 68000 by default.

The UNIX version of the compiler will print a warning message because a target

processor was not specified. Because this is just an example, ignore the warning.

Chapter 1: Getting Started

To compile a simple program

To generate an assembly listing

•Use the -L compiler option.

This option generates a listing of the C source, which includes the generated

assembly code, and a linker listing.

Example To generate the listings for "simple.c", enter:

cc68k -L simple.c

The mixed source and assembly listing is sent to file simple.O, and a linker listing

is sent to file a.out.O. (These files are named simple.lst and aout.lst if you are

using the compiler on a DOS system.)

Examine the simple.O file and note how:

•Addresses of strings are passed as parameters to the "_printf" support library

routine (String1+0 is pushed, then _printf is called).

•String literals are placed in the "const" section.

Now look at a.out.O and note that:

•The file shows the default linker command (generated by the compilation

control command).

•The linker command is followed by the contents of the default linker command

file. The default linker command file loads some libraries and an emulation

monitor or monitor stub.

•Modules are listed in the order they are loaded. Modules within library files

are listed in alphabetical order.

•The module crt0 is the program setup routine. Program execution will begin

with this routine.

Chapter 1: Getting Started

To generate an assembly listing

To specify addressing modes

•Use the -m command line option to specify the addressing mode for a section.

The 68000 C Compiler allows you to select the addressing modes used in the

generated assembly code for accessing data and calling functions (branches are

always done PC relative).

By default, the absolute long (the most flexible) addressing mode is used.

Addressing modes are selected using named sections (which are also used in the

linker when specifying load addresses).

To name sections in the source file, use the SECTION pragma.

Example To specify that program code and constants (the ROMable portion) be placed in

section MyProg and data be placed in section MyData, insert the line

#pragma SECTION PROG=MyProg DATA=MyData CONST=MyProg

at the beginning of the C source. These section names now apply not only to code

and data generated in the source file, but also to any extern functions or data

referenced in the file.

To specify that absolute short addressing be used from section MyProg to section

MyData, use "-m MyProg,MyData,as" ("as" is an abbreviation of absolute short).

This would be appropriate if MyData is located in the base page.

A simple example

To add two static integers and place the result in a third integer which is an extern:

#pragma SECTION PROG=MyProg DATA=MyData CONST=MyProg

extern int a;

int b,c;

main(){

a=b+c;

}

You can compile this example using the following command:

cc68k -LOc -m MyProg,MyData,as small.c

Chapter 1: Getting Started

To specify addressing modes

The small.O (small.lst for DOS) listing file looks like this:

Note that variables "a", "b", and "c" are accessed using the absolute short

addressing mode (indicated by the .W extension).

HPB3640-19300 68000 C Cross Compiler A.04.00 small.c

HPB3641-19300 A.02.00 19Apr93 Copr. HP 1988 Page 1 Mon Apr 26 15:09:55 1993

Command line: as68k -Lfnot,llen=1100 -o small.o /tmp/ct3CAAa27665

Line Address

CHIP 68000

NAME small

* MKT:@(#) B3640-19300 A.04.00 MOTOROLA 68000 FAMILY C

CROSS COMPILER

* Assembler options:

OPT BRW,FRL,NOI,NOW

* Macro definition for calling run-time libraries:

* bytes per call = 6

CALL MACRO routine

XREF routine

JSR (routine).L

ENDM

SECT MyProg,2,C,P

1 #pragma SECTION PROG=MyProg DATA=MyData CONST=MyProg

2 extern int a;

3 int b,c;

4 main(){

XDEF _main

_main

5 a=b+c;

00000000 2038 0000 R MOVE.L (_b+0).W,D0

00000004 D0B8 0004 R ADD.L (_c+0).W,D0

00000008 21C0 0000 E MOVE.L D0,(_a+0).W

6 }

functionExit1

returnLabel1

0000000C 4E75 RTS

XREF MyData:_a

SECT MyData,2,D,D

XDEF _b

ALIGN 2

00000000 ==00000004=of= DCB.B 4,0

XDEF _c

ALIGN 2

00000004 ==00000004=of= DCB.B 4,0

END

Chapter 1: Getting Started

To specify addressing modes

Next, change the example slightly to put variable "a" in another section (the default

is data)

extern int a;

#pragma SECTION PROG=MyProg DATA=MyData CONST=MyProg

int b,c;

main(){

a=b+c;

}

Compile the same way as before. Variable "a" will be declared external in section

data and referenced absolute long rather than absolute short (as indicated by the .L

extension).

An example using A5 relative addressing

A5 relative addressing allows accessing data values as offsets from an address

loaded into the A5 address register at program startup. The most common use of

this addressing mode is to create a second "basepage" (that is, a 64K byte block of

memory that can be accessed more efficiently than by absolute addressing). For

example, here is a short program that accesses variable "x" using absolute long

addressing, variable "i" using absolute short addressing, and variable "q" using A5

relative addressing:

int x;

#pragma SECTION DATA=0x400 BP

int i;

#pragma SECTION DATA=SecondBasePage

int q;

main(){

x=q+i;

}

You can compile this program using the following command:

cc68k -LOc -m all,SecondBasePage,a5s short.c

The SECTION pragma used to locate variable "i" specifies an absolute address

where "i" is "ORG’d" and the appended "BP" tells the compiler that the address is

on basepage (and, thus, to use absolute short addressing). The -m option specifies

that all references to the section named SecondBasePage be done A5 relative short.

In addition to the addressing mode selection, for A5 relative addressing, the linker

must be told the run-time value of A5. This is accomplished via an INDEX

command in the linker command file such as:

INDEX ?A5,SecondBasePage+$8000

The setup routine (crt0) initializes A5 to the value assigned by the linker to special

symbol ?A5. In this case, A5 will be initialized to the address 8000(hex) above the

Chapter 1: Getting Started

To specify addressing modes

start of the section named SecondBasePage. This allows up to 64K bytes of data in

section SecondBasePage to be accessed A5 relative short.

An example using PC relative addressing

The PC relative addressing mode is most commonly used for branches (which are

always done PC relative on the 68000), function calls, and reads of constant data.

The 68000 does not support PC relative writes, but the compiler does synthesize

this "addressing mode" using multiple instructions. When a group of mutually

referencing functions fits into 64K bytes, it is more efficient to use PC relative

short calls between them.

If you would like to see an example, create this program:

int f(int i);

main() {

int i,x;

i=f(x);

}

int f(int i) {

return i*2;

}

Then compile the program:

cc68k -LOc -m prog,prog,pcs pcs.c

Here, function "f" is called PC relative short (rather than the default "JSR

(_f+0).L"). By combining PC relative and A5 relative addressing modes, one can

create a variety of position independent code modules.

An example using run-time and support libraries

Run-time library routines are called implicitly by the generated assembly code (for

example, dtoi is called to cast a double to an int). Since these implicitly called

routines are not visible in the C source, a special section named lib is reserved and

understood by the compiler to be the section in which run-time libraries are

defined. Furthermore, a restriction is placed on addressing modes used to call

run-time libraries: all calls to run-time libraries from a single C source file must use

the same addressing mode. For this reason, all is the only section allowed in a -m

option specifying lib as its destination (use -m all,lib,mode).

Support library routines, unlike run-time library routines, are called explicitly in the

C source. Thus, they behave just as though they were user-written functions from

Chapter 1: Getting Started

To specify addressing modes

an addressing mode specification point of view. Their section names are the same

as the base name of the library (for example, libc.a’s section is libc).

On the PC host, there is only one library (lib and libc come from the same library

file).

For example, assume that the run-time library lib.a (named section lib) is located

on base page and that the support library libc.a (named section libc) is loaded in

the same 32K byte memory block as the following program:

To call run-time library routines using the absolute short addressing mode and

support library routines using the PC relative short addressing mode, you might

compile the program using the command line

cc68k -LOc -m all,libc,pcs -m all,lib,as libcalls.c

Note that it is important to use "#include <stdio.h>" since without it the compiler

does not know that "printf" is in named section libc.

Chapter 1: Getting Started

To specify addressing modes

To specify the target microprocessor

•Name the target microprocessor on the command line using the -p option.

You can specify the following target processors:

•68000

•68EC000

•68HC000

•68HC001

•68010

•68302

•68020

•68EC020

•68030

•68EC030

•68040

•68EC040

•68331

•68332

•68340

•68360

•CPU32

Example To compile the example program for the 68020, enter

cc68k -p 68020 simple.c

To always compile for the 68020, enter:

export CC68KOPTS="-p 68020"

This is the same as entering "-p 68020" on the command line every time you use

cc68k. Use setenv instead of export on Sun systems. Use set instead of export on

DOS systems.

Chapter 1: Getting Started

To specify the target microprocessor

To compile for a debugger

To gain the most benefit from HP debuggers and emulators, follow these

guidelines:

•Use the -OG option to generate debugging information.

•Avoid optimizing modes (-O or -OT).

•Turn off the automatic creation of register variables (-Wc,-F).

•Do not use the -h option. HP debuggers now use .x (.abs for DOS) rather than

.X files.

•Use the C compiler’s floating point library routines to generate code that will

run interchangeably in both the debugger/simulator and the debugger/emulator.

•Use the same environment files as you would use to compile for an HP

64700-series emulator.

Example To compile the simple.c program to be run in a debugger, use the following

command:

cc68k -LM -OG simple.c

See Also See the User’s Guide for your debugger/emulator, debugger/simulator, or emulator

interface for information on how to run a program in the debugger or emulator

environment.

Chapter 1: Getting Started

To compile for a debugger

To use a makefile (UNIX systems only)

The UNIX make command can simplify the process of compiling your programs.

This command allows you to specify which files are dependent on which other files

(for example, make "knows" that files which end in .o are produced by compiling

corresponding files that end in .c or by assembling programs that end in .s). If your

host operating system is HP-UX, see the man page for make in section 1 of the

HP-UX Reference Manual. See also "Make, a Program for Maintaining Computer

Programs" in the "Programming Environment" volume of HP-UX Concepts and

Tutorials.

Because cc68k is similar to the host cc command, it is easy to tell make how to

compile, assemble, and link using cross tools. To any makefile designed for the

host, you need to add some definitions and set up some options. These are:

CC=/usr/hp64000/bin/cc68k

AS=/usr/hp64000/bin/as68k

LD=/usr/hp64000/bin/ld68k

These definitions will cause make’s "built-in" rules to access the cross tools, and

because the built-in options mean the same thing to the cross tools as they do to the

host tools, the built-in rules now work when invoking the cross tools.

Note The SunOS make command adds a "-target" option to the compiler command line.

To remove this option, add the following statement to the beginning of the

makefile:

COMPILE.c= $(CC) $(CFLAGS) $(CPPFLAGS) -c

Make also has a mechanism for passing additional options to the compiler,

assembler, and linker. The additional options are passed each time the program is

invoked and are thus set only for "global" options. For example, to always have the

compiler and assembler produce listings, one might use:

CFLAGS = "-L"

ASFLAGS = "-Lfnot"

Some versions of make give default values for these options.

Here is an example makefile:

# These definitions are added to use the cc68k cross tools.

CC = cc68k

Chapter 1: Getting Started

To use a makefile (UNIX systems only)

# All object files (make knows how to generate them from

# sources based on implicit rules).

OBJECTS = main.o file1.o grammar.o

# This dependency links the program together.

program.x: $(OBJECTS)

$(CC) $(OBJECTS) -o program.x

# This dependency causes make to recompile file1.c

# whenever file1.h has been touched.

file1.o: file1.h

When run in a directory containing sources:

main.c file1.c grammar.y file1.h

The commands generated by HP-UX make will be:

cc68k -O -c main.c

cc68k -O -c file1.c

yacc grammar.y

cc68k -O -c y.tab.c

rm y.tab.c

mv y.tab.o grammar.o

cc68k main.o file1.o grammar.o -o program.x

This example assumes that /usr/hp64000/bin has been added to your PATH

environment variable.

You can see what commands will be generated by make by using the following

command:

make -n

Chapter 1: Getting Started

To use a makefile (UNIX systems only)

To modify environment libraries

To modify the environment-dependent library env.a (env.lib for DOS), the startup

routines crt0.o or crt1.o (crt0.obj or crt1.obj for DOS), or the monitor stub

mon_stub.o (mon_stub.obj for DOS):

1Copy the source files.

The following command copies the environment-dependent source files to the

current directory. The "." just before the return means that the names of the files

are not changed.

cp /usr/hp64000/env/hp

<emulator_environment>

/src/* .

Or, on a DOS system, enter:

copy c:\hpcc68k\env\hp

<emulator_environment>

\src\* .

2Edit the source files.

The following command changes the permissions of the source files so that you

will be able to save any changes you make while editing the files.

chmod 644 *

Or, on a DOS system, enter:

attrib -r *.*

Now you may edit the source files as needed.

3Set up the directory structure for "Makefile". (UNIX only)

The make utility will be used to create a new environment dependent library

which contains the changes made to the source files. As provided, Makefile

assumes there are two directories under the directory in which it resides, "src" and

"obj". Makefile also assumes that all source files are in the "src" directory. The

following commands set this situation up.

Chapter 1: Getting Started

To modify environment libraries

mkdir src

mkdir obj

mv *.s *.c src

4Run the "make" command. (UNIX only)

The following command will create a new environment-dependent library file

env.a, new startup modules crt0.o and crt1.o, and the monitor stub mon_stub.o,

and will place them in the current directory.

make all

In addition to the all target, other targets are available for the make command

which will create only those files needed. A list of these available targets is

displayed by the following command.

make help

The following command will remove unnecessary intermediate files left by the

make all command.

make clean

5Compile all of the source files. (DOS only)

For example, to compile for the 68020, enter:

\hpcc68k\cc68k -p 68020 -Ou -Wc,-i -c *.c

\hpas68k\as68k -fnod -fp=68020 *.s

6Create the env.lib library. (DOS only)

Create a temporary file "ar_cmd", similar to the following:

CREATE env.lib

ADDMOD disp_msg.obj

ADDMOD trap.obj

ADDMOD getmem.obj

ADDMOD heap.obj

ADDMOD stack.obj

ADDMOD startup.obj

ADDMOD open_file.obj

ADDMOD systemio.obj

ADDMOD sbrk.obj

ADDMOD fpu_trap.obj

Chapter 1: Getting Started

To modify environment libraries

SAVE

END

Add fpu_trap.obj only for the 68020, 68030, or 68040.

Next, use ar68k to make the library file:

\hpas68k\ar68k < ar_cmd

7Modify the default linker command file.

The following UNIX commands copy the default I/O linker command file to the

current directory so that you can edit it to load the environment file just created.

(Copy linkcom.k if your programs do not use I/O.)

cp /usr/hp64000/env/hp

<emulator_environment>

/iolinkcom.k .

chmod 644 iolinkcom.k

vi iolinkcom.k

Change the line which reads

LOAD /usr/hp64000/env/hp

<emulator_environment>

/env.a

LOAD env.a

The equivalent DOS commands are:

copy c:\hpcc68k\env\hp

<emulator_environment>

\iolinkco.k

attrib -r iolinkco.k

edit iolinkco.k

LOAD env.lib

Similarly, if you have modified the startup module source file crt0.s or crt1.s, or

the monitor stub mon_stub.s, you should also change the linker command file so

that it loads the local version instead of the shipped version.

Specifying the modified linker command file when compiling your program (with

the -k option) will cause the linker to call in routines from the modified

environment-dependent library.

Chapter 1: Getting Started

To modify environment libraries

About environment libraries

Many files are linked into the C program from the environment libraries. These

libraries reside in the subdirectories of /usr/hp64000/env (\hpcc68k\env for DOS)

and are designed to support the emulator (and simulator, if available). But these do

more than just help you use the emulator.

The C compiler has only limited information about the environment in which

compiled programs will ultimately execute. All the high level functions depend on

the environment libraries to provide the low level hooks into the execution

environment (or target system). The supplied environment libraries provide the

hooks necessary to operate in the emulator environment. They also serve as a

pattern for you to create your own low level hooks to allow the C compiler to work

in your own execution environment. You may either modify our environment files

(the source code is provided) or use the files as a pattern to create your own

equivalent files. HP has made every effort to narrow this "hook-up point" as much

as possible, but you will need to make some modifications in order to run your

programs in your own execution environment.

Chapter 1: Getting Started

To modify environment libraries

To view the on-line man (help) pages

•On a UNIX system, use the man command.

•On a DOS system, use the more command or an editor.

You can display on-line "man pages" for any of the programs which make up the

Motorola 68000 Family C Cross Compiler:

•cc68k

•cpp68k

•clst68k

Refer to the on-line man pages for detailed information about command-line

options and compiler directives.

Because the man pages contain important information which is not included in this

manual, HP recommends that you print the cc68k man page and keep it near your

computer.

On UNIX systems, the man pages are in the directory $HP64000/man. If the man

command cannot find the man pages, check that you have added this directory to

the MANPATH environment variable.

On DOS systems, the help files are in the directory \hpcc68k.

Example (UNIX) To view the cc68k on-line manual page, type the following command from

the operating system prompt:

man cc68k

(DOS) To view the cc68k help file, type the following command at the DOS

prompt:

more < c:\hpcc68k\cc68k.txt

Information on the cc68k compiler syntax and options will be scrolled onto your

display.

Chapter 1: Getting Started

To view the on-line man (help) pages

Chapter 1: Getting Started

To view the on-line man (help) pages

Part 2

Compiler Reference

Part 2

C Compilation Overview

An overview of the Motorola 68000 Family C Cross Compiler and a description of

the ANSI C language.

Chapter 2: C Compilation Overview

Execution Environment Dependencies

Providing the "standard I/O" and storage allocation C library functions creates

dependencies on the environment in which programs execute.

Since the C compiler is a tool to help you develop software for your own target

system execution environments, HP has been careful about any execution

environment dependencies associated with this compiler or its libraries.

The compiler provides the "standard I/O" and storage allocation library functions;

therefore, there are some environment dependencies to be aware of. The compiler

isolates these environment dependencies to make it easier to tailor the compiler to

your own target system execution environment.

The execution environment-dependent routines provided with the C compiler are

written to work in the HP development environments, but they need to be rewritten

for target system execution environments.

Chapter 2: C Compilation Overview

Execution Environment Dependencies

C Compilation Overview

An overview of the C compiler is shown in figure 2-1. The entire process is

controlled by the command line fed to the compilation control routine. Rectangles

in the diagram represent either data provided by the programmer (C source file, for

example) or data produced by one of the circular processes (output listing, for

example). Each process is described following the figure.

In the following figure, the names of programs appear in parentheses. These names

refer to the cross tools, and not to the native tools. For example, "cc" refers to

cc68k cross compiler and not to the native host cc compiler.

Chapter 2: C Compilation Overview

C Compilation Overview

Figure 2-1. C Compilation Overview

Chapter 2: C Compilation Overview

C Compilation Overview

Compilation Control Routine

The entire system is controlled by a compilation control routine, cc68k. The

compilation control routine calls in sequence: the C preprocessor (cpp68k), the C

compiler (ccom68xxx on UNIX systems or ccm68xxx on DOS systems), optionally

the peephole optimizer (opt68xxx), the assembler (as68k), optionally the lister

(clst68k), and the linker (ld68k). Many of these programs may be run individually

using the cc68k command’s options. See the on-line man pages for the description

of the command syntax and options.

The librarian (ar68k) is a separate tool for building archive files used by the linker.

C Preprocessor

The 68000 family C preprocessor accepts C preprocessor directives which modify

the source code that the compiler sees. This modification includes expansion of

include files, expansion of macros, and management of conditional compilation.

See the on-line man page for a description of the C preprocessor.

C Compiler

The C compiler accepts C language as defined by the ANSI C Standard. The

compiler performs a translation with optional optimizations (see the

"Optimizations" chapter) and emits an assembly language source file containing

embedded directives which provide information to be used by the lister and later by

the debugger and analyzer (see the "Compiler Generated Assembly Code" chapter).

The compiler also emits error and warning messages to the standard error output.

These messages include the original source line on which the error occurred with a

pointer to the offending token.

Peephole Optimizer

The peephole optimizer is run when the "optimize" command line option is

specified. It performs peephole optimization on the assembly output of the

compiler. The optimizer makes allowances for volatile data types and embedded

assembly code to avoid changing the functionality of the generated code. The

optimizer works properly only on compiler-generated assembly code and is not a

stand alone tool for use on hand-written assembly code. Refer to the

"Optimizations" chapter for more information on the peephole optimizer.

Chapter 2: C Compilation Overview

C Compilation Overview

Assembler

The assembler is the HP B3641 assembler which accepts an assembly language

source file (optionally containing symbolic debug information defined by special

directives) and produces an object code file (optionally containing a representation

of the symbolic debug information from the assembly source) and an optional

listing for use by the lister in generating the final listing. The assembler also has a

switch for generating HP 64000 format assembler symbol files.

Source File Lister

The source file lister is run when the "listing" command line option is specified.

The lister uses the assembler source or listing, C source file, and include files to

produce a listing. The listing includes embedded assembly language and,

optionally, expanded include files and a cross reference table. The lister is

controlled by "*LINE*" directives inserted by the compiler into the output

assembly code. Because the lister is usually run by the compilation control routine,

details of the lister directives are not described in this manual. See the on-line man

page for the description of clst68k command syntax and options.

Librarian

The librarian is the HP B3641 librarian which combines several object code files

(generated by the assembler) into an archive file which the linker will search when

it tries to resolve external references. The libraries that are part of the compiler

product are made with this librarian.

Linker

The linker is the HP B3641 linker which accepts several object code or archive

files (generated by the assembler or librarian, respectively) and creates an absolute

file containing all object code and symbols to be loaded. Optional load maps may

be generated as well as HP 64000 format linker symbol and absolute files.

Chapter 2: C Compilation Overview

C Compilation Overview

ANSI Extensions to C

The B3640 Motorola 68000 Family C Cross Compiler complies with ANSI/ISO

standard 9899-1990. In some cases, programs which compile with no errors on old

C compilers will result in errors or warnings with this compiler. Although this may

seem inconvenient, modifying the source will result in portability to other ANSI

standard C compilers.

Assignment Compatibility

The ANSI standard has more carefully regulated assignment compatibility. In

particular, pointers and integers are no longer considered to be assignment

compatible without casts, and pointers to different typed objects are not assignment

compatible without casts.

Pointers and Integers

Because assignments between pointers and integers occur often in many existing C

programs, such assignments are warned rather than being flagged as errors by the

Motorola 68000 Family C Cross Compiler. It is still recommended practice not to

perform such assignments without casts.

Pointers and Pointers

The assignment of a "pointer to one type" to a "pointer to another type" only

generates a warning message. However, the ANSI standard has provided a new

type (void) to which a pointer may point; the resulting "pointer to void" may be

assigned to any pointer.

Function Prototypes

Function prototypes allow you to specify the types of function parameters and

whether a function accepts variable parameters. They allow the compiler to check

the consistency of parameter types between declarations and calls of a function in a

file. Because the linker does not check for incompatible calls across file

boundaries, we recommend that you use an include file to declare the function at all

reference and definition points.

Function prototype information is used by the compiler to generate more efficient

code by not widening passed parameters. That is, short and char passed

Chapter 2: C Compilation Overview

ANSI Extensions to C

parameters are not widened to int; and float parameters are not widened to double,

as is the case in the absence of function prototypes.

Old style function declarations (those without any parameter information) continue

to have the same meaning as before. All short and char parameters are widened to

int, and all float parameters are widened to double at the function call. The

appropriate inverse conversions are performed at function entry. Old style and

prototype declarations for the same symbol can coexist as long as all of the

parameter types specified in the prototype are the widened types and as long as the

ellipsis is not used. It is good practice to convert all declarations to prototype

syntax if prototypes are going to be used.

The consistency checking between the type of expression passed as a parameter to

a prototyped function and the declared type of the corresponding parameter

requires that the two types be assignment compatible. The parameter expression

will be converted to the formal parameter type prior to its value being passed.

The following is an example of function prototype usage:

extern int printf(const char *format, ...);

/* Note the optional use of identifier "format" to document the parameter’s

meaning. The ellipsis indicates zero or more additional parameters. */

extern float float_operation(float,float);

/* In this case, only type names are given for the parameters. */

/* The following is the prototype syntax for a function definition. */

void func(int i)

{

float f;

f = float_operation(i, 2.0);

/* The int "i" and the double "2.0" will be converted to float

before being passed (the "2.0" is converted at compile time).

Both parameters are passed as floats without the expensive

run time conversion to double which old style functions cause. */

}

Pragmas

Pragmas are special preprocessor directives which allow compilers to implement

special features. By definition, any pragma that a compiler does not understand

will be ignored. However, because pragmas allow compilers to deviate from the

standard, their number has been kept to a minimum.

Chapter 2: C Compilation Overview

ANSI Extensions to C

The pragmas which the C compiler understands are listed below. Pragmas which

are not recognized cause a warning message to be written to the standard error

output.

#pragma SECTION

Provides for renaming the default program section names. (Refer to the "Section

Names" section of the "Embedded Systems Considerations" chapter for more

information.)

#pragma ASM/END_ASM

Provides for including assembly language in the C source file. (Refer to the "Using

Assembly Language in the C Source File" section of the "Compiler Generated

Assembly Code" chapter for more information.)

#pragma FUNCTION_ENTRY/EXIT/RETURN "C_string"

Provides for including assembly language instructions in the function entry and exit

code of the compiler-generated assembly code. (Refer to the "Using Assembly

Language in the C Source File" section of the "Compiler Generated Assembly

Code" chapter for more information.)

#pragma INTERRUPT

Provides for implementing functions as interrupt routines. (Refer to the

"Implementing Functions as Interrupt Routines" section of the "Embedded Systems

Considerations" chapter for more information.)

#pragma ALIAS

Provides for the naming of an assembly language symbol associated with a C

source file symbol. (Refer to the "Assembly Language Symbol Names" section of

the "Compiler Generated Assembly Code" chapter for more information.)

The

void

Type

A new type, void, has been added by ANSI. It has two fundamental purposes. The

first is to allow a function to be defined to have no return value (i.e., a procedure).

Since void typed objects cannot be assigned to other objects, such procedures

cannot be used in a context where a return value is required. (Of course, the

Chapter 2: C Compilation Overview

ANSI Extensions to C

protection afforded by this mechanism is limited to programs where functions are

declared with a void return type using old style declarations or function prototypes.)

The second use of type void is to declare generic pointers. By definition, pointers

to void, e.g., "void *genericPtr;", are assignment compatible with pointers to any

other type. This can also be a convenient type for the return type of a function such

as malloc whose result is then assignment compatible with any pointer.

The

volatile

Type Modifier

The type modifier volatile specifies that a particular variable’s value may change

from one read to another or following a write. An obvious example of such a

"variable" is an I/O port in an embedded system. The volatile type modifier

informs the compiler of this behavior so that the compiler can avoid performing

optimizations which assume that variables’ contents are not changed unexpectedly.

(Refer to the "Effect of volatile Data on Peephole Optimizations" section in the

"Optimizations" chapter; also, refer to "The volatile Type Modifier" section in the

"Embedded Systems Considerations" chapter for examples of its use.)

Chapter 2: C Compilation Overview

ANSI Extensions to C

The

const

Type Modifier

An object declared with the const type modifier tells the compiler that the object

cannot be assigned to, incremented, or decremented; statements which attempt to

do so will cause errors. Pointers to const storage cannot be assigned to pointers to

non-const storage. Objects declared with the const type modifier can be accessed,

but they cannot be written to. An object declared with the const type modifier,

which has static storage class, is placed in the CONST section (see the "#pragma

SECTION" section in the "Embedded Systems Considerations" chapter). Some

examples of how the const type modifier is used follow.

static const char message[][7] = {

"First ",

"Second",

"Third "

};

const char *cnst_chr_ptr; /* The pointer may be modified, */

/* but that which it points to */

/* may not. */

char *const ptr; /* The pointer may not be modified,*/

/* but that which it points to may.*/

const char *const ptr; /* Neither the pointer nor that */

/* which it points to may be */

/* modified. */

Chapter 2: C Compilation Overview

ANSI Extensions to C

Translation Limits

The ANSI C Standard has set standard translation limits which must be met or

exceeded by conforming implementations. The following list meets or exceeds all

such limits put forth by the standard.

•Approximately 50 nesting levels in compound statements, iteration control

structures, and selection control structures.

•Unlimited levels of nesting in preprocessor conditional compilation blocks.

•Approximately 100 pointer, array, and function declarators modifying a basic

type in a declaration.

•Limited to 128 levels of expression nesting.

•There are 255 significant case-sensitive characters in an internal identifier.

•There are 255 significant case-sensitive characters in a macro name.

•There are 30 significant case-sensitive characters in an external identifier.

•Limited to 231-1 bytes of local variables in one function block.

•Unlimited simultaneous macro definitions.

•Limited to 231–1 bytes of parameters in function definition and call.

•Limited to 127 parameters in preprocessor macro.

•Limited to 1024 characters in a logical source line.

•1023 characters in a single string literal (1024 including a trailing null

character). There is no limit on the size of string made from adjacent string

literals.

•Limited to 231-1 byte-sized objects.

•Unlimited nesting levels of include files.

•Unlimited number of cases in a switch statement.

•Size of the switch statement body is limited to 32767 bytes of generated code

unless the "big switch tables" option to cc68k is specified (in which case, the

size of the switch statement body is limited only by the size of the processor

address space).

Chapter 2: C Compilation Overview

ANSI Extensions to C

Internal Data Representation

How arithmetic and derived data types (arrays, pointers, structures, etc.) are

represented in memory.

Chapter 3: Internal Data Representation

This chapter does not describe how to use data types in your programs. Refer to

The C Programming Language for information such as escape sequences, printf

conversions, and declaration syntax.

Arithmetic Data Types

The arithmetic data types are listed in the following table:

The integral data types (char, short, int, and long) are signed by default; however,

they may be used in combination with the unsigned keyword to yield unsigned

data types (unsigned by itself means unsigned int). All integral data types use

two’s complement representation.

Floating-Point Data Types

Floating-point data types are stored in the IEEE single and double precision

formats. Both formats have a sign bit field, an exponent field, and a fraction field.

The fields represent floating-point numbers in the following manner:

Floating-Point Number = <sign> 1.<fraction field> x 2(<exponent field> - bias).

Sign Bit Field. The sign bit field is the most significant bit of the floating-point

number. The sign bit is 0 for positive numbers and 1 for negative numbers.

Type # of Bits Range of Values (Signed) (Unsigned)

char 8 –128 to 127 0 to 255

short 16 –32768 to 32767 0 to 65535

int 32 –2147483648 to 2147483647 0 to 4294967295

long 32 –2147483648 to 2147483647 0 to 4294967295

float 32 +/– 1.18 x 10-38 to +/– 3.4 x 1038

Table 3-1. Arithmetic Data Types

Chapter 3: Internal Data Representation

Arithmetic Data Types

Fraction Field. The fraction field contains the fractional part of a "normalized"

number. "Normalized" numbers are greater than or equal to 1 and less than 2. Since

all normalized numbers are of the form "1.XXXXXXXX", the "1" becomes

implicit and is not stored in memory. The bits in the fraction field are the bits to the

right of the binary point, and they represent negative powers of 2. For example:

0.011 (binary) = 2-2 + 2-3 = 0.25 + 0.125 = 0.375.

Exponent Field. The exponent field contains a biased exponent; that is, a

constant bias is subtracted from the number in the exponent field to yield the actual

exponent. (The bias makes negative exponents possible.)

If both the exponent field and the fraction field are zero, the floating-point number

is zero.

NaN. A NaN (Not a Number) is a special value which is used when the result of

an operation is undefined. For example, adding positive infinity to negative

infinity results in a NaN.

Float

The float data type is stored in the IEEE single precision format which is 32 bits

long. The most significant bit is the sign bit, the next 8 most significant bits are the

exponent field, and the remaining 23 bits are the fraction field. The bias of the

exponent is 127. The range of single precision format values is from 1.18 x 10-38 to

3.4 x 1038. The floating-point number is precise to 6 decimal digits.

31 30 23 22 0

S Exp. + Bias Fraction

0 000 0000 0 000 0000 0000 0000 0000 0000 = 0.0

0 011 1111 1 000 0000 0000 0000 0000 0000 = 1.0

1 011 1111 1 011 0000 0000 0000 0000 0000 = -1.375

1 111 1111 1 111 1111 1111 1111 1111 1111 = NaN (Not a Number)

Chapter 3: Internal Data Representation

Arithmetic Data Types

Double

The double data type is stored in the IEEE double precision format which is 64 bits

long. The most significant bit is the sign bit, the next 11 most significant bits are

the exponent field, and the remaining 52 bits are the fraction field. The bias of the

exponent is 1023. The range of double precision format values is from 2.23 x

10-308 to 1.8 x 10308. The floating-point number is precise to 15 decimal digits.

63 62 52 51 0

S Exp. + Bias Fraction

0 000 0000 0000 0000 0000 0000 ... 0000 0000 0000 0000 = 0.0

0 011 1111 1111 0000 0000 0000 ... 0000 0000 0000 0000 = 1.0

1 011 1111 1110 0110 0000 0000 ... 0000 0000 0000 0000 = -0.6875

1 111 1111 1111 1111 1111 1111 ... 1111 1111 1111 1111 = NaN

Precision of Real Number Operations

In the absence of the "generate code for the 68881/2" command line option, all real

number operations are accomplished by calls to the real number routines

(described in the "Conversion" and "Floating-Point Routines" sections of the

"Run-Time Library Description" chapter) or to math library routines which

eventually call run-time library routines. With the "generate code for the 68881/2"

command line option, most real number operations are performed in-line with

68881/2 instructions.

All of this has a subtle effect on the precision of floating-point results.

Without the 68881/2. When routines are used to perform floating-point

operations, all intermediate results are truncated to 64-bit precision immediately,

and no 80-bit intermediate results are carried on into subsequent calculations. The

precision of the results reflects this implementation.

With the 68881/2. When the "generate code for the 68881/2" (-f) command line

option is used, many intermediate results are kept with 80 bits of precision and are

passed on into subsequent operations without truncation. The 68881/2 itself

supports a mode in which these results are automatically truncated; however, an

execution speed penalty is incurred. Thus, it is important to understand, when using

the "generate code for the 68881/2" command line option, that results will differ

from those produced without the option.

Chapter 3: Internal Data Representation

Arithmetic Data Types

Characters

In addition to the char type, the C compiler supports wide (extended) characters

with the wchar_t type. The wchar_t type is implemented as unsigned long.

Constants in the extended character set are written with a preceeding L modifier.

Library routines which support wide characters are described under mblen in the

"Libraries" chapter.

Multi-byte characters are not supported.

If a multi-character constant (for example, ’abc’) is encountered, the compiler

multiplies the value of the first character by 256 and adds the value of the second

character. If there are remaining characters, the new value is multiplied by 256 and

the next character is added until no more characters are left. (Some previous

versions of the compiler technology simply accepted the first character and

discarded the others.)

Chapter 3: Internal Data Representation

Arithmetic Data Types

Derived Data Types

The following objects are derived data types. The sizes of each data type (or the

calculation used to determine the size) are listed.

Pointers 32-bits.

Arrays (Number of elements)*(Size of one element).

Structures Sum of the sizes of each member. (Members, as well as the

structure itself, may be padded for alignment.)

Unions Size of the largest member. (This member, as well as the

union itself, may be padded for alignment.)

Enum types 1, 2, or 4 bytes depending on the constant values of the

elements.

Pointers

Pointers are addresses which point to stored values. Pointers occupy four bytes and

are aligned on four-byte boundaries (two-byte boundaries for the 68000 and

68332). The following program is a simple example of how pointers are used.

main()

{

int value;

int *ptr /* "ptr" is of type pointer to "int". */

value = 256;

ptr = &value; /* "ptr" = the address of the location */

/* at which "value" is stored. */

}

Arrays

Arrays are made up of a fixed number of elements of the same type.

Multi-dimensional arrays can be thought of as arrays of arrays (of arrays, etc.)

where each array represents a single dimension. Index values for each dimension

are used to access the elements of a multi-dimensional array.

Chapter 3: Internal Data Representation

Derived Data Types

The amount of storage allocated for an array is the sum of the space used by all its

elements. An array is aligned on the alignment boundary of its elements. For

example, a short array with 10 elements would use 20 bytes and be aligned on a

two byte boundary.

The first element of a one-dimensional array (index equals zero) is located at the

lowest address of the storage allocated for the array. Elements of multi-dimensional

arrays are stored in row-major order (in other words, the rightmost index changes

more rapidly with successive memory locations).

The following program shows some simple arrays.

float fpns[10]; /* 10*4 = 40 Bytes of storage allocated */

main()

{

int array[4][7]; /* 4*7*4 = 112 Bytes allocated */

int i, j; /* on the stack. */

fpns[1] = 1.0;

for (i = 0; i < 4; i++)

for (j = 0; j < 7; j++)

array[i][j] = 0;

}

Chapter 3: Internal Data Representation

Derived Data Types

Strings

Strings are a sequence of characters or escape sequences enclosed in double quotes

("). Strings may be used in two distinct contexts. The first is in C program

statements or as intitializers of type char * where they are treated as if they are of

type "const char *". For example:

char *p, *q = "abc";

p = "xyz";

When used in such a context, the compiler places the string, together with an

additional NULL (0) termination character, in the named CONST linker section

(named "const" by default).

The second context in which strings may be used is as initializers of arrays of char.

If the initialized array is an automatic, the initialization occurs at run-time, and the

compiler places the string and NULL terminator in the named CONST linker

section just as above. If, however, the array being initialized is a static, the

initialization occurs at load-time (or is in ROM). For example:

const char string[] = "abcdefghi";

When a string is used to initialize an array, the compiler places the initialized array

in either the named DATA linker section (if the array’s type is not "const") or in

the named CONST linker section (if the array’s type is "const"). A terminating

NULL (0) character is appended to the string only if there is room in the declared

array (or if it is "open" as above).

Note Trying to change the value of a string constant may cause unwanted side effects.

The reason for this is explained in the "Optimizations" chapter.

The compiler accepts hexadecimal escape sequences of unlimited length. The

example below is interpreted as a single hex value:

*str = "\x064f";

In order to produce the string "df", you could modify the string in the following

way:

*str = "\x064" "f";

Chapter 3: Internal Data Representation

Derived Data Types

Structures

Structures are named collections of members. Structure members may be of

different types, they may be specified as bit fields, or they may even be pointers to

the structure in which they are defined (self-referential structures).

Structures may be passed as parameters to and returned from functions. (See the

"Stack Frame Management" section of the "Compiler Generated Assembly Code"

chapter for more information on how structures are passed to and returned from

functions.)

The amount of storage allocated for a structure is the sum of the space required by

all its members, the alignment padding between members, and padding at the end

of the structure to make its size a multiple of four (two) bytes. For example, a

structure whose members are a char, an int, and a double would be allocated 16

bytes (three bytes following the char are "wasted" to align the int). (For the 68000

and 68332, 14 bytes are allocated—one byte following the char is "wasted" to

align the int). Members are located in the allocated space in the order that they are

declared.

An example of a simple structure follows.

struct example { /* 16 bytes of storage allocated at 4-byte boundary. */

char c; /* First byte of structure. */

int i; /* Begins at 5th byte of structure. */

double d; /* Begins at 9th byte of structure. */

} var;

main()

{

var.c = ’a’;

var.i = -1;

var.d = 1.0;

}

For the 68000 and 68332 processors, struct example uses 14 bytes of storage

allocated at a 2-byte boundary. int i begins at the 3rd byte of the structure and

double d begins at the 7th byte of the structure.

See the "Alignment Considerations" section for information on how the -Q option

affects member alignment.

Chapter 3: Internal Data Representation

Derived Data Types

Bit Fields

Bit fields are structure or union members which are defined as a number of bits. A

colon separates the length of a bit field from the declarator. Bit fields can be signed

(declared as plain integral types) or unsigned (declared as unsigned integral types).

All integral types are allowed in bit field declarations, but are converted to int or

unsigned int. The high order bit of a signed bit field is the sign bit.

Bit fields are packed from the high-order bits to the low-order bits in the words of

memory they occupy. Bit padding can be generated by omitting the name from the

bit field declaration. Consecutive bit fields are packed adjacently regardless of

integer boundaries. However, a bit field with a specified width of zero will cause

the following bit field to start on the next int (double word) (short word for the

68000) boundary.

Examples of bit field declarations follow.

struct {

int f1:8; /* f1 is a signed bit field, */

/* occupying bits 31-24 of the */

/* first double word. */

/* */

unsigned :12; /* 12 bits of padding occupy */

/* bits 23-12 of the first */

/* double word. */

/* */

unsigned f2:16; /* f2 occupies bits 11-0 of the */

/* first double word and bits */

/* 31-28 of the second double */

/* word. */

/* */

int :0,f3:7; /* f3 occupies bits 31-25 of */

/* the third double word. */

} a; /* The size of the structure is */

/* 12 bytes. */

Chapter 3: Internal Data Representation

Derived Data Types

Unions

Unions are like structures except that each member has a zero offset from the

beginning of the union. Unions provide a way to access the same memory

locations in more than one format. A simple example of a union is shown below.

union {

unsigned int sign:1;

float fp_rep;

} fp_num;

main()

{

fp_num.fp_rep = 1.0;

if (fp_num.sign == 0)

fp_num.sign = 1;

}

Accessing int and char members or int and short members will yield different

results due to the byte ordering of data on the 68000. See the "Byte Ordering"

section which follows.

Enumeration Types

Enumeration type declarations define elements of a finite set. Each element of the

enumerated type becomes a constant. The first element is equal to a constant value

of 0, the second is equal to 1, and so on. You can assign a particular constant value

to an element, and the values of the elements which follow will increment from that

value.

An enumeration type is considered to be the smallest integral type which can

represent all the values of the enumeration.

•If the constant values for all elements are between -128 and +127, the

enumeration type is allocated the same space as char types.

•If the condition above is not true, but the constant values for all elements are

between -32768 and +32767, the enumeration type is allocated the same space

as short int types.

•If the constant value of any element is outside the range

-32768 to +32767, the enumeration type is allocated the same space as int

types.

An enum typed variable can be used in expressions wherever integral typed

variables are allowed. The following program shows a simple enumerated type.

Chapter 3: Internal Data Representation

Derived Data Types

enum color {yellow, red, green, blue=8, violet} paint;

/* The elements of the enumeration type "color" equal the */

/* following constants: yellow = 0, red = 1, green = 2, */

/* blue = 8, and violet = 9. */

main()

{

enum color marker;

if (marker == green)

{

paint = marker;

marker++; /* This statement is allowed, but */

/* marker = 3 instead of "blue" */

/* which is 8. */

}

The values of an enumerated type are considered to be declared the moment they

are encountered in the source file. Thus it is possible to have a declaration like the

following:

enum {apple, orange = apple} e;

Alignment Considerations

Variable and constant data, as opposed to executable instructions, may be aligned

or padded by the compiler. In this context, aligned is defined to mean that the

memory allocated to the variable begins at a particular byte boundary (e.g., an

alignment of four (two) bytes means that a variable’s absolute address is a multiple

of four (two)); padded is defined to mean that the size of a type was rounded up to

guarantee that the number of bytes in that type is a multiple of four (two).

Arrays are aligned according to their element type’s alignment and are not padded.

Note, however, that an array’s elements may be padded (if it is an array of

structures or unions).

Structure members are aligned relative to the start of the structure (and padded if

they are structures or unions) in accordance with their type.

Unless function prototypes are used (see the "ANSI Extensions" section in the "C

Compiler Overview" chapter), all char and short parameters are widened to ints

when they are passed and, thus, follow int alignment rules when they are passed.

Chapter 3: Internal Data Representation

Alignment Considerations

Note that inside a called function, char or short parameters are reduced to their

normal char and short size.

Alignment can be changed by using the compiler’s "word align data" (-Q) option.

In the presence of this option, data is aligned at word boundaries.

Note The "word align data" option is not available for the 68000 and 68332, because the

compiler always word-aligns data for these processors.

The following table summarizes the default alignment and padding of the various

data types when the "word align data" option is not used. The numbers in

parentheses are for the 68000/10, 68332, and 68302 processors.

Data Type Alignment Padded?

char 1 N

short 2 N

int 4(2) N

long 4(2) N

pointer 4(2) N

float 4(2) N

double 4(2) N

struct 4(2) Y

Table 3-2. Arithmetic Data Type Alignment

Chapter 3: Internal Data Representation

Alignment Considerations

Alignment Examples

These examples assume that the "word align data" option is not used.

Default alignment dictates that a char variable followed by an int variable

"wastes" three bytes (one byte for the 68000 and 68332) of memory between the

two objects. Note that there are no "wasted" bytes when a char variable is

followed by an array of char, but memory is "wasted" when a char variable is

followed by a structure.

The sizeof bytestruct declared with:

struct {char element;} bytestruct;

is four (two) (the minimum sizeof any struct type) and the sizeof biggerstruct

declared with:

struct {char element1;

int element2;} biggerstruct;

is eight (one for element1, three "wasted" for alignment, four for element2, and

none for padding as the size is a multiple of four). For the 68000 and 68332, the

size is six (one for element1, one "wasted" for alignment, four for element2, and

none for padding as the size is a multiple of two).

Chapter 3: Internal Data Representation

Alignment Considerations

Byte Ordering

Some programs rely on byte ordering. For example, programs that declare a

variable int in one module and char in another may work differently on the 68000

than on other microprocessors due to byte ordering. Consider the two files shown

below:

Because of the problems which can be caused by relying on processor-dependent

ordering, you should not write code like this. Each module or file should declare

variables with identical type information.

File 1: File 2:

------------------------------------- --------------------------------------

extern int x; char x;

main() funct()

{ {

x = ’A’; char c;

funct();

} c = x; /* c = 0x00 */

} /* c != 0x41 */

7 0 7 0

_x 0000 0000 MSB _x 0000 0000

0000 0000

0100 0001 LSB

Chapter 3: Internal Data Representation

Byte Ordering

Chapter 3: Internal Data Representation

Byte Ordering

Compiler Generated Assembly Code

Description of the assembly code generated by the compiler.

Chapter 4: Compiler Generated Assembly Code

The compiler generates assembly code for the HP B3641 assembler (as68k).

Knowing how the compiler generates this code will help you to write assembly

language routines that interface with C functions.

In this chapter you will find information about the following subjects:

•Assembly language symbol names

•Debug directives

•Stack frames (how parameters are passed to and from C functions)

•Register usage

•Run-time error checking

•Ways to include assembly language in a C source file

Chapter 4: Compiler Generated Assembly Code

Assembly Language Symbol Names

The compiler prefixes characters to the names given in the C source (to prevent

potential conflicts with assembler reserved words) when generating assembly

language symbols to represent addresses and stack offsets of C variables.

Symbol Prefixes

The _ Prefix

Externs, globals, statics, and functions have an underscore (_) prefix. You can

change the prefix for external variables (externs, globals, and functions) to a

different string by using a cc68k option (-Wc,-l). Refer to the on-line man page for

more information on changing this prefix character.

The S_ Prefix

Parameters and automatics have "S_" prefixed. The "S" indicates symbols that are

SET equal to stack offsets.

The L_ Prefix

The only other symbol names from the C source which are passed on to the

assembly code are C label names. These labels have "L_" and a unique ASCII

number prefixed to them in the generated assembly code.

See figure 4-1 for an example of how the compiler creates symbol names.

These symbol names are not used by debuggers and emulators unless the

debuggers and emulators consume HP format absolute files. The C source symbol

names are defined using debug directives (see the following "Debug Directives"

section).

Chapter 4: Compiler Generated Assembly Code

Assembly Language Symbol Names

Situations Where C Symbols are Modified

There are four cases where the compiler modifies the names of C variables to

guarantee that they are unique in the assembly code:

1If a parameter or automatic name exceeds 29 characters in length, then it must

be made unique since the assembler only recognizes 31 (29 + 2 for "S_")

significant characters in a symbol.

2If there is a variable with the same name in a containing scope in the C source,

then a parameter or automatic name must be made unique since both symbols

must exist at the same time in the assembler (which doesn’t understand

scoping).

3All local statics (those declared inside a function) are made unique, since a

global static of the same name may be declared later.

4External statics (those declared outside a function) are made unique if their

name exceeds 30 characters in length since the assembler only recognizes 31

(30 + 1 for "_") significant characters in a symbol.

/* Assembly Symbol Name: */

/* --------------------- */

float ext_var; /* _ext_var */

/* */

main() /* _main */

{ /* */

char auto_var; /* S_auto_var */

static int number; /* _1_number */

/* */

auto_var = ’a’; /* */

goto label; /* */

label: /* L_2_label */

function(number); /* */

} /* */

/* */

int number; /* _number */

/* */

function(i) /* _function */

int i; /* S_i */

{ /* */

i = 1; /* */

} /* */

Figure 4-1. Examples of Generated Symbol Names

Chapter 4: Compiler Generated Assembly Code

Assembly Language Symbol Names

In all four cases, symbol names are made unique by inserting a unique ASCII

number and an underscore between the initial underscore (or "S_") and the C name.

For example:

_123_name

S_123_name

#pragma ALIAS

Syntax:

#pragma ALIAS Csymbolname Assemsymbolname

#pragma ALIAS Csymbolname "Assemsymbolname"

This pragma allows overriding of the C compiler algorithm for converting C source

file symbol names into an unique assembler symbol names (the algorithm generally

prefixes an "_" or "S_"). This pragma should be used with great care as it may

generate assembly-time errors due to conflicts between Assemsymbolname and

other assembly language symbols. Use the quotation marks if the

Assemsymbolname would not be a valid C identifier. This pragma should be placed

before any references to the symbol.

Compiler Generated Symbols

The compiler generates assembly language labels for C loops, switch statements,

and other constructs which require labels. The name of the label is related to the

use of the label; for example, the label "forLoop3" might be used to implement a

for loop.

Chapter 4: Compiler Generated Assembly Code

Assembly Language Symbol Names

Debug Directives

If the "strip symbol table information" compiler command line option is not used,

the compiler generates all the HP B3641 debug directives necessary to use

debugger, emulation, and analysis tools. This debug information consists of source

file and line references, type names and structure, symbol type and access

information, and function call information. One LINE directive is output for each

C source statement to associate the generated assembly code with the C source file

line number.

Stack Frame Management

In block-structured languages (C, Pascal, etc.), the stack is used to pass parameters

into and receive results from each of the blocks which make up the program. In C,

these blocks are called functions. In addition to passing values and returning

results, the stack is used for a function’s local variables and to buffer register

variables. The area of the stack used by a function is called a "stack frame". To

illustrate what makes up stack frames and how they are managed, one must observe

what happens to the stack when a function is called; these events are listed below

and described in this section.

Note This section applies only to C function calls. Run-time libraries invoked in

compiler-generated code may use different (and more efficient) stack frame

management because these calls are not constrained by C language calling

conventions.

Chapter 4: Compiler Generated Assembly Code

Debug Directives

High Address

Used stack space

Reserved space for

structure result

Absent if result is <= 8 bytes or if a

larger result is returned through a

variable.

Last parameter

⇑

First parameter

Absent if no parameters are passed.

(Last passed parameter is pushed first.)

Result address Absent if size returned is <= 8 bytes.

Return address

Frame pointer (A6)

points to address of

old frame pointer.

Old frame pointer Absent if there are no parameters or

locals, and size returned is <= 8 bytes.

Last local

⇑

First local

Absent if function does not declare any

local (automatic) variables. (Last

declared local is first on stack.)

Buffered register

variables

Absent if function does not use any

the function are buffered.

Stack pointer (A7)

points to lowest

address used.

Temporaries

⇓

Stack changes as temporaries are saved

and used in expressions.

Low Address Top of stack

Figure 4-2. Stack Frame Format

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

•Space is reserved for a structure result (if the size returned is greater than 8

bytes).

•Parameters are pushed (last is pushed first).

•A pointer to the result address is pushed (if size returned is greater than 8

bytes).

•The subroutine call is made and the return address is pushed (with the JSR or

BSR instructions).

•The old frame pointer is pushed (with the LINK instruction).

•Space for automatics (locals) is allocated (also by LINK).

•Registers used in the called function for register variables are pushed (to buffer

their values).

•During function execution, intermediate values may be stored on the stack

temporarily.

•Function return values are stored in working registers or returned indirectly

through a pointer on the stack (possibly into space reserved on the stack).

•At function exit, register variables are restored and locals are deallocated; and

the calling routine deallocates parameters and uses the structure result.

The general format of a stack frame is shown in figure 4-2. An example of the

code generated for stack frame management is shown in figure 4-3.

Structure Results

C allows functions to return results of type struct. Although most function results

are returned in register D0, D1, or FP0, structures greater in size than 8 bytes are

returned to a location specified by the result location pointer. The result location

pointer is pushed onto the stack after the parameters and before the return address.

In a C statement such as "structure = f(x)", the address of the variable "structure"

may be pushed as the result location pointer, and the called function will return its

resultant structure directly into memory reserved for the "structure" variable.

In other statements, such as "i = f(x).field", space must be reserved on the stack

(prior to pushing parameters) to hold the function structure result. The address of

this reserved stack space will be pushed as the result location pointer (after the

parameters and before the return address), and the function will return its resultant

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

structure into the reserved stack space. This approach maintains reentrancy for

functions returning structures.

Parameter Passing

Parameters are pushed on the stack in right to left order as they appear in the

function call (in other words, the last passed parameter is pushed first). Unless

function prototypes are used (see the "ANSI Extensions" section in the "C

Compiler Overview" chapter), parameters of type char and short are rounded up to

int when passed, and parameters of type float are rounded up to double when

passed.

After the parameters (and, possibly, a result address) are pushed, the function is

called. The subroutine call pushes the return address on the stack following the

parameters.

Pushing the Old Frame Pointer and Allocating Space

A LINK is the first instruction executed inside a called function. The LINK

instruction will:

1Push the old frame pointer (register A6).

2Load A6 with the current value of the stack pointer. (A6 becomes the new

frame pointer.)

3Decrement the stack pointer (register A7) by the amount of space required for

all local (automatic) variables used by the function. (Total local space is

padded to a multiple of two bytes.)

The LINK (and UNLINK at function exit) are optimized out whenever a function

has no parameters, no automatics, and returns a result of size eight bytes or less.

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

Buffering Registers Used for Register Variables

Following the allocation of automatics, any registers which have been allocated for

use by the function as register variables are pushed on the stack to buffer their

values.

Also, the compiler may use these registers for automatics regardless of whether or

not they have been declared with the register storage class specifier (see the

"Register Usage" section which follows). Any registers used by the function for

automatics are also pushed on the stack.

Accessing Parameters

Each parameter’s assembly language symbol name is SET to that parameter’s

offset from the frame pointer. The offset of the first parameter will be 8 if the

result size is less than or equal to 8 bytes; the offset of the first parameter will be 12

if the result size is greater than 8 bytes. For example, if "p" is the first parameter

passed, the compiler generates the following line in the assembly:

S_p SET 8

Parameters are accessed by using the symbol names relative to A6. For example:

MOVE.L (S_p,A6),D0

Shortening Parameters

Unless function prototypes are used (see the "ANSI Extensions" section in the "C

Compiler Overview" chapter), parameters of type char and short are widened to

int when passed. Thus, any parameters formally declared to be of type char or

short must be shortened from int. Since this shortening is defined to be by

truncation, it is accomplished by simply adjusting the int parameter’s offset from

the frame pointer to point to the least significant word (short) or byte (char).

Similarly, float parameters are widened to double when passed. Thus, any formal

float parameters must be shortened from their passed double form. To avoid

problems when such parameters are optional, a float local variable is allocated, and

the double value is converted to float and stored in the local variable. The formal

parameter’s offset from the frame pointer is then set to be that of the new local

variable.

An example of the widening and shortening of parameters is shown in figure 4-4.

The same example using function prototypes is shown in figure 4-5.

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

Accessing Locals

The last local (automatic) variable declared appears first on the stack. Each local

variable’s assembly language symbol name is SET to that variable’s offset from the

frame pointer. For example, if "l" is the first local declared, and there are 20 bytes

of local variables, then the compiler generates the following line in the assembly:

S_l SET -20

Local variables are accessed using the symbol name relative to A6. For example:

MOVE.L (S_l,A6),D0

Using the Stack for Temporary Storage

Code generated by the function body may or may not use the stack for temporary

storage of intermediate results. This temporary storage size is dynamic through the

function, but has all been removed by the time the function exit code is executed.

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

Function Results

Results which fit in four bytes are returned in register D0. Results of four to eight

bytes are returned in registers D0 and D1. Results larger than eight bytes are

returned indirectly through a "result address" pointer pushed by the calling routine.

This pointer may point to a static memory location, an automatic variable, or

temporary space on the stack. For the 68040, functions return float or double values

in the FP0 register.

Function Exit

At function exit, any buffered register variables are popped, an UNLINK

instruction is used to restore the buffered frame pointer and increment the stack

pointer to its position at function entry, and the function return itself pops the return

address. The calling routine is responsible for incrementing the stack pointer,

popping the passed parameters, and, if necessary, removing the space reserved for

structure function results.

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

HPB3640-19300 68000 C Cross Compiler A.04.00 stackf1.c

HPB3641-19300 A.02.00 19Apr93 Copr. HP 1988 Page 1 Mon Apr 26 15:14:50 1993

Command line: as68k -Lfnot,llen=1100 -H stackf1.A -o stackf1.o /tmp/ct3CAAa27807

Line Address

CHIP 68000

NAME stackf1

* MKT:@(#) B3640-19300 A.04.00 MOTOROLA 68000

FAMILY C CROSS COMPILER

* Assembler options:

OPT BRW,FRL,NOI,NOW

* Macro definition for calling run-time libs:

* bytes per call = 6

CALL MACRO routine

XREF routine

JSR (routine).L

ENDM

SECT prog,2,C,P

1 typedef struct {

2 int month,day,year;

3 } date;

5 main()

6 {

XDEF _main

_main

00000000 4E56 FFF4 LINK A6,#-12

FFFFFFF4 S_d SET -12

7 date d,set_date();

9 set_date(d,5,18,87);

00000004 4FEF FFF4 LEA (-12,A7),A7

00000008 4878 0057 PEA (87).W

0000000C 4878 0012 PEA (18).W

00000010 4878 0005 PEA (5).W

00000014 41EE FFF4 LEA (S_d+0,A6),A0

00000018 2F28 0008 MOVE.L (8,A0),-(A7)

0000001C 2F28 0004 MOVE.L (4,A0),-(A7)

00000020 2F10 MOVE.L (A0),-(A7)

00000022 486F 0018 PEA (24,A7)

00000026 4EB9 0000 0034 R JSR (_set_date+0).L

0000002C 4FEF 0028 LEA (12+24+4,A7),A7

10 }

functionExit1

00000030 4E5E UNLK A6

returnLabel1

00000032 4E75 RTS

Figure 4-3. Example Stack Frame Management Code

Space reserved for

structure result.

Parameters

pushed.

Structure

result address

pushed.

Stack pointer incremented

(parameters popped).

Function

call.

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

12 date set_date(x,mo,da,yr)

13 date x;

14 int mo,da,yr;

15 {

XDEF _set_date

_set_date

00000034 4E56 FFF0 LINK A6,#-16

0000000C S_x SET 12

00000018 S_mo SET 24

0000001C S_da SET 28

00000020 S_yr SET 32

FFFFFFF0 S_i1 SET -16

FFFFFFF8 S_i2 SET -8

16 double i1,i2;

17 register int i3;

19 x.month = mo;

00000038 2D6E 0018 000C MOVE.L (S_mo+0,A6),(S_x+0,A6)

20 x.day = da;

0000003E 2D6E 001C 0010 MOVE.L (S_da+0,A6),(S_x+4,A6)

21 x.year = yr;

00000044 2D6E 0020 0014 MOVE.L (S_yr+0,A6),(S_x+8,A6)

22 return(x);

0000004A 41EE 000C LEA (S_x+0,A6),A0

0000004E 226E 0008 MOVEA.L (8,A6),A1

REPT 3

MOVE.L (A0)+,(A1)+

ENDR

00000052 22D8 MOVE.L (A0)+,(A1)+

00000054 22D8 MOVE.L (A0)+,(A1)+

00000056 22D8 MOVE.L (A0)+,(A1)+

23 }

functionExit2

00000058 4E5E UNLK A6

returnLabel2

0000005A 4E75 RTS

END

Figure 4-3. Example Stack Frame Mgmt. Code (Cont’d)

Old frame pointer

pushed and space

for locals allocated.

Structure

result

returned.

Function exit.

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

HPB3640-19300 68000 C Cross Compiler A.04.00 shrtwid1.c

HPB3641-19300 A.02.00 19Apr93 Copr. HP 1988 Page 1 Mon Apr 26 15:14:59 1993

Command line: as68k -Lfnot,llen=1100 -H shrtwid1.A -o shrtwid1.o /tmp/ct3CAAa27822

Line Address

CHIP 68000

NAME shrtwid1

* MKT:@(#) B3640-19300 A.04.00 MOTOROLA 68000

FAMILY C CROSS COMPILER

* Assembler options:

OPT BRW,FRL,NOI,NOW

* Macro definition for calling run-time

libraries:

* bytes per call = 6

CALL MACRO routine

XREF routine

JSR (routine).L

ENDM

SECT prog,2,C,P

1 main()

2 {

XDEF _main

_main

00000000 2F03 MOVE.L D3,-(A7)

00000002 2F02 MOVE.L D2,-(A7)

* Register ’D3’ is register variable ’S_c’.

* Register ’D2’ is register variable ’S_f’.

3 char c, char_funct();

4 float f, float_funct();

6 char_funct(c);

00000004 1003 MOVE.B D3,D0

00000006 4880 EXT.W D0

00000008 48C0 EXT.L D0

0000000A 2F00 MOVE.L D0,-(A7)

0000000C 4EB9 0000 002E R JSR (_char_funct+0).L

00000012 588F ADDQ.L #4,A7

7 float_funct(f);

00000014 2002 MOVE.L D2,D0

CALL ftod

XREF ftod

00000016 4EB9 0000 0000 E JSR (ftod).L

0000001C 2F01 MOVE.L D1,-(A7)

0000001E 2F00 MOVE.L D0,-(A7)

Figure 4-4. Widening and Shortening of Parameters

char widened to int.

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

00000020 4EB9 0000 003A R JSR (_float_funct+0).L

00000026 508F ADDQ.L #8,A7

8 }

functionExit1

00000028 241F MOVE.L (A7)+,D2

0000002A 261F MOVE.L (A7)+,D3

returnLabel1

0000002C 4E75 RTS

10 char char_funct(chr)

11 char chr;

12 {

XDEF _char_funct

_char_funct

0000000B S_chr SET 11

13 chr = ’A’;

0000002E 1F7C 0041 0007 MOVE.B #65,(S_chr-4,A7)

14 return(chr);

00000034 102F 0007 MOVE.B (S_chr-4,A7),D0

15 }

functionExit2

returnLabel2

00000038 4E75 RTS

17 float float_funct(flt)

18 float flt;

19 {

XDEF _float_funct

_float_funct

0000003A 4E56 FFFC LINK A6,#-4

FFFFFFFC S_flt SET -4

00000008 S_wide_param1 SET 8

0000003E 43EE 0008 LEA (S_wide_param1+0,A6),A1

00000042 2019 MOVE.L (A1)+,D0

00000044 2219 MOVE.L (A1)+,D1

CALL dtof

XREF dtof

Figure 4-4. Widening/Shortening Parameters (Cont’d)

int shortened to

char (offset

points to least

significant byte

of parameter.)

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

HPB3640-19300 68000 C Cross Compiler A.04.00 funcprto.c

HPB3641-19300 A.02.00 19Apr93 Copr. HP 1988 Page 1 Mon Apr 26 15:15:10 1993

Command line: as68k -Lfnot,llen=1100 -H funcprto.A -o funcprto.o /tmp/ct3CAAa27837

Line Address

CHIP 68000

NAME funcprto

* MKT:@(#) B3640-19300 A.04.00 MOTOROLA 68000 FAMILY C

CROSS COMPILER

* Assembler options:

OPT BRW,FRL,NOI,NOW

* Macro definition for calling run-time libraries:

* bytes per call = 6

CALL MACRO routine

XREF routine

JSR (routine).L

ENDM

SECT prog,2,C,P

1 main()

2 {

XDEF _main

_main

00000000 2F02 MOVE.L D2,-(A7)

* Register ’D0’ is register variable ’S_c’.

* Register ’D2’ is register variable ’S_f’.

3 char c, char_funct(char);

4 float f, float_funct(float);

6 char_funct(c);

00000002 1F00 MOVE.B D0,-(A7)

00000004 4EB9 0000 0018 R JSR (_char_funct+0).L

7 float_funct(f);

0000000A 2F02 MOVE.L D2,-(A7)

0000000C 4EB9 0000 0024 R JSR (_float_funct+0).L

00000012 5C8F ADDQ.L #6,A7

8 }

functionExit1

00000014 241F MOVE.L (A7)+,D2

returnLabel1

00000016 4E75 RTS

10 char char_funct(

Figure 4-5. Function Prototype Parameter Passing

char no longer

widened to int.

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

11 char chr)

12 {

XDEF _char_funct

_char_funct

00000008 S_chr SET 8

13 chr = ’A’;

00000018 1F7C 0041 0004 MOVE.B #65,(S_chr-4,A7)

14 return(chr);

0000001E 102F 0004 MOVE.B (S_chr-4,A7),D0

15 }

functionExit2

returnLabel2

00000022 4E75 RTS

17 float float_funct(float flt)

18 {

XDEF _float_funct

_float_funct

00000008 S_flt SET 8

19 flt = 1.0;

00000024 2F7C 3F80 0000 MOVE.L #$3F800000,(S_flt-4,A7)

0004

20 return(flt);

0000002C 202F 0004 MOVE.L (S_flt-4,A7),D0

21 }

functionExit3

returnLabel3

00000030 4E75 RTS

END

Figure 4-5. Function Prototype Parameters (Cont’d)

Chapter 4: Compiler Generated Assembly Code

Stack Frame Management

The following table shows how registers are used for C function calls.

Note This section applies only to C function calls. Run-time libraries invoked in

compiler-generated code may use other conventions understood by the calling

code. (See the "Run-Time Library Description" chapter.)

Registers D0, D1, A0, and A1 are reserved as working registers to hold

intermediate values of calculations. Registers D0 and D1 are also used to hold

function return values that fit in eight bytes. Return values larger than eight bytes

are returned indirectly via a pointer.

D0, D1 Return values

A0, A1 Working registers

FP0, FP1

A5 Reserved for A5 relative addressing

A6 Frame pointer

A7 Stack pointer

Table 4-1. Register Usage

Chapter 4: Compiler Generated Assembly Code

For more information on how register A5 is used for A5 relative addressing, see the

"Addressing Modes" section in the "Embedded Systems Considerations" chapter.

When the "generate 68881/2 code" (-f) option is used, registers FP2-FP7 are

reserved for floating-point register variables. The compiler may assign float or

double objects to these registers. Also, when the "generate 68881/2 code" option is

used, registers FP0 and FP1 are reserved as working registers.

For the 68040, registers FP2-FP7 are reserved for floating-point register variables.

The compiler may assign float or double objects to these registers. Registers FP0

and FP1 are reserved as working registers. FP0 is also used for function return

values of type float or double.

Using the priority listed below, the compiler allocates the following types of

objects to registers D2-D7, A2-A4, and FP2-FP7:

1Variables declared with register storage class in the order declarations are

encountered.

2Local non-static and function parameter variables, and addresses of static

variables, according to frequency of occurrence of the variable’s name in the

function.

If the type of the object being declared is a pointer, the compiler prefers to assign

the object to an address register; however, the compiler may assign the object to a

data register if no address registers remain. The compiler only assigns non-pointers

(small enough to fit in a register) to data registers.

When the "optimize" option is specified, the peephole optimizer will reallocate

and "pop" instructions used to buffer register variable registers.

Function parameter names and static variable names must be used at least three

times in the function before they will be considered for register allocation. The

rationale for this restriction has to do with the added generated assembly

instruction required to move a static or a function parameter into a register. The

space cost of the added instruction is considered to be offset when three or more

references are made to the parameter because now the references are to a register

instead of the stack. However, it is difficult to know if the register-for-a-parameter

optimization will improve execution speed because it is impossible to know how

the parameter is actually used in the function body. There could be instances where

this optimization could result in slower code due to the extra assignment.

Chapter 4: Compiler Generated Assembly Code

Example

To better understand the allocation scheme, consider the following example.

Suppose there was a single register left to allocate. A local non-static variable

appears just once in the function body. A parameter appears twice in the function

body. Which gets the register? The local variable does because the parameter,

which appears less than three times, has not "qualified" for consideration for

frequency of occurrence.

Now let us suppose that the parameter appears n times where n is three or greater.

Suppose the local non-static variable appears n–1 times. Which gets the register?

The parameter gets the register because it has "qualified" for consideration and has

a greater number of occurrences.

Chapter 4: Compiler Generated Assembly Code

Run-Time Error Checking

Specifying the "generate run-time error checking" (-g) option causes the compiler

to generate code for the following types of additional run-time error checking:

•Dereferences of all NULL pointers and uninitialized automatic pointers are

detected and reported. (Dereferencing is also called indirection; in other

words, it is access to the object to which a pointer points.) This requires the

initialization of automatic pointers at run-time with a value (–1) indicating

they are uninitialized. Note that static variables are not initialized to the

uninitialized pointer value, because the default value for static variables is zero.

•Array references outside declaration index bounds are detected and reported.

The "generate run-time error checking" option will override the "optimize" and

"strip symbol table information" options. See the on-line man pages for more

information on the compiler command line options.

Chapter 4: Compiler Generated Assembly Code

Run-Time Error Checking

Using Assembly Language in the C Source File

The C compiler provides three mechanisms to embed assembly language

instructions. Which one you choose depends on where you want the assembly

language to appear and your purpose for including the assembly language

instructions. The mechanisms are:

•#pragma ASM and #pragma END_ASM

•__asm ("C_string")

•#pragma FUNCTION_ENTRY "C_string",

#pragma FUNCTION_EXIT "C_string", and

#pragma FUNCTION_RETURN "C_string"

The compiler changes the names of C variables and functions into assembly

language symbols. If you know how the changed symbol names will appear in the

generated assembly code, you may easily use C variables and functions in your

embedded assembly code. (For more information on symbol names, see the

"Symbol Names" section in this chapter.)

When you embed assembly language, all assumptions about working registers (D0,

D1, A0, A1, and FP0-FP1) for optimization purposes are forgotten.

the stack pointer (A7) are not buffered prior to embedded assembly language

instructions. You should buffer these registers if they will be used in your

assembly code.

Optimizations do not affect your embedded assembly code.

None of these mechanisms are part of the ANSI standard, so programs which use

embedded assembly language may not be portable to other compilers.

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

#pragma ASM

#pragma END_ASM

Syntax:

#pragma ASM

(assembly language statement(s))

#pragma END_ASM

These two pragmas bracket a portion of inline assembly code. You may use these

pragmas anywhere a C statement or external declaration can occur. Place the

#pragma ASM before the beginning of your embedded assembly code and place

the #pragma END_ASM after the code.

The assembly instructions must conform to the format and syntax required by the

HP B3641 assembler. The C compiler does not check the embedded assembly

instructions for correctness. The compiler simply passes the assembly language

statements, unchanged, to the assembler. You may, however, use the C

preprocessor to alter embedded assembly language instructions.

Example Figure 4-6 gives an example of using the #pragma ASM/END_ASM to embed

assembly code in a C source file.

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

main ()

{

/* Invoke supervisor mode routine. */

#pragma ASM

TRAP #17

#pragma END_ASM

}

swap (int i1, int i2) {

#pragma ASM

move.l (S_i1,a6),d0

move.l (S_i2,a6),(S_i1,a6)

move.l d0,(S_i2,a6)

#pragma END_ASM

}

Figure 4-6. #pragma ASM/END_ASM Embedded Assembly

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

__asm ("C_string")

Syntax:

__asm (

"C_string"

)

The quotes are part of the C_string argument and the two preceding underscores

are required to meet ANSI name space requirements.

The __asm function is another way to embed assembly code. It differs from the

#pragma ASM/END_ASM pair in two ways:

•#pragma ASM/END_ASM brackets a section of inline assembly code. In

contrast, the assembly language instructions are contained in a "C_string"

argument to the __asm function.

•#pragma ASM/END_ASM may appear either inside or outside of a function

body. Because __asm is syntactically a function call, it may only appear inside

a function body just as any other function call must.

The __asm function has some advantages over the #pragma ASM/END_ASM

mechanism. First, this function can be part of a macro definition which means you

may define a macro that contains embedded assembly language. The #pragma

ASM/END_ASM pair cannot be used to do this. Second, for single assembly

instructions, the __asm function is more expedient because it requires just the

function call on a single line.

The "C_string" argument is a character string containing one or more lines of

assembly code. (The quotes are part of the argument.) It must contain white space

so that when the string is output to the generated assembly code, it will conform to

the format and syntax required by the HP B3641 Assembler. The C compiler does

not check the C_string for correctness. The compiler simply outputs the string to

the assembly code.

Example Figure 4-7 gives an example of using the __asm function.

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

main ()

{

/* Invoke supervisor mode routine. */

__asm("\tTRAP\t#17") .

}

swap (int i1, int i2) {

/* Notice the "\t" whitespace that must appear

in order to conform to the Assembler requirement

that instructions cannot begin in column 1. Spaces

or a tab character would also have worked. Notice also

that there is no need to terminate the string with a newline. */

__asm ("\tmove.l (S_i1,a6),d0");

__asm ("\tmove.l (S_i2,a6),(S_i1,a6)");

__asm ("\tmove.l d0,(S_i2,a6)");

/* Another, less readable way of doing the above

involves using newlines to achieve line breaks

in the output assembly when the C_string contains

more than one assembly instruction.

__asm ("\tmove.l (S_i1,a6),d0\n\tmove.l (S_i2,a6),(S_i1,a6)");

__asm ("\tmove.l d0,(S_i2,a6)");

This form would appear the same as the first

in the output assembly code. */

}

Figure 4-7. __asm Function Embedded Assembly

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

#pragma FUNCTION_ENTRY,

#pragma FUNCTION_EXIT,

#pragma FUNCTION_RETURN

Syntax:

#pragma FUNCTION_ENTRY

"C_string"

#pragma FUNCTION_EXIT

"C_string"

#pragma FUNCTION_RETURN

"C_string"

The third mechanism is #pragma FUNCTION_ENTRY /EXIT /RETURN.

These pragmas are not a pair like #pragma ASM/END_ASM. They may be used

independently of each other or they may be used together.

#pragma FUNCTION_ENTRY may be used to insert assembly language

instructions into function entry code. Similarly, #pragma FUNCTION_EXIT and

#pragma FUNCTION_RETURN may be used to insert assembly language

instructions into function exit code. Neither #pragma ASM/END_ASM nor the

__asm function is able to place embedded assembly in the function entry or exit

code. The embedded code is placed is as follows:

•#pragma FUNCTION_ENTRY places the embedded assembly code

immediately after the label generated from the function name. Because the

embedded assembly occurs before any function entry code, you can modify the

way a function is entered.

•#pragma FUNCTION_EXIT places the embedded assembly immediately

before the function return label. That is, it follows the function exit code, but

precedes the function return. (Some NOPs may appear between the embedded

assembly code and the return label.) This pragma gives you the flexibility to

control function return and also allows you to perform extra instructions before

function return.

•#pragma FUNCTION_RETURN places the embedded assembly

immediately after the function return label. Use this pragma if you want to use

your own function return code. For example, you might want to trap to a

debugging routine.

Remember, you may use #pragma FUNCTION_ENTRY, FUNCTION_EXIT,

and FUNCTION_RETURN by themselves, or you may use all of them together.

Two limitations apply to these pragmas:

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

•#pragma FUNCTION_ENTRY, #pragma FUNCTION_EXIT, and

#pragma FUNCTION_RETURN may only appear outside of a function

body.

•#pragma FUNCTION_ENTRY, #pragma FUNCTION_EXIT, and

#pragma FUNCTION_RETURN must precede the function they are to

affect. They are in effect only for the immediately following function and no

other.

These pragmas take a "C_string" argument. (The quotes are part of the argument

and no parentheses surround the argument.) As with the __asm function, the

"C_string" argument is a character string containing assembly language

instructions. It must contain white space and newlines ("\n") so that when the string

is output to the generated assembly code, it will conform to the format and syntax

required by the HP B3641 assembler. The C compiler does not check the C_string

for correctness. The compiler simply outputs the string to the assembly code.

Example Figure 4-8 gives an example of using #pragma FUNCTION_EXIT along with

#pragma INTERRUPT (discussed in the "Embedded Systems Considerations"

chapter) to cause an interrupt service routine to trap back to the operating system

instead of allowing it to terminate with an RTE instruction as it would if #pragma

INTERRUPT were used alone. When this routine enters its function exit code, it

will do the cleanup of the stack and other chores in preparation of the RTE. But

because the #pragma FUNCTION_EXIT code causes the routine to trap back to

the operating system, it will never execute the RTE.

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

#pragma INTERRUPT

#pragma FUNCTION_EXIT "\tMOVE #10,D0\n\tTRAP #12"

void intr_funct (void)

{

/* Function body for interrupt routine. */

}

/* The following exit code results from these

pragmas. */

functionExit1

00000004 4CDF 6303 MOVEM.L (A7)+,D0/D1/A0/A1/A5/A6

00000008 31C0 000A MOVE #10,D0

0000000C 4E4C TRAP #12

returnLabel1

0000000E 4E73 RTE

END

Figure 4-8. #pragma FUNCTION_EXIT

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

Assembly Language in Macros

To use assembly language in a macro, use the __asm function. The #pragma

mechanism does not work in a macro.

When you write the macro, remember the following suggestions:

•Use __asm, not one of the pragmas.

•Do not use macro parameters in the assemly code. The C preprocessor does

not expand names inside the quotation marks.

•Use spaces and tabs (entered as "\t") to place "white space" in the assembly

code.

•If you need to place more than one line of assembly language in the macro,

either use an __asm statement for each line or place a "\n" between lines. The

C preprocessor will place the entire macro on one line, then the compiler will

change the "\n" to a newline when generating the assembly code.

•Be careful about changing the values of C variables (side effects) in the macro.

You may wish to include the names of such variables in the name of the macro.

•You can examine the generated assembly code by compiling with cc68k

-SL and looking at the .O file. If you need to understand how the C

preprocessor affected the code, use cc68k -E.

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

Chapter 4: Compiler Generated Assembly Code

Using Assembly Language in the C Source File

Optimizations

Description of optimizations performed by the compiler.

Chapter 5: Optimizations

The C compiler performs many optimizations automatically; there is also an

"optimize" command line option (-O) to cause peephole optimization, time or

space optimization, and other compile-time costly optimizations. This chapter first

describes the optimizations which are always performed; next, it describes the

optimizations which occur as a result of the "optimize" command line option.

Universal Optimizations

The C compiler automatically performs many optimizations on C programs.

Several of the most notable types of optimizations are listed below and described in

this section.

•Constant Folding.

•Expression Simplification.

•Operation Simplification (involves multiplies, divides, and mods by powers of

two).

•Optimizing Expressions in a Logical Context (involves expressions which

contain logical operators).

•Loop Construct Optimization.

•Switch Statement Optimization.

•Automatic Allocation of Register Variables.

The compiler may do many specific things for each type of optimization. The

descriptions which follow contain examples to illustrate the kinds of things which

are done for each type of optimization; they do not show every specific

optimization performed by the compiler.

Note In the general examples which follow, E represents any expression, C represents

any constant, !0 represents a constant with a non-zero value, and other operator

symbols are their C equivalents.

Chapter 5: Optimizations

Universal Optimizations

Constant Folding

Whenever an expression contains operations made on constants, the compiler

combines the constants to form a single constant. By folding constants, the

compiler can eliminate the code which would otherwise be generated to perform

the operations. A general and specific example of constant folding is shown below.

C1 * C2 - C3 / C4 ⇒C5

i = 4 * 3 - 10 / 2; ⇒i = 7;

Constant Folding Across Expressions

The compiler will rearrange integer expressions to fold constants.

(E1 + C1) + ( E2 + C2) ⇒(E1 + E2) + (C1 + C2)

(E1 * C1) * (E2 * C2) ⇒(E1 * E2) * (C1 * C2)

(E1 + C1) * C2 ⇒(E1 * C2) + (C1 * C2)

(E1 << C1) * (E2 * C2) ⇒(E1 * E2) * ((2C1) * C2)

i = (x * 3 + 1) * 3 + 2 ⇒i = x * 9 + 5

Maintaining Order of Evaluation

Parentheses force grouping (prevent constant folding) of floating-point expressions.

The unary plus (+) operator may be used to force grouping of arithmetic

expressions. The unary plus operator may not be used to force grouping of pointer

expressions. For example:

i = x+4.141 + y+2.067 + 3.287; ⇒i = x + y + 9.495;

i= x+4.141 + (y+2.067)+3.287; ⇒i = x + +(y + 2.067) + 7.428;

i= x+4.141 + +(y+2.067)+3.287; ⇒i = x + +(y + 2.067) + 7.428;

Chapter 5: Optimizations

Universal Optimizations

Expression Simplification

The compiler will simplify expressions, if possible, by using the basic laws,

identities, and definitions of conditional, logical, bitwise, and arithmetic operations.

Some examples of expressions which get simplified follow.

Conditional:

0 ? E1 : E2 ⇒E2

!0 ? E1 : E2 ⇒E1

Logical:

E && 0 ⇒0 (unless E has side effects; then E,0)

E || 0 ⇒E

E1 && !E2 ⇒!(!E1 || E2)

Bitwise:

E & 0 ⇒0 (unless E has side effects; then E,0)

E | 0 ⇒E

E ^ 0 ⇒E

E << 0 ⇒E

Arithmetic:

E + 0 ⇒E

-E1 - (-E2) ⇒E2 - E1

E * 0 ⇒0 (unless E has side effects; then E,0)

E * 1 ⇒E

E / -1 ⇒-E

E % 1 ⇒0 (unless E has side effects; then E,0)

Operation Simplification

Multiplications (whether explicit or as a result of scaling an array index), divisions,

and mods of integral types by constants which equal powers of two can be

simplified to bitwise operations which are shorter and faster. Generally:

E * (2C)⇒E << C

Chapter 5: Optimizations

Universal Optimizations

E / (2C)⇒E >> C

E % (2C)⇒E & (2C - 1)

Optimizing Expressions in a Logical Context

When expressions containing logical operators are used in a logical context (for

example, to yield a "true" or "false" in a control flow statement test expression), the

compiler will generate code which evaluates the expression piece by piece. For

example, suppose the test expression for an if statement is two expressions ANDed

together. The compiler generates code which evaluates the first expression and

branches out if it is "false" (if, at run-time, the first expression is "false", the second

expression will not be evaluated). The compiler also generates code to evaluate the

second expression in case the first is "true". The code generated as a result of this

optimization is smaller and faster. Several "pseudo code" examples of

optimizations on expressions in a logical context are shown below.

if (0) goto label ⇒(Nothing.)

if (!0) goto label ⇒goto label

if (E1 || E2) goto label ⇒if (E1) goto label

if (E2) goto label

if (E1 && E2) goto label ⇒if (!E1) goto skip

if (E2) goto label

skip:

Loop Construct Optimization

The compiler places the evaluation of a loop construct’s test expression at the end

of the loop to avoid the execution of a "goto" at each loop iteration. A "goto" is

generated to branch to the test for the first iteration. However, if the compiler can

determine that the loop will execute at least once, the "goto" can be optimized out.

Whenever the test expression becomes "false", execution simply "falls through".

Chapter 5: Optimizations

Universal Optimizations

The loop construct optimization can be generally expressed as follows.

while (E) { statements } ⇒goto end

beginning:

{ statements }

end: if (E) goto beginning

for (i = 0; i < 10;) ⇒i = 0

{ statements } beginning:

{ statements }

if (i < 10) goto beginning

Switch Statement Optimization

If there is code associated with at least 25% of the cases in a switch statement, the

compiler will generate a jump table to access the code associated with each case. If

less than 25% of the cases have associated code, the compiler will generate a

hybrid binary/linear search to access the cases. The linear search can be up to four

items long, otherwise a binary test is performed.

Automatic Allocation of Register Variables

Operating on variables which reside in registers is faster and more efficient than

operating on variables in memory. The C compiler will automatically allocate

variables to registers even in the absence of the register storage class specifier.

Note that the presence of the auto storage class specifier prevents this optimization.

For more information on the algorithm used by the compiler to allocate these

variables, see the "Register Usage" section in the "Compiler Generated Assembly

Code" chapter.

String Coalescing

When the compiler finds identical string constants, it stores them at a single

memory location. In the following example, both string1 and string2 will point to

the same memory location containing the string "abcde":

char *string1, *string2;

string1 = "abcde";

string2 = "abcde";

Chapter 5: Optimizations

Universal Optimizations

Only string constants allocated by the compiler are coalesced. For example, the

following strings will not be coalesced because the user, rather than the compiler, is

allocating the storage:

char string3[8] = "abcde";

char string4[8] = "abcde";

Note Trying to change the value of a string constant may cause unwanted side effects.

The compiler treats string literals as constants. Do not attempt to change the

contents of a string which has been defined as a string literal. Be especially careful

if you are using character pointers. For example, the following statements will

change the value of both string1 and string2 to "abXde":

char *string1, *string2;

string1 = "abcde";

string2 = "abcde";

*(string1 + 2) = ’X’;

The compiler will not warn you about this.

Chapter 5: Optimizations

Universal Optimizations

The Optimize Option

The "optimize" command line option (-O) causes the compiler to use a more

exhaustive algorithm in an attempt to generate locally optimal code; it also causes

the compiler to run the peephole assembly code optimizer (unless the "generate

run-time error checking code" option is also specified, in which case the "optimize"

command line option is ignored).

You may find it easier to debug your code if you do not use the "optimize" option.

Optimizations may make it difficult to follow the program flow. After the code is

executing properly, use optimization to improve execution speed or to shrink the

size of the executable code.

Time vs. Space Optimization

By default, the -O option causes the generated code to be optimized for space.

That is, the compiler tries to generate as few bytes of code as possible (even,

occasionally, at the expense of execution speed). However, if optimizing for time

is more important (in other words, the generated code should execute as fast as

possible), you can append the "time" option to the "optimize" option (-OT).

Optimizing for time will cause the compiler to use more space if machine cycles

can be saved. The listings in figure 5-1 give an example of a time vs. space

trade-off.

Chapter 5: Optimizations

The Optimize Option

1 struct test {

2 int a,b,c,d,e,f;

3 } x, y;

5 main()

6 {

XDEF _main

_main

7 y = x;

00000000 207C 0000 0018 R MOVE.L #_y+0,A0

00000006 227C 0000 0000 R MOVE.L #_x+0,A1

0000000C 7205 MOVEQ #6-1,D1

L0_StatAssign

0000000E 20D9 MOVE.L (A1)+,(A0)+

00000010 51C9 FFFC DBF D1,L0_StatAssign

8 }

---------------------------------------------------------------------------------

1 struct test {

2 int a,b,c,d,e,f;

3 } x, y;

5 main()

6 {

XDEF _main

_main

7 y = x;

00000000 207C 0000 0018 R MOVE.L #_y+0,A0

00000006 227C 0000 0000 R MOVE.L #_x+0,A1

REPT 6

MOVE.L (A1)+,(A0)+

ENDR

0000000C 20D9 MOVE.L (A1)+,(A0)+

0000000E 20D9 MOVE.L (A1)+,(A0)+

00000010 20D9 MOVE.L (A1)+,(A0)+

00000012 20D9 MOVE.L (A1)+,(A0)+

00000014 20D9 MOVE.L (A1)+,(A0)+

00000016 20D9 MOVE.L (A1)+,(A0)+

8 }

Figure 5-1. Example of Time vs. Space Optimization

OPTIMIZED FOR SPACE (Default).

OPTIMIZED FOR TIME. (More bytes used

to accomplish structure assignment, but code

executes faster.)

Chapter 5: Optimizations

The Optimize Option

Multiplication Simplification

In addition to the powers-of-two optimizations as described in the preceding

"Operation Simplification" section, multiplications by constants up to 1024

(whether explicit or as a result of scaling an array index) are optimized to

sequences of shifts and adds or subtracts. Shifts and adds or subtracts are typically

less time expensive but more space expensive than the corresponding

multiplications (i.e., these optimizations occur more often in the presence of the

"time" option to the "optimize" command line option). For example:

E * 10 ⇒((E << 2) + E) << 1

E * 29 ⇒(((E << 3) - E) <<2) + E

Maintaining Debug Code

The compiler normally generates code which makes the resulting programs easier

to debug with an HP emulator or simulator. This debug code includes:

1Generation of no-operation (NOP) instructions preceding all labels. This

provides unique addresses for all labels. It also avoids certain problems

associated with instruction prefetch.

2Buffering of the frame pointer on the stack at function entry and restoration of

the frame pointer at function exit, even when this is known to be unnecessary.

(Every function begins with a LINK instruction and ends with an UNLINK

instruction followed by a RTS or RTE.)

When the "optimize" option is specified, this debug code is optimized out.

However, if you wish the compiler to generate debug code and perform the other

optimizations, use the "generate debug code" option with the "optimize" option.

See the on-line man pages for more information on the compiler command line

options.

Peephole Optimization

The peephole optimizer, which is run when the "optimize" command line option is

specified, adds another pass to the compilation process. The peephole optimizer

examines the assembly language instructions generated by the compiler and

performs the optimizations described in the following subsections.

Chapter 5: Optimizations

The Optimize Option

100

Branch (Jump) Shortening

Perhaps the most common peephole optimization is branch shortening. Neither the

compiler (by itself) nor the assembler is capable of determining the distance of a

forward branch. Consequently, 32-bit PC relative branches are generated by

default.

The peephole optimizer, on the other hand, is capable of determining the distance

of forward branches, and it will replace long branch instructions with byte or word

sized instructions wherever possible.

Tail Merging

When two blocks of code end in identical branches, the peephole optimizer checks

if the blocks have the same tail (ending) statements. If the blocks do have identical

tail statements, the peephole optimizer will replace the first tail with a "goto" the

second. If this would cause an additional branch to be executed, it is not performed

when "optimize for time" is specified. For example:

. . . ⇒. . .

{ tail 1 } ⇒goto sametail

goto label ⇒. . .

. . . ⇒sametail:

{ tail 2 } (Same as tail 1.) ⇒{ tail 2}

goto label ⇒goto label

. . . ⇒. . .

label: ⇒label:

Redundant Register Load Elimination

When the peephole optimizer detects that a register is being loaded with a value it

already contains, the second load is eliminated. (Compare to "Strength Reduction"

below.)

MOVE.L (S_i+0,A6),D0

. . .

MOVE.L (S_i+0,A6),D0 ; This instruction is removed.

Chapter 5: Optimizations

The Optimize Option

101

Redundant Jump Elimination

When one jump occurs immediately after another jump, the two jumps are

combined to form a single jump. Note that this optimization is performed on the

generated assembly code, but a C code equivalent example would be the following:

if (x == y) goto aaa; ⇒if (x == y) goto bbb;

. . . . . .

aaa:goto bbb aaa: goto bbb;

. . . . . .

bbb: bbb:

Unreachable Code Elimination

As compilers normally generate code, they can produce assembly instructions

which will never get executed. The peephole optimizer can recognize unreachable

assembly instructions and remove them.

Strength Reduction

Strength reduction refers to optimizations which can be made due to the

optimizer’s ability to remember the contents of registers. For example, the

compiler may generate code to move a variable into one register, and later generate

code to move the same variable into another register. The peephole optimizer can

replace the second move with a move from the first register to the second (which is

shorter and faster). Two bytes will be saved by the example strength reduction

optimization shown below.

MOVE.L (S_i+0,A6),D0 ⇒MOVE.L (S_i+0,A6),D0

MOVE.L (S_i+0,A6),D1 ⇒MOVE.L D0,D1

Chapter 5: Optimizations

The Optimize Option

102

Destination/Source Swapping

When generated code operates on a working register to yield a result, and the result

is moved to a register variable, the peephole optimizer can eliminate the last move

by causing the operations to be made on the register variable in the first place. This

optimization is called destination swapping; an example is shown below.

MOVE.L (S_i,A6),D0 ⇒MOVE.L (S_i,A6),D2

ADD (S_x,A6),D0 ⇒ADD (S_x,A6),D2

MOVE.L D0,D2

Source swapping refers to a similar situation where the value of a register variable

is moved to a working register before being used in a calculation. In this case, the

peephole optimizer will recognize that the calculation may just as well be made

using the register variable, and a MOVE instruction will be saved.

Redundant Test Removal

Sometimes the compiler will generate a TST instruction without knowing that the

condition codes were set by a previous instruction. The peephole optimizer can

recognize this situation and remove the redundant test. For example:

ADD.L D0,(S_i,A6)

TST.L (S_i,A6) ; This instruction is removed.

BNE L_001

If the peephole optimizer can determine that a working register (A0, A1, D0, D1,

FP0 or FP1) is not used in a function, it will reallocate a register variable to the

working register. This optimization will save a "push" instruction on function

entry and a "pop" instruction on function exit.

Chapter 5: Optimizations

The Optimize Option

103

Effect of

volatile

Data on Peephole Optimizations

Any function that includes a volatile declaration or which follows any volatile

declaration in a file will not have "data motion" optimizations performed on it.

Data motion optimizations include redundant load elimination, strength reduction

optimizations, source and destination swaps, and redundant test removal.

These optimizations account for considerably less than half of the space savings

and roughly half of the speed savings that the peephole optimizer is capable of.

Branch shortening and branch structure simplification optimizations (tail merging,

redundant jump elimination, and unreachable code elimination) are unaffected by

volatile data.

Function Entry and Exit

The -O option also affects function entry and exit code. Whenever a called function

has no parameters, no automatics, and returns a result whose size is eight bytes or

less, the LINK and UNLINK instructions which are used to push the old stack

frame pointer at function entry and restore the frame pointer on exit are not

generated.

In-Line Expansion of Standard Functions

Certain standard functions have traditionally been implemented as macros (e.g.,

putc()), and errors are generated if such functions are assigned to function pointers.

All other standard functions in libc and libm have traditionally been implemented

with calls to support library routines. This is consistent with C’s notion of having

no built-in functions, and the user could rewrite these routines at will.

With the advent of standard definitions for these functions defined by ANSI, it is

possible to expand these functions in-line, generally saving both time and space.

This is particularly true in the presence of the "generate code for the 68881/2"

command line option when a routine such as tan() reduces to a single instruction.

Of course, the assignment of these routines to function pointers requires that they

be called rather than expanded in-line.

Routines that are expanded in-line even without the "generate code for the

68881/2" command line option are:

strcmp strcpy strlen

fabs (

68040 only

) sqrt (

68040 only

)

Chapter 5: Optimizations

The Optimize Option

104

For the 68020 and 68030, routines that are expanded in-line only in the presence of

the "generate code for the 68881/2" command line option are:

acos fint fsincos

asin fetoxm1 log

atan flog2 log10

cos flognp1 sqrt

cosh ftentox sin

exp ftwotox sinh

fabs fatanh tan

tanh

The appropriate header file (string.h, math.h, or m6888x.h) must be included for

in-line expansion to occur.

Chapter 5: Optimizations

The Optimize Option

105

68332 TBL functions

For the 68332, the following functions are expanded in-line to give you direct

access to the TBL instruction:

tableS interpolateS

tableSN interpolateSN

tableU interpolateU

tableUN interpolateUN

Preventing expansion

Because it is conceivable that someone might want to substitute their own function

for a standard one, the "do not expand standard functions in-line" (-Wc,-I)

command line option turns off this default optimization.

It is also possible to prevent in-line expansion by using your own header file.

Comments in the supplied header file explain how the definitions affect

optimization.

What to do when optimization causes problems

Occasionally, the peephole optimizer can make incorrect assumptions, resulting in

code that does not execute properly. Use the -Wo,-m command-line option to

eliminate some of the risky optimizations (especially common sub-expression

optimizations). If the code still doesn’t execute properly, you may need to avoid

the -O optimizations.

Chapter 5: Optimizations

The Optimize Option

106

Embedded Systems Considerations

Issues to consider when using the C compiler to generate code for your target

system.

Chapter 6: Embedded Systems Considerations

107

Execution Environments

The compiler cannot know the design of your target system. Therefore, all

high-level functions and library routines depend on environment-dependent

libraries to supply low-level hooks into the target execution environment.

The environment-dependent routines which are supplied with the compiler allow

programs produced by the compiler to execute in an emulator. The supplied

routines also support the debugger/simulator. Use these files as examples to create

your own environment-dependent routines. We expect that you will need to modify

the supplied files. You must use your own knowledge of your target system to

decide what changes must be made.

Monitor and mon_stub

Current HP emulators use background monitors instead of foreground monitors.

The environment files do not have a monitor program. Instead, there is a program

(and accompanying source) called mon_stub. The mon_stub program completes

the environment in the absence of the emulator monitor program. mon_stub does

the following:

•Contains the trap vector table.

•Declares identifiers to satisfy external references in the env.a

environment-dependent library.

•Acts as a template when you create your own version of the

environment-dependent routines.

Chapter 6: Embedded Systems Considerations

Execution Environments

108

Common problems when compiling for an

emulator

If you plan to execute your program in an emulator environment, follow these

guidelines:

•Copy emulation configuration files (*.EA) from the environment directory to a

local directory prior to using.

•Use #pragma SECTION DATA=idata to specify the section for "initialized"

data external declarations when using the -d option (separate initialized and

uninitialized data).

Loading supplied emulation configuration files

Symptoms: In the emulator, one of the two supplied emulation configuration

files is loaded from the directory /usr/hp64000/env/hp<emulator_environment>

and the following error message appears:

ERROR: Cannot build

/usr/hp64000/env/hp

<emulator_environment>

/ioconfig

Description: There are two forms of emulator configuration files. The first form

(.EA), which is supplied, is an ASCII file. The second form (.EB), which is

created from the ASCII file by the emulator, is a binary file. This binary file is not

portable between versions of HP 64000 emulators and therefore not supplied.

When loading a configuration file, the emulator attempts to create the binary

version of the file if one does not already exist. This binary file is created in the

same directory as the ASCII file. The directory which contains the supplied

configuration files is not meant to be modified and is write-protected. In order to

use the supplied configuration file, it must first be copied to a local (writable)

directory.

Chapter 6: Embedded Systems Considerations

Common problems when compiling for an emulator

109

Using the "-d" option

Symptoms: During compilation, cc68k displays the following warning:

warning- Extern ’variable_name’ assumed to be in UDATA.

Description: The "Separate Initialized and Uninitialized Data" option (-d)

causes the compiler to place static variable definitions with initializers in section

idata by default, and static variable definitions without initializers in section udata

by default. When an external declaration of a static variable is encountered the

compiler assumes the external variable is uninitialized, places the external

declaration in section udata, and issues a warning regarding this assumption. It is

very important that if the external is instead an initialized variable that this warning

be heeded and the external declaration placed in the proper section (idata). To do

this, place a #pragma SECTION DATA=idata directive before the initialized

variable’s external declaration and a #pragma SECTION UNDO following it. The

second pragma merely "undoes" the first pragma. See the "Embedded Systems"

chapter for more details on using these pragmas.

Chapter 6: Embedded Systems Considerations

Common problems when compiling for an emulator

110

Section Names

Section names are used by the linker/loader to locate program code and data at the

addresses appropriate for the target system environment. Code generated by the

compiler is placed in relocatable program sections as follows:

•Executable code is placed in the PROG section (named prog by default).

•Static variables are placed in the DATA section (named data by default).

•Constants and string literals are placed in the CONST section (named const by

default).

The section name information is also used when specifying (through a compiler

command option) the addressing modes to be used for symbol accesses from one

section to another. (For more information on specifying addressing modes, refer to

the "Addressing Modes" section which follows.)

The default names given to the PROG, DATA, and CONST sections (prog, data,

and const, respectively) may be changed with the SECTION pragma in the C

source file.

The linker checks that external functions or data declared to be in a particular

section are indeed found in that section. This checking is defeated for the default

sections named prog, data, and const. This is done to accommodate existing C

programs which often declare extern C library functions without any SECTION

pragma. Note that all header (.h) files for libraries do include the appropriate

extern declarations with the correct section pragmas.

If there are multiple declarations for the same symbol within a single file, the

compiler checks that the section in which the symbol is declared is the same in all

cases; if it is not, an error is reported. An exception is made for this checking when

both declarations are external references and the "specify addressing modes" (-m)

command line option has not been given.

#pragma SECTION

Syntax:

#pragma SECTION [PROG=pname] [DATA=dname] [CONST=cname]

#pragma SECTION [PROG=address [BP]] [DATA=address [BP]] [CONST=address [BP]]

#pragma SECTION [PROG=pname] [UDATA=udname] [IDATA=idname] [CONST=cname]

Chapter 6: Embedded Systems Considerations

Section Names

111

#pragma SECTION [PROG=address [BP]] [UDATA=address [BP]] [IDATA=address [BP]]

[CONST=address [BP]]

#pragma SECTION UNDO

Description

The first form of this pragma causes the program, static data, and static constant

information to be placed in sections named pname, dname, and cname respectively

until the next SECTION pragma is encountered. The linker also expects to find

external functions and data in these named sections.

In the second form, absolute addresses are given in place of the segment names

causing the subsequent information to be ORG’d starting at the given address. An

optional BP may be given after such an address to indicate that it is in the base

page and that absolute short addressing should be used to access that location rather

than absolute long.

Note When absolute addresses are used, all information (program, data, or constant) to

be ORG’d must immediately follow the #pragma SECTION line and come prior

to any information (program, data, or constant) which is output in another named or

ORG’d segment. For example:

#pragma SECTION DATA=0x1000

int i, j, k;

const int l;

int m, n, o;

will cause an error since constant integer "l" is output in another section (const) and

since integers "m, n, o" also need to be ORG’d as they are data. Corrected this

becomes:

#pragma SECTION DATA=0x1000

int i, j, k;

int m, n, o;

const int l;

Other cases that cause information to be put out in new sections include: extern

definitions and string literals.

The third and fourth forms listed are the same as the first two forms with UDATA

and IDATA substituted for DATA. These forms make sense only in the presence

Chapter 6: Embedded Systems Considerations

Section Names

112

of the "separate initialized and uninitialized data" option (-d) which forces

separation of explicitly initialized data from implicitly initialized (or uninitialized

with -u) data. Non-constant static data items explicitly initialized by means of a C

initializer go into the IDATA named section. Non-constant static data items not

explicitly initialized by means of a C initializer go into the UDATA named section.

Watch for the "extern variable assumed to be in UDATA" warning message. If the

variable is initialized, place it in the IDATA section by naming the DATA section

to be the same as the IDATA section. For example:

#pragma SECTION UDATA=UDataSec IDATA=IDataSec

extern int x; /* */

#pragma SECTION UNDO /* Both x and y will go */

/* in the UDATA section. */

#pragma SECTION IDATA=IDataSec /* */

extern int y; /* */

#pragma SECTION UNDO

#pragma SECTION DATA=IDataSec /* z will go in the */

extern int z; /* IDATA section. */

#pragma SECTION UNDO

The absolute addresses and segment names may be intermixed for the three (four,

counting UDATA and IDATA) different information types (program, static data,

static constant) in the same SECTION pragma. If the target section is not specified

for one of the information types, then it remains unchanged.

The last form, #pragma SECTION UNDO, "undoes" the effect of the

immediately preceding SECTION directive. That is, it restores the name (or

address) of any section renamed (or ORG’d) in the last directive. This form is

useful at the end of #include files to restore the section environment which existed

prior to the #include file. (Include files must contain SECTION directives to

define the sections that externs are in.)

The SECTION pragma must be placed outside a function body.

Note #pragma SECTION UNDO is implemented by a one-level-deep stack. That is,

only the most recent SECTION pragma may be "undone" or, said another way,

two #pragma SECTION UNDOs in a row will not undo two SECTION pragmas.

This is of particular importance when an include file further includes other files.

Since include files will generally surround their extern declarations with a

SECTION-SECTION UNDO pair, care must be taken not to put an include inside

of this pair as it will result logically in two "UNDO"s in a row.

Chapter 6: Embedded Systems Considerations

Section Names

113

Addressing Modes

The C compiler allows you to specify the addressing mode to be used when

references are made from one section to static variables and functions defined in

the same or other sections. Only references to variables and function calls are

affected; branches are always PC relative. Sections are the named sections which

are understood by the linker.

In some situations, selecting the appropriate addressing mode is critical. In other

situations, selecting the appropriate addressing mode (short vs. long) can be a way

of generating more efficient code.

The appropriate addressing mode to use depends on such questions as:

•Is the data on base page? (The absolute short addressing mode can be used

to access this data; instructions will use 16-bit addresses instead of 32-bit

addresses.)

•Is the data near to the accessing code? (The PC relative short addressing

mode can be used to read locations within +/- 32K bytes; instructions will use

16-bit signed displacements instead of 32-bit absolute addresses. Program

Counter relative writes are not directly supported by the 68000; they can be

simulated by the compiler, but they will cost more time and space than

absolute long writes.)

•If the data is not on the base page, is it less than 64K bytes in length? (The

A5 relative short addressing mode can be used to access data in a 64K byte

block; instructions will access data with 16-bit signed displacements instead of

32-bit absolute addresses. The effect is a second base page.)

•Does the code need to be position independent? (No absolute addresses

may be used.)

•Does the code operate on run-time dynamically relocated data? (A5

relative addressing modes must be used.)

There are six 68000 addressing modes available to the C programmer: absolute

short, absolute long, PC relative short, PC relative long, A5 relative short, and A5

relative long. The default addressing mode used is absolute long.

Chapter 6: Embedded Systems Considerations

Addressing Modes

114

Specifying addressing modes

Addressing modes are specified with a command line option. You can specify that

a certain addressing mode be used on accesses from one section to another, from

one section to all sections, from all sections to one section, or from all sections to

all other sections. Sections are named by default (prog, data, and const) or with

the SECTION pragma in the C source file. (See the on-line man page for a

description of the "mode" command line option. See also the section on

"Addressing Modes Used in Libraries" in the "Libraries" chapter.)

Note The 68000 does not support the PC relative long and A5 relative long addressing

modes directly. The compiler generates code to calculate the proper addresses.

These instructions are more expensive in terms of time and space than absolute

long mode instructions.

When to use certain addressing modes

Certain situations are associated with the use of a particular addressing mode.

Listed below are the situations generally associated with the six addressing modes.

Mode Situation

Absolute Short The absolute short addressing mode can be used when

accesses are made to code or data in the address range

0xFFFF8000 to 0x7FFF (base page).

Absolute Long This is the default addressing mode. The absolute long

addressing mode is typically used when accesses are made

to locations outside the base page.

PC Relative Short The program counter relative short addressing mode is

used when you wish to create position independent code

and when that code accesses locations within +/- 32K bytes

of the current program counter location.

PC Relative Long The program counter relative long addressing mode is used

when you wish to create position independent code and

when that code accesses locations which are greater than

+/- 32K bytes away from the current program counter

location.

Chapter 6: Embedded Systems Considerations

Addressing Modes

115

A5 Relative Short The A5 relative short addressing mode is used when

accessing locations relative to an address (in register A5)

which are less than +/- 32K bytes away from that address.

The run-time value of the A5 register can be specified

when linking, and register A5 can be initialized with that

run-time value (as it is in the setup object file crt0).

A5 Relative Long The A5 relative long addressing mode is used when

accessing locations relative to an address (in register A5)

which are greater than +/- 32K bytes away from that

address. The run-time value of the A5 register can be

specified when linking, and register A5 can be initialized

with that run-time value (as it is in the setup object file

crt0).

Short vs. long

The "short" addressing modes are associated with 16-bit offsets. In the case of the

absolute mode, short means that addresses can be accessed with 16-bits; in other

words, they are located in the address range -32K to +32K (0xFFFF8000 to

0x7FFF). In the case of the PC and A5 relative addressing modes, short means

16-bit signed displacements are used. Signed 16-bit displacements allow accesses

to locations within +/- 32K bytes of the program counter or address in A5.

Note When using the short addressing modes, the compiler will assume that program or

data references are within the short (signed 16-bit) range. If the accessed code or

data does not fit within that range, assembler or linker errors will result.

The "long" addressing modes are associated with 32-bit quantities. The absolute

long mode, which is the default, allows locations anywhere in the microprocessor

address space to be accessed.

In the PC and A5 relative addressing modes, long also means that locations

anywhere in the microprocessor address space can be accessed, except that these

modes use 32-bit signed offsets.

Using the short addressing modes generates more efficient code in the sense that

instructions will have one less word of extension, causing shorter code which

executes faster.

Chapter 6: Embedded Systems Considerations

Addressing Modes

116

For the 68000, note that the PC and A5 relative long modes are not supported by

the 68000, and the compiler generates code to calculate the proper addresses.

Consequently, these modes are less efficient.

Absolute addressing modes

Since a section is the smallest piece of code for which an addressing mode can be

selected (with the exception of using assembly language), the absolute addressing

mode you choose (long or short) will depend upon where sections are to be located

with the linker. For example, suppose one of your programs calls a library function;

if the library function’s program section is to be located in the base page, you

would then specify the absolute short mode for references from your program

section to the library program section (lib, libc, libm, etc.).

PC relative addressing modes

The PC relative addressing modes allow you to create position independent code.

Also, in certain situations, the PC relative short addressing mode allows you to

access data or call functions more efficiently than the absolute long addressing

mode.

Position independent code

In general, a position independent code section uses PC relative function calls and

branches and accesses only local data (on the stack). This is readily accomplished

by specifying PC relative short (if the segment fits into 64K bytes) or long as the

addressing mode used for accesses from the position independent section to itself.

If the position independent code section must declare or access static data, different

addressing modes will be appropriate depending on the desired functionality. First

of all, it may be acceptable to have the code depend on the location of static data

(i.e., absolute addresses may be used). Secondly, it may be desirable to force the

static data to be located in a fixed location relative to the position independent code

and, thus, PC relative access would be appropriate. Finally, it may be necessary to

allow the code to be located anywhere and its static data to be located anywhere. In

this case, A5 relative addressing should be used, and A5 should be loaded with the

appropriate value relative to the location of the static data. In these last two cases

(static data being accessed PC relative or A5 relative), care should be taken to

avoid absolute addresses of static data inadvertently appearing as load-time

initializers. For example:

Chapter 6: Embedded Systems Considerations

Addressing Modes

117

int j;

int *i = &j;

char *p = "abc";

The declarations above would result in "i" being initialized with the absolute

address of "j" and in "p" being initialized with the absolute address of the constant

string "abc".

Accessing near locations

The PC relative short addressing mode can be used to advantage when a program

accesses code or data which is nearby. If locations are within +/- 32K bytes of the

current program counter, they can be accessed with PC relative short instructions

which use 16-bit signed displacements. Alternatively, absolute long mode

instructions would use 32-bit absolute addresses.

Note The 68000 does not support PC relative data writes. The compiler creates this

addressing mode from multiple instructions. These instructions are more expensive

in terms of time and space than absolute long mode instructions.

Branches within functions (68000 only)

By default, the compiler generates PC relative short branches for "goto"s in control

flow constructs within functions. Rarely, the code around which a "goto" must

jump will exceed 32K bytes. In this case, an assembly time error will result.

The "big switch tables" option the the C compiler causes the compiler to use PC

relative long branches. Such branches are not directly available in the 68000

instruction set and are "manufactured" from a series of instructions. The optimizer

will shorten these except when required.

A5 relative addressing modes

The A5 relative addressing modes can be used to advantage in many types of

situations. A few of the most general situations are described here.

Creating a second "base page"

Suppose that a program accesses a 64K byte block of data located at an address off

of the base page. Without A5 relative addressing, this data would have to be

accessed with an absolute long or PC relative addressing mode. However, with A5

Chapter 6: Embedded Systems Considerations

Addressing Modes

118

relative addressing, you can load register A5 with the address of the mid-point of

the data section and access 64K bytes of data using the A5 relative short mode. The

A5 relative short addressing mode is more efficient than the absolute long mode

because it uses 16-bit signed displacements instead of 32-bit absolute addresses.

Chapter 6: Embedded Systems Considerations

Addressing Modes

119

If the "run-time" value of A5 is set equal to the base

address of the data section plus 8000H, then 64K bytes

of data may be accessed with 16-bit displacements

using the A5 relative short addressing mode.

When using the A5 relative short addressing mode in

this way, instructions such as "move memory (relative

to A5) into register" generate 2 words of code instead

of the 3 words of code generated by instructions such

as "move memory into register."

Using the A5 relative short addressing mode in this

manner can be thought of as creating a second "base

page."

Figure 6-1. Creating a Second Base Page

07FFFH

PROGRAM

64K BYTE

DATA AREA A5

0FFFF 8000H

0FFFF FFFFH

Chapter 6: Embedded Systems Considerations

Addressing Modes

120

Shared programs

When a program is shared, it may have to operate on separate data areas associated

with each user. Only local variables and ROM variables (global or static) may be

used by shared programs. When programs are shared, the A5 register is used as a

pointer to the user’s data area.

Figure 6-2. Shared Programs

Chapter 6: Embedded Systems Considerations

Addressing Modes

121

Other addressing mode considerations

When embedding assembly language in C source files, make sure that your

assembly language instructions agree with the addressing mode you have selected

for that section. For example, you would not code absolute mode jump instructions

in a PC relative mode program section.

RAM and ROM Considerations

This section addresses special considerations of loading your programs into RAM

and ROM environments.

Initialized data

The C language specifies that, without explicit initialization, external and static

variables will be initialized to zero. Declarator initializers allow you to specify

initial values other than zero.

These initial values, or default values of zero, are written to static variables at

load-time. Programs executed in operating systems, in emulation environments, or

in simulation environments, have a "load-time" and initialization is possible.

Embedded environments, however, have no "load-time", and statics and externals

cannot be initialized (either to zero or any other value). As an example, when a

target system is powered up, the contents of RAM data locations are not known.

Symbols declared with the const type modifier are considered to be ROM locations

and are initialized by definition.

The "uninitialized" option

There is an "uninitialized data" option (-u) to the compiler which will cause

warning messages to be printed whenever static initializers are used in

non-constant declarations. Also, the generated assembly language declarations no

longer initialize static data to zero (as is done when the "uninitialized data" option

is not specified).

Chapter 6: Embedded Systems Considerations

RAM and ROM Considerations

122

This option cannot check for the use of a static or external variable which has not

been assigned a value (although the compiler generates warnings occasionally), so

make sure your programs do not assume an initialized value.

Where to load constants

For ROM/RAM embedded systems, the program and constants will ultimately

reside in ROM. In anticipation of this environment, the default sections prog and

const contain ROMable information, and the default section data contains

RAMable information.

Embedded Systems with Mass Storage

Systems which load programs from mass storage differ from pure ROM/RAM

systems in that a load time exists when alterable data can be initialized. The C

language anticipates such a load time by allowing variable data to be declared with

initializers. When static data is declared with an initializer, such initialization

occurs at load time. Indeed C specifies that static data which is not explicitly

initialized will be initialized to zero at load time.

To facilitate load time initialization of static data, a command line option has been

provided to separate explicitly initialized data from uninitialized (or initialized to

zero at load time) data into different named sections. By default, these sections are

named idata and udata; but these names can be changed using #pragma

SECTION (see above).

The value of the "separate initialized and unitialized data" option is that it allows

the loader to load initialized static data contiguously into RAM from the idata

section. It can then, if desired, initialize the udata section’s locations to zero in an

efficient contiguous manner.

The use of the "separate initialized from uninitialized" option together with the

"uninitialized data" option (described above) supports emulation of an environment

with a load time (for initializing explicitly initialized static data) which does not

initialize uninitialized data to zero. When used together, the compiler does not

warn explicit initializations of non-constant static data, but places such data in

section idata (by default). Static data which is not explicitly initialized, is reserved

space in section udata (by default), but is not initialized to zero at

emulation/simulation load time.

Chapter 6: Embedded Systems Considerations

Embedded Systems with Mass Storage

123

The "volatile" Type Modifier

The volatile type modifier is used in declarations to specify that an object’s value

may change in ways unknown to the compiler. A volatile type modifier makes the

compiler access an object literally, as specified in C statements. Literal

interpretations of C statements can be important in programs which are closely tied

to hardware such as memory mapped I/O devices or device drivers. The volatile

type modifier is necessary because optimizations can take short-cuts, using

methods which differ from the literal interpretation but which yield the same result.

The listings shown in figure 6-3 give an example of the effect given by the volatile

type modifier. The top listing shows code in which the assignment of "io_port" to

"secondValue" has been optimized into a "MOVE.L D0,D4" instruction which

does not actually read "io_port" (whose value may have changed since its

assignment to "firstValue"). The bottom listing shows the "io_port" variable

declared with the volatile type modifier. Notice that the assignment of "io_port" to

"secondValue" does not get optimized.

For the user who wants a controlled way of toggling an address line, it is

guaranteed that a simple assignment to a volatile variable which has a size equal to

the data bus width of the target processor will cause exactly one write. An access of

such a variable will cause exactly one read. For example:

volatile int *p = (int *)1234; /* int size = bus width.

1234 is address of I/O port. */

main()

{

*p = 0; /* Exactly one write to address 1234. */

*p; /* Exactly one read of address 1234. */

}

A pointer-to-volatile cannot be assigned to a pointer-to-non-volatile without a cast.

Note If the "word align data" option is on, short and int variables may be accessed with

two reads or writes instead of just one.

Chapter 6: Embedded Systems Considerations

The "volatile" Type Modifier

124

1 int io_port;

3 main()

4 {

XDEF _main

_main

00000000 2F04 MOVE.L D4,-(A7)

* Register ’D0’ is register variable ’S_firstValue’.

* Register ’D4’ is register variable ’S_secondValue’.

* Register ’D1’ is register variable ’S_tmp’.

5 int firstValue, secondValue, tmp;

7 firstValue = io_port;

00000002 2039 0000 0000 R MOVE.L (_io_port+0).L,D0

8 secondValue = io_port;

00000008 2800 MOVE.L D0,D4

9 tmp = firstValue;

0000000A 2200 MOVE.L D0,D1

10 }

---------------------------------------------------------------------------------

1 volatile int io_port;

3 main()

4 {

XDEF _main

_main

00000000 2F04 MOVE.L D4,-(A7)

* Register ’D0’ is register variable ’S_firstValue’.

* Register ’D4’ is register variable ’S_secondValue’.

* Register ’D1’ is register variable ’S_tmp’.

5 int firstValue, secondValue, tmp;

7 firstValue = io_port;

00000002 2039 0000 0000 R MOVE.L (_io_port+0).L,D0

8 secondValue = io_port;

00000008 2839 0000 0000 R MOVE.L (_io_port+0).L,D4

9 tmp = firstValue;

0000000E 2200 MOVE.L D0,D1

10 }

Figure 6-3. "volatile" Type Modifier Example

OPTIMIZATION

PERFORMED

NO OPTIMIZATION

PERFORMED

Chapter 6: Embedded Systems Considerations

The "volatile" Type Modifier

125

Reentrant Code

Reentrant code is code that can be interrupted during its execution and re-invoked

by subsequent calls any number of times. A nonreentrant routine might, for

example, operate on static data or external variables; if this routine is interrupted

and called from somewhere else, the data it was originally operating on might be

destroyed. Interrupt handlers and other routines which may be interrupted and

called again must be reentrant.

The C compiler generates reentrant code.

Nonreentrant library routines

Most of the library routines which have been shipped with the compiler are

reentrant. However, some of the libraries are not reentrant; they are listed below.

Nonreentrant routines should not be called from interrupt handlers or other

reentrant routines.

Some libraries use the global symbol errno. Note that the value of errno can be

overwritten in a multitasking or reentrant environment.

assert

atexit

calloc

fclose

fflush

fgetc

fgetpos

fgets

fopen

fprintf

fputc

fputs

fread

free

freopen

fscanf

fseek

fsetpos

ftell

fwrite

getc

getchar

gets

lseek

malloc

open

printf

putc

putchar

puts

rand

read

realloc

remove

rewind

scanf

setbuf

setvbuf

srand

strtok

strtol

ungetc

unlink

vfprintf

vprintf

write

Table 6-1. Nonreentrant Library Routines

Chapter 6: Embedded Systems Considerations

Reentrant Code

126

Implementing Functions as Interrupt Routines

Interrupt routines are not intended to return values. Therefore, the type specifier

void must be used to declare functions which you wish to implement as interrupt

routines. The INTERRUPT pragma is used to specify that a function should be

implemented as an interrupt routine.

#pragma INTERRUPT

This pragma specifies that the next encountered function be implemented as an

interrupt routine. This means that all working registers are saved at function entry

(in addition to the register variables which ordinarily are saved), no parameter

passing or returned result is allowed, and a return from interrupt is generated at the

return point. Note that only the next encountered function is affected--not

subsequent functions.

The INTERRUPT pragma may be used any place a C external declaration may.

An example of a function implemented as an interrupt routine is shown below.

#pragma INTERRUPT

void int_routine()

{

}

Loading the vector address

Using the INTERRUPT pragma will cause all registers to be pushed onto the stack

upon function entry, and a return from interrupt instruction is generated for

function exit. However, you must make sure that the address of the function is

loaded into the vector table. For example, the emulator monitor stub program uses

some interrupt vectors. The source for mon_stub.s contains vector tables which

may be modified to contain the address of your interrupt handler written in C.

Chapter 6: Embedded Systems Considerations

Implementing Functions as Interrupt Routines

127

In your own target system, it will be easiest to implement your vector table in C.

For example, if you had implemented one routine totally in assembly language and

named it "_asm_int_routine", you could declare your vector table and initialize it

with:

extern void asm_int_routine();

#pragma SECTION DATA=0x00

void (*vectorTable[])() = {. . ., asm_int_routine, . . .,

int_routine, . . .};

#pragma SECTION UNDO

#pragma INTERRUPT

void int_routine() {

}

Eliminating I/O

Your embedded system may well have no file I/O capability. If this is the case,

you can specify a linker command file which avoids the overhead of initializing

emulation simulated I/O buffers for stdin, stdout, and stderr. See the description of

cc68k in the on-line man page.

Chapter 6: Embedded Systems Considerations

Eliminating I/O

128

Libraries

Descriptions of the run-time and support libraries.

Chapter 7: Libraries

129

Two varieties of libraries are provided with the Motorola 68000 Family C Cross

Compiler. First are the run-time libraries which contain routines required to do real

number arithmetic, initializations, run-time debug checks, etc. Second are the

support libraries for which both a ".h" include file and the library object code are

provided.

Addressing Modes Used in Libraries

Three versions of the library routines are provided: position dependent versions,

and two position independent versions.

The position dependent versions of the library routines access static data with the

absolute long mode, call other library routines in the same named library section

with the PC relative short mode, and call library routines across named library

sections with the absolute long mode.

The position independent versions of the library routines access static data with the

A5 relative long mode, call other library routines in the same named library section

with the PC relative short mode, and call library routines across named library

sections with the PC relative long mode.

The program-counter relative versions of the library routines access static data with

the PC relative long mode, call other library routines in the same named library

section with the PC relative short mode, and call library routines across named

library sections with the PC relative long mode.

Chapter 7: Libraries

130

Library Names

The absolute and position-independent versions of the default libraries (which are

included by cc68k when linking) are:

The run-time, support, and math libraries are included by the default linker

command file. When the "generate code for the 68881/2" command line option is

used, the 68881/2 run-time and math libraries are also included by the default

linker command file. Because there are no real numbers in the support libraries,

there is no 68881/2 version of the support library.

Controlling the Addressing Mode of the Calling Code

You can control the addressing modes used for calls to libraries in the same manner

as you would control the addressing modes throughout your program. The "mode"

option to the cc68k command allows you to specify the addressing modes which

are generated when one section makes references to static variables or functions

which are defined in the same or a different section.

Run-time library modules are all located in linker section name lib. The same

addressing mode must be used to call run-time library modules throughout a source

file.

Library: Absolute Version

(PROG Section

Name)

Position-Independent

Version

(PROG Section Name)

PC-Relative Version

(PROG Section Name)

Run-time library

Support library

Math library

lib.a (lib)

libc.a (libc)

libm.a (libm)

libpi.a (lib)

libcpi.a (libc)

libmpi.a (libm)

libpc.a (lib)

libcpc.a (libc)

libmpc.a (libm)

Table 7-1. Absolute/Position-Independent Library Names

Chapter 7: Libraries

131

Support and math libraries are located in section names libc and libm, respectively.

The 68881/2 math library modules are located in section name libm. These section

names may be used just as any other section names would be (for example, in

SECTION pragmas or in the "mode" command line option provided include files

are used). See the on-line man pages for a complete description of the cc68k

command syntax and options.

Run-Time Library Routines

The run-time library, lib.a or lib881.a, contains routines used at run-time by the

compiler-generated code to implement operations which, for one reason or another,

are better accomplished in a subroutine than in-line. The reasons for encoding an

operation in a run-time library routine instead of in-line vary from conserving

space to minimizing repetition of in-line code to maintenance considerations (the

same reasons functions are used in C).

Although run-time library routines are usually used only by the compiler, they may

be called from assembly code (including embedded assembly code within the C

source). Also, it is possible to replace any or all of the routines with your own

routines. See the "Run-Time Library Description" chapter for descriptions of the

interface and functionality of all run-time library routines.

Run-time libraries, unlike user routines, generally receive their parameters in the

compiler’s "working" registers (A0, A1, D0, D1). Their results are generally

returned in a similar manner as results which are returned from user routines. See

the "Run-Time Library Description" chapter for detailed information on specific

routines.

In the presence of the "generate code for the 68881/2" option, most run-time

library routines are not called, but rather in-line 68881/2 instructions are used to

perform the operation.

Support Library and Math Library Routines

In general, the implementation of the support library routines is likely to deviate

subtly from the standard due to environment dependencies. Where possible, the

Chapter 7: Libraries

132

sources for these environment-dependent routines (which are customized to HP

development environments) are provided as part of the compiler product (see the

chapters describing "Environment Dependent Routines").

Especially in the presence of the "generate code for the 68881/2" option, certain

support and math library functions may be expanded in-line (see the "In-Line

Expansion of Standard Functions" section in the "Optimizations" chapter).

Certain support and math library functions may be expanded in-line (see the

"In-Line Expansion of Standard Functions" section in the "Optimizations" chapter).

Library Routines Not Provided

Several "standard" C library routines are not provided with the C compiler.

•General Utilities. The <stdlib.h> functions abort, getenv, and system are not

supported.

•Input/Output. The <stdio.h> definitions L_tmpnam, FILENAME_MAX,

and TMP_MAX, as well as the rename, tmpfile, and tmpnam routines, are

not supported.

•Signal Handling. The <signal.h> routines are not provided because of their

extreme environment dependencies.

•Date and Time. The <time.h> routines are not provided because of their

extreme environment dependencies.

Chapter 7: Libraries

133

Include (Header) Files

The following is a list of include files which are shipped with the compiler:

assert.h Defines the macro assert.

ctype.h Defines the "character classification" macros (e.g.,

isalnum, isalpha, etc.).

errno.h Declares errno and macros used to test errno.

float.h Describes the IEEE single- and double-precision

floating-point representations and contains definitions of

the limiting values of floating-point types.

fp_control.h Declares the floating-point error functions. This header

file also defines the macros which can be used as

arguments to the _set_fp_control function, or to check the

return value of the _get_fp_status function.

limits.h Contains definitions of the limiting values for integral

types.

locale.h Declares the setlocale and localeconv functions and

defines the lconv structure. Also defines the categories

which the functions can change.

math.h Declares the standard math library routines and

HUGE_VAL.

memory.h Declares sbrk and _getmem.

m68332.h Declares the table and interpolate routines.

m6888x.h Declares floating-point functions so that the 68881/2 FPU

will be used.

setjmp.h Defines the jmp_buf type and declares the setjmp and

longjmp functions.

simio.h Declares the simulated I/O functions and companion

macros.

Chapter 7: Libraries

134

stdarg.h Provides the va_list type and the macros which are used to

access variable-length argument lists, va_start, va_arg,

and va_end. For a description of the variable argument list

macros, see the entry for "va_list" in this chapter.

stddef.h Defines the ptrdiff_t, size_t, and wchar_t types and the

NULL null pointer constant. This header file also defines

the offsetof macro.

stdio.h Declares all the functions that handle input and output.

This header file also defines the FILE type, buffering

macros, file positioning macros, the maximum number of

open files, and buffer size macros.

stdlib.h Defines the types div_t and ldiv_t, and also the macros

EXIT_SUCCESS, EXIT_FAILURE, RAND_MAX, and

MB_CUR_MAX. This header file also declares standard

library functions.

string.h Declares the character string and memory operations.

Chapter 7: Libraries

135

List of All Library Routines

The following table lists all of the library routines shipped with this compiler.

An asterisk (*) in the Index column means that you can find a description of the

routine in this manual by looking in the index.

The routines not marked with an asterisk are not described in this manual. These

routines are run-time routines or subroutines used by the libraries. You should not

use these undocumented routines in your programs because they are likely to be

changed or even deleted in future versions of the compiler.

Index Definition name Library

___tableS libc.a

___tableSN libc.a

___tableU libc.a

___tableUN libc.a

__assert libc.a

__bufsync libc.a

*__clear_fp_status lib.a

libm.a

__dbl_to_str libc.a

__display_message lib.a

__doprnt libc.a

__doscan libc.a

__exec_funcs libc.a

*__exit libc.a

Index Definition name Library

__filbuf libc.a

__findbuf libc.a

__findiop libc.a

__flsbuf libc.a

*__fp_control lib.a

libm.a

*__fp_error lib.a

*__fp_error libm.a

__fp_errorf lib.a

__fp_errori lib.a

*__fp_status lib.a

libm.a

*__get_fp_control lib.a

libm.a

*__get_fp_status lib.a

libm.a

Chapter 7: Libraries

136

Index Definition name Library

*__getmem libc.a

__memccpy libc.a

__readFile libc.a

__readStr libc.a

*__set_fp_control lib.a

libm.a

__swrite libc.a

__wrtchk libc.a

__xflsbuf libc.a

*_abs libc.a

*_acos libm.a

*_asin libm.a

*_atan libm.a

*_atexit libc.a

*_atof libc.a

*_atoi libc.a

*_atol libc.a

*_bsearch libc.a

*_calloc libc.a

*_ceil libm.a

*_clearerr libc.a

Index Definition name Library

*_close libc.a

*_cos libm.a

*_cosh libm.a

*_div libc.a

*_errno lib.a

libc.a

libm.a

*_exp libm.a

*_fabs libm.a

*_fclose libc.a

*_feof libc.a

*_ferror libc.a

*_fflush libc.a

*_fgetc libc.a

*_fgetpos libc.a

*_fgets libc.a

*_floor libm.a

*_fmod libm.a

*_fopen libc.a

*_fprintf libc.a

*_fputc libc.a

Chapter 7: Libraries

137

Index Definition name Library

*_fputs libc.a

*_fread libc.a

*_free libc.a

*_frem libm.a

*_freopen libc.a

*_frexp libm.a

*_fscanf libc.a

*_fseek libc.a

*_fsetpos libc.a

*_ftell libc.a

*_fwrite libc.a

*_getc libc.a

*_getchar libc.a

*_gets libc.a

*_interpolateS libc.a

*_interpolateSN libc.a

*_interpolateU libc.a

*_interpolateUN libc.a

*_isalnum libc.a

*_isalpha libc.a

Index Definition name Library

*_iscntrl libc.a

*_isdigit libc.a

*_isgraph libc.a

*_islower libc.a

*_isprint libc.a

*_ispunct libc.a

*_isspace libc.a

*_isupper libc.a

*_isxdigit libc.a

*_labs libc.a

*_ldexp libm.a

*_ldiv libc.a

*_localeconv libc.a

*_log libm.a

*_longjmp libc.a

*_lseek libc.a

*_malloc libc.a

*_mblen libc.a

*_mbstowcs libc.a

*_mbtowc libc.a

Chapter 7: Libraries

138

Index Definition name Library

*_memchr libc.a

*_memcmp libc.a

*_memcpy libc.a

*_memmove libc.a

*_memset libc.a

*_modf libm.a

*_open libc.a

*_perror libc.a

*_pow libm.a

*_printf libc.a

*_putc libc.a

*_putchar libc.a

*_puts libc.a

*_qsort libc.a

*_rand libc.a

*_read libc.a

*_realloc libc.a

*_remove libc.a

*_rewind libc.a

*_scanf libc.a

Index Definition name Library

*_setbuf libc.a

*_setjmp libc.a

*_setlocale libc.a

*_setvbuf libc.a

*_sin libm.a

*_sinh libm.a

*_sprintf libc.a

*_sqrt libm.a

*_srand libc.a

*_sscanf libc.a

*_strcat libc.a

*_strchr libc.a

*_strcmp libc.a

*_strcoll libc.a

*_strcpy libc.a

*_strcspn libc.a

*_strerror libc.a

*_strlen libc.a

*_strncat libc.a

*_strncmp libc.a

Chapter 7: Libraries

139

Index Definition name Library

*_strncpy libc.a

*_strpbrk libc.a

*_strrchr libc.a

*_strspn libc.a

*_strstr libc.a

*_strtod libc.a

*_strtok libc.a

*_strtol libc.a

*_strtoul libc.a

*_strxfrm libc.a

*_tan libm.a

*_tanh libm.a

*_tolower libc.a

*_toupper libc.a

*_ungetc libc.a

*_unlink libc.a

*_vfprintf libc.a

*_vprintf libc.a

*_vsprintf libc.a

*_wcstombs libc.a

Index Definition name Library

*_wctomb libc.a

*_write libc.a

Chapter 7: Libraries

140

Support Library and Math Library Descriptions

The remainder of this chapter describes the support and math library functions.

Functions declared in the math.h include file are found in the math library archive

files libm.a, libmpi.a, libmpc.a, libm881.a, libm881pi.a, and libm881pc.a. All

other functions are found in the support library archive files libc.a, libcpi.a, and

libcpc.a.

Note The open, close, read, write, lseek, unlink, exit, _exit, _getmem,

and sbrk functions have execution environment dependencies; therefore, these

libraries are described in the "Environment-Dependent Routines" chapter.

Chapter 7: Libraries

141

abs, labs

Return Integer Absolute Value

Synopsis #include <stdlib.h>

int abs (int i);

long int labs (long int i);

Description Abs returns the absolute value of its integer operand.

Labs is similar to abs except that the argument and the returned value each have

type long int.

Warnings In two’s-complement representation, the absolute value of the negative integer with

the largest magnitude is undefined. This error is ignored.

Motorola 68000 Family C Cross Compiler B3640 97001_68000_C_Cross Compiler_Jan94 97001 Jan94

B3640-97001_68000_C_Cross-Compiler_Jan94 B3640-97001_68000_C_Cross-Compiler_Jan94

Navigation menu

Versions of this User Manual:

Views

Navigation