Digital PDFs

AA-H712D-TK

May 1984

292 pages

Original

10MB

Document:	BLISS-36 Users Guide Feb84
Order Number:	AA-H712D-TK
Revision:	0
Pages:	292
Original Filename:	AA-H712D-TK_BLISS-36_Users_Guide_Feb84.pdf

OCR Text

BLISS-36
User's Guide
Order No. AA-H712D-TK

February 1984
This document describes the BLlSS-36 compiler and its use, gives basic
information about linking, executing, and debugging BLlSS-36 programs,
and describes BLlSS-36 machine-specific functions, BLISS tools, and other
topics relevant to BLlSS-36 programming.

SUPERSESSION/UPDATE INFORMATION:

BLlSS-36 V4(216)

OPERATING SYSTEMS AND VERSIONS:

TOPS-10 V7.01A
TOPS-20 V5.1 (KL)
TOPS-20 V4.1 (KS)

SOFTWARE VERSION:

BLlSS-36 V4(216) implementing
BLISS language V4.0

digital equipment corporation · maynard, massachusetts

First Printing, June
Revised, September
Revised, February
Revised, February

1979
1980
1982
1984

The information in this document is subject to change without notice
and should not be construed as a commitment by Digital Equipment
Corporation.
Digital Equipment Cor~oration assumes no responsibility
for any errors that may appear in this document.
The software described in this document is furnished under a
license
and may be used or copied only in accordance with the terms of such
license.
No responsibility is assumed for the use or reliability of software on
equipment that is not supplied by Digital Equipment Corporation or its
affiliated companies.
Copyright

1979,1980,

1982, 1984 by Digital Equipment Corporation
All Rights Reserved.
Printed in U.S.A.

The postpaid READER'S COMMENTS form on the last page of this document
requests
the user's critical evaluation to assist in preparing future
documentation.
The following are trademarks of Digital Equipment Corporation:
DEC
DEC/CMS
DEC/MMS
DECnet
DECsystem-lO
OECSYSTEM-20
OECUS
DECwriter

OIBOL
EduSystern
lAS
MASSBUS
MICRO/PDP-II
Micro/RSX
PDP
PDT

RSTS
RSX
UNIBUS
VAX
VMS
VT

ZK2260

HOW TO ORDER ADDITIONAL DOCUMENTATION
In Continental USA and Puerto Rico call

800-258-1710

In New Hampshire, Alaska, and Hawaii call
In Canada call

603-884-6660

613-234-7726 (Ottawa-Hull)
800-267-6146 (all other Canadian)

DIRECT MAIL ORDERS (USA & PUERTO RICO)*
Digital Equipment Corporation
P.O. Box CS2008
Nashua, New Hampshire 03061

DIRECT MAIL ORDERS (CANADA)
Digital Equipment of Canada Ltd.
940 Belfast Road
Ottawa, Ontario K1G 4C2
Attn: A&SG Business Manager

DIRECT MAIL ORDERS (INTERNATIONAL)
Digital Equipment Corporation
A&SG Business Manager
c/o Digital's local subsidiary or
approved distributor

* Any prepaid order from Puerto Rico must be placed

with the local Digital subsidiary (809-754-7575)
Internal orders should be placed through the Software Distribution Center (SDC), Digital Equipment
Corporation, Northboro, Massachusetts 01532

CONTENTS
Page
PREFACE

SUMMARY OF TECHNICAL CHANGES

CHAPTER 1

TOPS-20 OPERATING PROCEDURES

1.1
COMPILING A BLISS PROGRAM
. . . 1-1
1.1.1
Command-Line Syntax
· 1-3
1.1.2
Command-Line Semantics .
· . . . . . . . . 1-3
1.2
FILE SPECIFICATIONS
. . . .
1-4
1.3
COMMAND-LINE SWITCHES
. . . .
· 1-5
1.3.1
Output Switches
. . . . . . . .
1-6
1.3.1.1
Syntax . . . . . .
. ...
· . . . . 1-7
Defaults . . .
. . . .
1.3.1.2
· 1-7
1.3.1.3
Semantics
. . 1-7
1.3.2
General Switches .
· . . . . 1-8
1.3.2.1
Syntax . .
... . . . . . . . ..
. . 1-9
1.3.2.2
Defaults . . . . . .
1-9
1.3.2.3
Semantics
. . . . . . .
. . ..
. . 1-9
1.3.3
Check Switch .
· . . . 1-10
1.3.3.1
Syntax . .
· . . . 1-10
1.3.3.2
Defaul ts . . .
1-10
1.3.3.3
Semantics
1-10
1.3.4
Terminal Switches
· . . . . . . .
1-11
1.3.4.1
Syntax . . . .
1-11
1.3.4.2
Defaults .
1-11
1.3.4.3
Semantics
1-11
1.3.5
Optimization Switches
1-12
1.3.5.1
Syntax . . . .
· . . . . 1-12
Defaults . . . . .
1.3.5.2
1-12
1.3.5.3
Semantics
. . . .
1-13
1.3.6
Listing Switches .
1-14
Syntax . . . . . .
1.3.6.1
1-14
1.3.6.2
Defaults . . . .
. . . . . .
1-15
1.3.6.3
Semantics
. . . .
1-15
1.3.7
Reference Switches .
· . . .
1-17
Syntax . . . . . .
1.3.7.1
1-18
Defaults . . . . .
1.3.7.2
1-18
1.3.7.3
Semantics
. . . .
1-18
Environment Switches .
1.3.8
1-18
Syntax . .
. ... .
1.3.8.1
· . . . . 1-19
Defaults . . . . .
... .
1.3.8.2
· . . . .
1-19
Semantics
. . . . . . . . . . . . . . . . . 1-19
1.3.8.3
Placement of Switches
.....
1.3.9
1-20
1.3.10
Switches and Default Module Switch Settings
1-20
positive and Negative Forms of Switches
1.3.11
1-22
1.3.12
Abbreviations of Switch and Value Names
1-22
1.4
SPECIAL FEATURES . . . . . .
1-22
1.4.1
Indirect Files
· . . . . 1-22
EXEC Command . . .
1.4.2
1-23
CHAPTER 2
2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2

TOPS-I0 OPERATING PROCEDURES
COMPILING A BLISS PROGRAM
Command-Line Syntax
. .
Command-Line Semantics .
FILE SPECIFICATIONS
Syntax . . . .
Semantics
.
w

•

iii

·
·
· ........
· ....
·
·

2-1
2-3
2-3
2-3
2-4
2-4

CONTENTS
2.2.3
Default Extension
· . . . . . 2-4
2.3
OUTPUT SPECIFICATIONS
2-5
. . . • . . . . • . . 2-6
2.4
COMMAND-LINE SWITCHES
Library Switches .
2.4.1
· . . . . 2-6
Syntax . . . . .
2.4.1.1
· . . . . 2-7
Defaults . • . .
2.4.1.2
· . . . . . 2-7
2.4.2
General SWitches .
. . . 2-7
2.4.2.1
Syntax . .
· 2-8
Defau1 ts . .
. . . . . . . . . . . . . . 2-8
2.4.2.2
Semantics
2.4.2.3
· 2-8
2.4.3
Check SWi tch .
· . . . . 2-8
Syntax . . .
2.4.3.1
. . 2-9
2.4.3.2
Defaults . .
. • 2-9
2.4.3.3
Semantics
· 2-9
2.4.4
Terminal SWitches
· 2-9
2.4.4.1
Syntax . . .
· . . .
2-10
2.4.4.2
Defaults .
2-10
. . . . . . . . . . .
2.4.4.3
Semantics
. . . . .
· . . .
2-10
2.4.5
Optimization SWitches
.... .
· . . . .
2-10
Syntax . . . .
. ... .
2.4.5.1
· . . . • 2-11
2.4.5.2
Defaults .
. ...
2-11
2.4.5.3
Semantics
· . . .
2-12
2.4.6
Listing SWitches . . . . .
· . . .
2-12
Syntax . . . . .
2.4.6.1
2-13
Defaults . . . .
2.4.6.2
2-13
2.4.6.3
Semantics
. . . .
· . . . .
2-13
2.4.7
Reference SWitches .
. . . • . . .
2-15
2.4.7.1
Syntax . . .
2-16
2.4.7.2
Defaults . . . . .
· . . . .
2-16
2.4.7.3
Semantics
· . . . .
2-17
2.4.8
Environment Switches
2-17
2.4.8.1
Syntax . . .
. .... .
· . . .
2-17
2.4.8.2
Defaults . . . . . . . . . . . . . . . .
2-17
2.4.8.3
Semantics
. . . . . . . . . .
· . . . .
2-18
2.4.9
Placement of Switches
2-18
2.4.10
Switches and Default Settings
. . . . . .
2-18
2.4.11
positive and Negative Forms of Switches
2-20
Abbreviations
2.4.12
2-20
2.5
SPECIAL FEATURES .
2-20
2.5.1
Indirect Files .
. . . . . . . . . . .
2-20
2.5.2
Option File
. . . . . . . . . . . . . . . . .
2-20
CHAPTER 3
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.4.1
3.2.4.2
3.2.4.3
3.2.4.4
3.3
3.3.1
3.3.2
3.3.3
3.4
3.5
CHAPTER 4
4.1

COMPILER OUTPUT
TERMINAL OUTPUT
· . . . . . 3-2
OUTPUT LISTING .
· 3-3
Listing Header .
· . . . . . 3-4
Source Listing .
. . . 3-5
Object Listing
· 3-7
Source Part Options
· . . .
3-10
Default Source Listing
3-11
Listing with LIBRARY/REQUIRE Information . . 3-11
Listing with Macro Expansions
... .
3-11
Listing with Macro Tracing .
. .. .
3-11
CROSS-REFERENCE LISTING
. . . .
3-16
Cross-Reference Header . . .
· . . . . 3-16
Cross-Reference Entries
. . . .
3-16
Output Listing with Cross-Reference Listing
3-20
COMPILATION SUMMARY
. . . . .
3-22
ERROR MESSAGES . . . . . . . . . . . . . . . . .
3-22
LINKING, EXECUTING, AND DEBUGGING
LINKING

. . . . . . . . 4-1
iv

CONTENTS
4.1.1
4.1.2
4.1.3
4.2
4.3
4.3.1
4.3.2
CHAPTER 5
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
5.21
5.22
5.23
5.24
5.25
5.26
5.27
5.28
5.29
5.30
5.31
5.32
5.33
5.34
5.35
5.36
5.37
5.38
CHAPTER 6
6.1
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
6.2.7

Syntax . • .
Defaults . . •
Semantics
EXECUTING
DEBUGGING
Debug Example
Other SIX12 Commands .

..
.•
·
·
·

4-2
4-2
4-3
4-3
4-3
4-3
4-4

MACHINE-SPECIFIC FUNCTIONS
GENERAL CONVENTIONS
5-1
Machine Code Insertion Functions
• 5-1
Logical Functions
5-3
Arithmetic Functions
5-3
System Interface Functions
5-3
ADDD (ADD DOUBLE OPERANDS)
5-3
ADDF (ADD FLOATING OPERANDS)
5-4
ADDG (ADD FLOAT-G OPERANDS)
5-4
ASH (ARITHMETIC SHIFT)
5-5
CMPD (COMPARE DOUBLE OPERANDS)
5-5
CMPF (COMPARE FLOATING OPERANDS)
5-5
CMPG (COMPARE FLOAT-G OPERANDS)
5-6
COPYII, COPYIN, COPYNI, AND COPYNN (COpy A BYTE)
5-6
CVTDF (CONVERT DOUBLE TO FLOATING)
5-6
CVTDI (CONVERT DOUBLE TO INTEGER)
5-7
CVTFD (CONVERT FLOATING TO DOUBLE)
5-7
CVTFG (CONVERT FLOATING TO FLOAT-G)
5-7
CVTFI (CONVERT FLOATING TO INTEGER)
5-8
CVTGF (CONVERT FLOAT-G TO FLOATING)
5-8
CVTGI (CONVERT FLOAT-G TO INTEGER)
5-8
CVTID (CONVERT INTEGER TO DOUBLE)
5-9
CVTIF (CONVERT INTEGER TO FLOATING)
5-9
CVTIG (CONVERT INTEGER TO FLOAT-G)
5-9
DIVD (DIVIDE DOUBLE OPERANDS)
5-10
DIVF (DIVIDE FLOATING OPERANDS)
5-10
DIVG (DIVIDE FLOAT-G OPERANDS)
5-10
FIRSTONE (FIND FIRST BIT)
• '.
5-11
INCP (INCREMENT A BYTE POINTER)
5-11
JSYS (INVOKE A TOPS-20 SYSTEM SERVICE)
5-11
LSH (LOGICAL SHIFT)
5-13
MACHOP AND MACHSKIP (EMIT AN INSTRUCTION)
5-13
MULD (MULTIPLY DOUBLE OPERANDS)
5-14
MULF (MULTIPLY FLOATING OPERANDS)
5-14
MULG (MULTIPLY FLOAT-G OPERANDS)
5-14
POINT (BUILD A BYTE POINTER)
5-15
REPLACEI AND REPLACEN (STORE A BYTE)
5-15
ROT (ROTATE A VALUE)
5-15
SCANN AND SCANI (FETCH A BYTE)
5-16
SUBD (SUBTRACT DOUBLE OPERANDS)
5-16
SUBF (SUBTRACT FLOATING OPERANDS)
5-16
SUBG (SUBTRACT FLOAT-G OPERANDS)
5-17
UUO (INVOKE A TOPS-I0 SYSTEM SERVICE)
5-17
PROGRAMMING CONSIDERATIONS
LIBRARY AND REQUIRE USAGE DIFFERENCES
FREQUENT BLISS CODING ERRORS
Missing Dots
Valued and Nonvalued Routines
Semicolons and Values of Blocks
Complex Expressions Using AND, OR, and NOT
Computed Routine Calls
Signed and Unsigned Fields
Complex Macros
v

6-1
6-2
6-3
6-3
6-3
6-4
6-4
6-4
6-5

CONTENTS
Missing Code . . . . . . .
6.2.8
6.2.9
Conflicting Names
. . .
Routines Within Routines . .
6.2.10
Indexed Loop Coding Error
. . . . . . . .
6.2.11
ADVANCED USE OF BLISS MACROS . . . . .
6.3
6.3.1
Advantageous Use of Machine Dependencies .
6.3.2
Dealing with Enumeration Types
6.3.2.1
The SET Data-Type
. . .
6.3.2.2
Creating a Set . .
. . . . . .
6.3.2.3
Placing Elements in Sets . .
....
6.3.2.4
Membership in a Set
. . . . .
6.4
EXTENDED ADDRESSING DIFFERENCES
. . .
CHAPTER 7

. . . 6-S
. . . 6-6
. 6-6
. . . 6-7
. 6-7
. . . 6-8
. 6-9
. . • 6-9
. . 6-10
6-11
6-12
. . 6-13

TRANSPORTABILITY GUIDELINES

INTRODUCTION . . .
7.1
· . . 7-1
7.2
GENERAL STRATEGIES . .
· . . 7-2
7.2.1
Isolation
7-2
Simplicity
7.2.2
· 7-3
7.3
TOOLS
· 7-3
Li terals .
. . . . . . . . . . . . . . · 7-3
7.3.1
7.3.1.1
Predeclared Literals
....... .
· 7-4
7.3.1.2
User-Defined Literals
· . 7-4
7.3.2
Macros and Conditional Compilation .
7-S
7.3.3
Module SWitches
....
· 7-6
7.3.4
Reserved Names . . . . . . .
· . 7-8
7.3. S
Require and Library Files
· . 7-8
7.3.6
Routines
· . . 7-9
7.4
TECHNIQUES . . . . .
7-10
Data . . . . . . . . . . . .
7.4.1
7-10
7.4.1.1
Problem Origin . .
. . . . . 7-11
7.4.1.2
Transportable Declarations .
7-11
7.4.1.3
Length of Externally Used Names
7-13
7.4.2
Data: Addresses and Address Calculations .
7-13
7.4.2.1
Addresses and Address Calculations . .
7-13
7.4.2.2
Relational Operators and Control Expressions 7-1S
7.4.2.3
BLISS-10 Addresses Versus BLISS-36 Addresses 7-1S
7.4.3
Data: Character Sequences
. . . . .
7-16
7.4.3.1
Usage as Numeric Values
7-16
7.4.3.2
Usage as Character Strings
7-17
7.4.4
PLITs and Initialization
7-17
7.4.4.1
PLITs in General . . . . .
7-18
7.4.4.2
Scalar PLIT Items
. . . . . .
. . . . 7-18
7.4.4.3
String Literal PLIT Items
7-18
7.4.4.4
An Example of Initialization .
7-20
7.4.4.S
Initializing Packed Data . . .
7-23
7.4.S
Structures and Field Selectors .
7-27
7.4.S.1
Structures .
7-27
7.4.S.2
FLEX VECTOR
7-28
7.4.S.3
Field Selectors
7-30
7.4.S.4
GEN VECTOR
7-31
7.4.S.S
Summary
7-33
CHAPTER 8

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES

8.1
COMPILER PHASES
8.1.1
Lexical and Syntactic Analysis .
8.1.2
Flow Analysis
. . . . . . . . .
8.1.2.1
Knowing When a Value Changes .
8.1.2.2
Accounting for Changes .
8.1.3
Heuristics . . . . . . . . . . . . .
Temporary Name Binding . . .
. .
8.1.4
8.1.S
Code Generation
8.1.6
Code Stream Optimization .
vi

8-1
· . 8-1
· . . 8-2
8-3
· . . 8-4
8-6
. · . . 8-6
· . . 8-7
8-7

CONTENTS
8.1.7
8.2
CHAPTER 9

Output File Production . .
SUMMARY OF SWITCH EFFECTS

. 8-8
. 8-8

TOOLS, LIBRARIES, AND SYSTEM INTERFACES

9.1
TRANSPORTABLE PROGRAMMING TOOLS (XPORT)
9-1
XPORT Data Structures
. . . . .
. 9-2
9.1.1
XPORT Input/Output . . . . . . . .
. . . . . 9-2
9.1.2
XPORT Dynamic Memory Management
. . . . . . . . 9-3
9.1.3
XPORT Host System Services . . .
. 9-3
9.1.4
XPORT String Handling Facilities .
. . . . . 9-3
9.1.5
9.2
BCREF - BLISS MASTER CROSS REFERENCE PROGRAM .
9-4
Command-Line Format
.. . . . . .
. . 9-4
9.2.1
Command Semantics
. . . . . . . . .
. 9-5
9.2.2
Building a Master Cross Reference
. 9-5
9.2.3
Command Switches . . . . . . . . .
9-5
9.2.4
9.3
CVTI0 - BLISS-I0 TO BLISS-36 CONVERSION PROGRAM . 9-6
9.3.1
CVTI0 Command-Line Syntax
9-6
BLISS-I0 Translations
. . . . .
. 9-7
9.3.2
Normal Declarations
. . . . . . 9-8
9.3.2.1
9.3.2.2
REQUIRE Declarations .
. . . . . 9-8
SWITCHES Declarations
. . ..
9-8
9.3.2.3
9.3.2.4
BIND Declarations
. . 9-8
ROUTINE Declarations .
. . . . . . . . . . 9-9
9.3.2.5
SELECT Expressions .
. . . . . . . . . . 9-9
9.3.2.6
CASE Expressions . .
. . . . . . . . 9-9
9.3.2.7
MACROs . . . . . . .
. . 9-9
9.3.2.8
TUTIO - TUTORIAL TERMINAL INPUT/OUTPUT PACKAGE. 9-10
9.4
SYSTEM INTERFACES
. . . . . . . . . . . . . . . 9-10
9.5
Precompiled Declaration Libraries
. . . .
9-10
9.5.1
9.5.2
TENDEF.L36 Library . . .
. . . . 9-11
POINTR Macro . . . . . . . . . . . . . . . . 9-11
9.5.2.1
FLD Macro
. . . . . . . . . . . .
9-12
9.5.2.2
9.5.2.3
MONWORD and MONBLOCK Structures
9-12
Other Symbols
. . . .
. . . . 9-12
9.5.2.4
9.5.3
UUOSYM.L36 Library . . .
. . . . . 9-13
MONSYM.L36 Library . .
. . . . .
9-13
9.5.4
Generation Procedure . . . . . .
. . . . 9-14
9.5.5
9.5.6
TOPS-I0 System Interface Example
. . . . . 9-14
TOPS-20 System Interface Example
9-17
9.5.7
CHAPTER 10

BLISS-36 CODING EXAMPLES

EXAMPLE 1: THE PSINT
10.1
Module PSINT . . .
10.1.1
Routine REPLAY . .
10.1.2
10.1.3
Routine DISPLAY
Routine ENAPSI .
10.1.4
Routine TTYSET
10.1.5
Routine FILIO
10.1.6
Routine TTYRES
10.1.7
Routine DISPSI
10.1.8
Routine CTRLC
. .
10.1.9
Rout i ne CTRLY
10.1.10
Routine DSPHDL .
10.1.11
Routine PSIHDL . .
10.1.12
EXAMPLE 2: THE TRANS
10.2
Module TRANS . . .
10.2.1
Routine TRANSMAIN
10.2.2
Routine CMDINIT .
10.2.3
Routine LEXGET . .
10.2.4
Routine OPENFILES
10.2.5
Routine BUILDTBL .
10.2.6
Routine EXTBL
10.2.7
vii

PROGRAM
.
. . . .
. . .
.
.
. . . .

.
.
.
.
.
.

..
.
. . .
. . .
.

. . . .
.....
. . . .
. .

. .

. . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . .
. . . . . .
. . . . .
PROGRAM . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . .
. . . .
. . . . . . . .
.
. . . . . .
.
. . . . . . . . . . . . . .
. . ..
..
. . . ..
.....

10-1
10-2
10-4
10-4
10-4
10-5
10-6
10-7
10-8
10-8
10-9
10-9
10-9
10-10
10-11
10-16
10-17
10-18
10-21
10-22
10-23

CONTENTS
10.2.8
10.2.9
APPENDIX A
A.l
A.2
A.3
A.4

Routine CHRVAL .
Routine FILIO

· 10-25
· 10-26

SUMMARY OF COMMAND SYNTAX
TOPS-20
TOPS-20
TOPS-IO
TOPS-IO

COMMAND SUMMARY
SWITCH DEFAULTS
COMMAND SUMMARY
SWITCH DEFAULTS

APPENDIX B

SUMMARY OF FORMATTING RULES

APPENDIX C

MODULE TEMPLATE

C.l
C.2
C.3
C.4
APPENDIX D
D.l
D.2
APPENDIX E
E.l

...........
.........
· .
· .....

A-I
A-2
A-3
A-5

· .
· .....
·
·

C-l
C-2
C-3
C-3

MODULE PREFACE . . . . . . .
DECLARATIVE PART OF MODULE .
EXECUTABLE PART OF MODULE
CLOSING FORMAT . . . . . . .
IMPLEMENTATION LIMITS
BLISS-36 LANGUAGE
SYSTEM INTERFACES

· D-l
· D-l

ERROR MESSAGES
BLISS COMPILER FATAL ERRORS

E-36

APPENDIX F

SAMPLE OUTPUT LISTING

APPENDIX G

MIXING BLISS-36 MODULES AND BLISS-IO MODULES

APPENDIX H

USER-GENERATED OTS FILES

FIGURES
3-1
3-2
3-3
3-4
3-5
3-6
3-7
3-8

Compiler Output Listing Sequence . . . . . . . . . 3-3
Listing Header Format
. . . . .
· . . . . . 3-4
Default Object Listing Example .
· 3-9
Default Source Listing Example . . . . . .
3-12
Output Listing with Library and Require File Data 3-13
Output Listing with Macro Expansion Data . .
3-14
Output Listing with Macro Expansion and Tracing
Data . . . . . . . . . . . . . . . . . . . .
3-15
Output Listing with Cross-Reference Listing
Included . .
3-21
Error Messages in Source Listing Example .
3-25
Sample Output Listing
. . . . . . . . . . . . . . F-2
II>

3-9
F-l

•

TABLES
1-1
2-1
3-1

Command Line, Module Switch, and SWITCH Names on
TOPS-20
. . . . . . . . ..
. . . . . . . . 1-21
Command Line, Module Switch, and SWITCH names on
TOPS-10
. . . . . .
. . . . .
2-19
Format of Preface String in Source Listing . . . . 3-6
viii

CONTENTS
3-2
5-1
9-1
10-1

Symbol Type Abbreviations
3-17
Machine-Specific Functions .
. . . . . . . 5-2
BLISS-1 a Language Features . . . . .
. . 9-7
Depiction of the Command State Table . . . . . . 10-13

PREFACE

MANUAL OBJECTIVES
This manual is a user's guide for the BLISS-36 compiler, which runs on
TOPS-IO and TOPS-20 operating systems.
It provides three kinds of
information: basic operating instructions,
advanced material,
and
reference information.
This manual is' intended as a companion manual
to the BLISS Language Guide. As such, they have certain structural
similarities,
and the discussions of organization and syntax notation
given in the language guide apply to this manual.

INTENDED AUDIENCE
This guide is intended for users of the BLISS-36 programming language.
It presupposes some familiarity with the TOPS-IO or TOPS-20 operating
system, its command language, and file-system conventions.

STRUCTURE OF THIS DOCUMENT
Chapters 1 through 4 describe basic operating instructions:
•

Chapters 1 and 2 present procedures for compiling a BLISS
program,
define file specifications,
and describe command
switches that can be used in the TOPS-20 and TOPS-IO operating
system environments.

•

Chapter 3 considers output produced by the compilation.
The
format and meaning of each crf the possible compiler outputs
are described and illustrated.

•

Chapter 4 is concerned with linking, executing, and debugging.

Chapters 5 through 10 supply advanced material:
•

Chapter 5 describes machine-specific functions.

•

Chapter 6 describes programming considerations,
use of LIBRARY and REQUIRE facilities.

•

Chapter 7 gives guidelines
programs.

•

Chapter 8 presents a discussion of the compiler architecture
and provides insight into the effects that result from command
switches related to optimization.

for

writing

such

transportable

the
BLISS

•

Chapter 9 describes some tools related to BLISS programming.

•

Chapter 10 provides coding examples in the
and annotated programs.

form

complete

including

command

The appendices contain reference information:
•

Appendix A summarizes command line syntax,
switches and their default settings.

•

Appendix B summarizes formatting rules suggested for your use.

•

Appendix C provides a model
current implementation limits.

•

Appendix E contains error messages generated by the compiler.

•

Appendix F illustrates a sample output listing.

•

Appendix G describes methods for interfacing with BLISS-IO.

•

Appendix H describes the use of user-generated OTS files.

template.

Appendix

lists

RELATED MANUALS
BLISS Language Guide (AA-H275C-TK)
This manual completely describes the BLISS-16,
BLISS-32,
and
BLISS-36 languages.
It can be used both as a learning tool for
the languages and as a reference guide.
BLISS Language Guide Update Package (AD-H275C-Tl)
The update package provides Version 4.0
Guide.

the

BLISS

Language

BLISS Primer (order from Educational Services)
The BLISS Primer is a guide to a
self-paced BLISS learning
course.
The language features are described and exemplified.
Each section is followed by a quiz and suggested solutions.
This
document is strongly recommended for the BLISS novice.
BLISS Pocket Guide (AV-AT45A-TK)
This guide presents a concise syntax summary for the family of
BLISS languages.
A summary of the command line syntax for the
respective compilers is also provided.
XPORT Programmer's Guide (AA-J20lA-TK)
The guide is a tutorial and reference manual for the XPORT
transportable-programming tools package.
XPORT is a collection
of
source-level
tools
that
provide
input/output
and
operating-system services for BLISS-32 and BLISS-36.

xii

PREFACE

SYNTAX NOTATION
Syntax notation used for defining BLISS-36 is explained thoroughly in
Chapter 2 of the BLISS Language Guide. The following is a summary of
the syntax notation used in this manual:
item-l

item-2 I item-3 } Select exactly one of the items separated
by vertical bars within the braces.

~ item-l
item-2
item-3

Select
braces
lines.

item ...

The item directly preceding the " ... " can
be replicated zero or more times.

item , ...

The item directly preceding the
, ...
can be replicated zero or more times,
with the items separated by commas.

item+ ...

The item directly preceding the
"+ ... "
can be replicated zero or more times,
with the items separated by plus signs.

exactly one of the
on
separate
but

In addition, the red portions of a syntax line or
identify information keyed in by the user.

xiii

items
in
contiguous

system-user

dialog

SUMMARY OF TECHNICAL CHANGES

This manual provides BLISS-36 user information for Version 4.0 of the
BLISS-36
compiler.
This section summarizes technical changes,
additions, and deletions to the guide since Version 3.0.
•

/CHECK,
/CROSS-REFERENCE
(DECsystem-20),
and
/CREF
(DECsystem-lO) switches have been added as general-qualifiers
to the BLISS-36 command lines.

•

/MASTER-CROSS-REFERENCE has been added as an output-qualifier
to the BLISS-36 compiler for both TOPS-IO and TOPS-20.

•

An extended addressing capability has been added to the
BLISS-36
compiler
for
TOPS-20 along with an extended
addressing SECTION-INDEPENDENT option.

•

A new cross-reference capability (BCREF)
replace BLSCRF.

•

Additions have been made to the Programming Considerations
chapter (6), which include the use of BUILTIN PC, indexed loop
coding errors, the advanced use of BLISS macros, and extended
addressing coding differences.

•

Changes and additions have been made to the compiler listing
formats to update the examples and provide an example of
cross-reference listings.

•

An Examples chapter (10)
additional coding examples.

has

been

has

been

included

added

provide

CHAPTER 1
TOPS-20 OPERATING PROCEDURES

This chapter discusses the TOPS-20 operating procedures used to
compile a BLISS program.
Compilation, including command-line syntax
and semantics, is considered first.
Next,
file specifications for
input to a BLISS-36 compilation are described and illustrated.
Finally, the command-line switches relevant to a BLISS-36 compilation
are given.
Compiling,
linking,
and executing
a
BLISS-36
program
is
a
straightforward procedure.
In the simplest case,
to compile and
execute a program that consists of a single module,
you enter the
module in a
file
(for example,
ALPHA.B36),
compile it with the
BLISS-·36 compiler, link it using LINK, and then execute the linked
image.
The EXECUTE command automatically invokes LINK as follows:
@BLISS
BLISS>ALPHA
BLISS>/EXIT
@EXECUTE ALPHA
The first command invokes the BLISS compiler to compile the module in
the file ALPHA.B36 and to produce an object file ALPHA.REL.
The
second command uses the object module in the file ALPHA.REL to produce
an executable image in memory and to execute the image.
To save the linked image,
resulting image as follows:

invoke

LINK

explicitly

and

save

the

@BLISS
BLISS>ALPHA/EXIT
@LOAD ALPHA
@SAVE ALPHA
You can control the compiler by using command-line switches.
These
switches add a
level of complexity to the compilation process, but
they also provide a significant number of options by which you can
vary the performance of the compiler in the production of output, the
formatting of listings,
and the degree of optimization to
be
performed.

1.1

COMPILING A BLISS PROGRAM

The BLISS compiler uses the standard TOPS-20 command interpreter,
the
COMND% JSYS, to parse the command line.
As such, various features of
command line processing that are common to many programs and EXEC
commands on TOPS-20 are also common to the BLISS compiler.
Some of
these include command recognition,
file specification completion,
editing characters, and the question mark character (?).
Refer to the
TOPS-20 Userls Guide for a description of these facilities.

1-1

TOPS-20 OPERATING PROCEDURES
To compile a BLISS program,
you run the BLISS compiler from the
command level and wait for the 'BLISS>' prompt.
(The simplest way to
run the BLISS compiler is to have the compiler, BLISS.EXE,
reside on
logical device SYS:i
for the rest of this chapter, the compiler is
assumed to be invoked by typing 'BLISS ' at the command level.)
Input
specs and global switches, if supplied, are then supplied.
Global switches apply to all input specs and precede them in the
command line.
They override default switch settings.
Input-specs
consist of one or more file names followed by switch settings that
apply to an individual file or concatenated file.
Switch settings in
an input-spec override global switch settings.
•

To compile a program, use the following command:
BLISS>MYPROG
The BLISS compiler uses the file MYPROG.B36 or MYPROG.BLI as
its input,
compiles the source in that file, and produces
object file MYPROG.REL.

•

To produce a listing file,

use the output switch /LISTING:

BLISS>MYPROG/LISTING
In addition to the object file, the
the listing file MYPROG.LST.
•

BLISS

compiler

produces

To compile more than one module, include a list of input files
separated by commas, as follows:
BLISS>ALPHA,BETA,GAMMA

•

The compiler compiles ALPHA.B36,
producing the object
ALPHA.RELi
then
BETA.B36,
producing BETA.RELi
and
GAMMA.B36, producing GAMMA.REL.

file
then

To compile a program that consists of several pieces, each
a separate file, use the concatenation indicator (+):

BLISS>ALPHA+BETA+GAMMA
The BLISS compiler compiles the program formed by
concatenation of ALPHA.B36,
BETA.B36,
and GAMMA.B36,
produces the single object file ALPHA.REL.
•

the
and

To perform a multifile compilation in which one command-line
switch is common to all source files in an input-spec, include
the appropriate switch before the input-spec:
BLISS>/LIBRARY ALPHA,BETA,GAMMA/NOLIBRARY,DELTA
The command line consists of four input-specs, which must be
separated by commas.
Placing the /LIBRARY switch before the
first input-spec has the effect of overriding the default
switch settings of /NOLIBRARY and /OBJECT for all input-specs,
unless it, in turn, is superseded by a
switch setting that
applies to an individual input-spec.
A switch setting that
follows an input-spec applies only to that input-spec.
Thus,
the command line above causes the compiler to produce three
library files and one object file:
ALPHA.L36,
BETA.L36,
DELTA.L36, and GAMMA.REL.

1-2

TOPS-20 OPERATING PROCEDURES
•

To produce an object file with a name different from that of
the source file,
specify the new object file name in the
command
BLISS>ALPHA/OBJECT:GAMMA
The BLISS compiler produces the object file GAMMA.REL.

•

To produce a library file instead of an object file,
/LIBRARY command switch:

use

the

ALPHA.R36

and

BLISS>ALPHA/LIBRARY
The BLISS compiler compiles the input
produces the library file ALPHA.L36.

file

NOTE
The TOPS-20 EXEC does not support BLISS-36 in
LOAD-class commands. Therefore, the following
commands will not compile ALPHA as a BLISS-36
module.
However,
they will attempt to use
BLISS-IO to compile ALPHA.BLI.
@EXECUTE ALPHA.BLI
@LOAD ALPHA.BLI

1.1.1

Command-Line Syntax
bliss-compilation
bliss-commandline

space

switch

input-spec

file-spec+ ...

space

blank

switch

1.1.2

BLISS>bliss-command-line
input-spec

•••

switch ... }

output-switch
general-switch
check-switch
terminal-switch
optimization-switch
listing-switch
reference-switch
environment-switch

Command-Line Semantics

The BLISS-36 compiler uses switches given in the bliss-command-line to
modify
the
initial defaults for each compilation.
Then,
the
concatenated input is compiled in the context of the initial defaults.
The switches and the initial default for each switch are described in
Section 1.3.
Unless a switch to change the compiler's behavior is given, the output
from a compilation initiated from your terminal or batch file is the
object file; no listing is generated.

1-3

TOPS-20 OPERATING PROCEDURES
The compiler begins processing with the first file given and continues
until an end-of-file is reached.
It continues to read input until all
files specified in the input-spec have been read.
Command-line switches can appear in two places in a command line:
before the first input-spec, and after individual input-specs.
Those
appearing before the first input-spec have a global application to all
input-specs in the command line.
For example:
BLISS>/LIBRARY ALPHA,BETA+ETA+THETA,OMEGA
Those appearing at the
input-spec they follow.

end of an input-spec
For example:

apply

only

the

BLISS>/LIBRARY ALPHA,BETA/LIST,IOTA
If no command-line switches exist in a command line,
default switch
settings are assumed for all input-specs in the command line.
All
switches have an assigned default setting or value.
The only required space in the command line separates
input-spec from preceding global command-line switches.

1.2

the

first

FILE SPECIFICATIONS

File specifications are used to name the source of program text to be
compiled and the destination of output from the compilation.
More
precisely, file specifications can occur in four contexts:
•

In the input-specs of a bliss-command-line

•

As the values of the switches /OBJECT, /LIBRARY, /LISTING,
/MASTER-CROSS-REFERENCE

•

In REQUIRE
compiled

•

In the object-time system (OTS)
style file specs only)

LIBRARY

declarations
module

the

switch

module

being

(for

TOPS-IO

The file-spec is a standard TOPS-20 file specification,
as described
in the DECSYSTEM-20 User's Guide, and is interpreted as follows:
1.

Logical name translation occurs.

If a file type is not given, a default file type is used (see
below) .

If the file-spec applies to an output file and a file name is
not given, the name of the first input file in the input-spec
is used.

This same interpretation is also
processes the file specification
declaration.

used by the compiler when it
given in a REQUIRE or LIBRARY

The file-spec must be fully specified in the OTS module switch.
is, no defaults are applied by the compiler.

1-4

That

TOPS-20 OPERATING PROCEDURES
The compiler has two ordered lists of default file types to be tried
for an input-spec that does not include a file type. The list the
compiler applies depends on the output specified for the compilation,
as indicated in the following list:
Input-Spec Used to Produce

Default Type List

An object module

.B36,

.BLI

A library file

. R3 6 ,

. REQ ,

. B36

•

BL I

If the program being compiled contains a REQUIRE
or
LIBRARY
declaration,
the compiler uses the following list to search for the
appropriate file type according to the type of declaration:
File Use

Default Type List

File given in a
REQUIRE declaration

.R36,

File given in a
LIBRARY declaration

.L36

For example, suppose you have entered the
file ALPHA.BLI:

.REQ,

following

.B36,

.BLI

program

the

MODULE MYTEST
BEGIN
REQUIRE 'CBLISS ' :
LIBRARY 'TBLISS':
END
ELUDOM
and you use the following command line to compile it:
BLISS>ALPHA
Since the bliss-command-line contains no switch requesting that a
library file be produced, the output of the compilation is an object
module. Therefore, the compiler chooses the list of default types
associated with object module output and searches first for ALPHA.B36,
then, not finding that file,
for ALPHA.BLI,
which it finds and
compiles.
In processing the module MYTEST in that file, the compiler
encounters the REQUIRE declaration for the file CBLISS.
Since no file
type for CBLISS is given, the compiler uses the list of default types
for files in a REQUIRE declaration and searches for CBLISS.R36,
then
CBLISS.REQ,
then CBLISS.B36,
and finally CBLISS.BLI.
When the
compiler processes the LIBRARY declaration, it uses the default type
list associated with library declarations and searches for TBLISS.L36.

1.3

COMMAND-LINE SWITCHES

Command-line
compilation.

switches provide control over many aspects of the
Valid command-line switches and their functions are:

•

Output switch -- defines the types of output to be produced

•

General switch -- sets a %VARIANT value and specifies code and
debug information

1-5

TOPS-20 OPERATING PROCEDURES
•

Check switch -- controls the level of semantic
during compilation.

checking

done

•

Terminal switch -- controls output produced on a terminal

•

Optimization switch -- supplies code
and directions

optimization

strategies

•

Listing switch
provides
output
concerning the source and machine code

listing

information

•

Reference switch -- includes cross-reference information
output listing and/or a master cross-reference data file

•

Environment switch
identifies the processor
target operating system of the generated code

and

model

Output Switches

1.3.1

Output switches are used to indicate the type of output to be produced
from a BLISS-36 compilation and to give names for the files to be
produced when you do not want to use the default names.
Some examples
of output switches are given in the following list:

•

To suppress the production of an object file,
use
/NOOBJECT switch in the bliss-compilation, as follows:

the

BLISS>ALPHA/NOOBJECT
The BLISS-36 compiler reads the source in the file ALPHA.B36
and produces no output files.
The only outputs are the error
messages and summary information produced at the terminal.
•

To obtain a list file
for a
/LISTING switch, as follows:

single

source

file,

use

the

BLISS>ALPHA/LISTING
The BLISS-36 compiler produces an object file ALPHA.REL and
list file ALPHA.LST.
However, to obtain list files in a multifile compilation,
the /LISTING switch before the input-specs, as follows:

a
use

BLISS>/LISTING ZETA,ETA,THETA
The BLISS-36 compiler generates both object and list files for
each input file.
•

To use a different name for the object or list files,
following switches:

use

the

The compiler reads the input file ALPHA.B36, and produces
object file BETA.REL and the list file GAMMA. LST.

the

To produce
following:

the

BLISS>ALPHA/OBJECT:BETA/LISTING:GAMMA

•

master

cross-reference

data

BLISS>ALPHA/MASTER-CROSS-REFERENCE:MASTER

1-6

file,

use

TOPS-20 OPERATING PROCEDURES
The compiler reads the input file ALPHA.B36, and produces the
object
file
ALPHA.REL
and master cross-reference file
MASTER.CRF.
•

To produce a library file rather than an object file, use
/LIBRARY switch, as follows:

the

BLISS>ALPHA/LIBRARY
The compiler reads the input file ALPHA.B36 and
library file ALPHA.L36.

1.3.1.1

produces

the

Syntax - Output-switch syntax is:

outputswitch

/OBJECT {: file-spec}
/LISTING {:file-spec}
{ /LIBRARY {:file-spec}
/MASTER-CROSS-REFERENCE {:file-spec}

I /NOOBJECT
}
I /NOLISTING
I /NOLIBRARY
I /NOMASTER-CROSS-REFERENCE

The compiler can produce either a library or an object file,
but not
both.
Therefore,
the switches /OBJECT and /LIBRARY must not be
applied to the same input-spec.

1.3.1.2 Defaults - In the absence of an
switch, the following are assumed:
/OBJECT

/NOLISTING

/NOLIBRARY

explicit

choice

output

/NOMASTER-CROSS-REFERENCE

If a file-spec is not given, the file name of the first
file-spec
in
the input-spec is combined with the default file type to form the
file-spec.
If a file-spec is given but the file-spec does not include
a
file type,
the following defaults are supplied, according to the
file-designator:
File-Designator

Default Type

/OBJECT

.REL

/LISTING

.LST

/LIBRARY

.L36

/MASTER-CROSS-REFERENCE

.CRF

1.3.1.3 Semantics - Output
interpretation:

switches

have

the

following

/OBJECT:file-spec

Produce an object file in the file
specified by file-spec.

/OBJECT

Produce an object file in the file
by
specified
'input-file-name.REL' .

/NOOBJECT

Do not produce an object file.

/LISTING:file-spec

Produce a list file
in
specified by file-spec.

1-7

the

file

TOPS-20

OPERATI~G

PROCEDURES

Produce a list file
specified

/LISTING

file
by

the

'input-file~name.LST' .

/NOLISTING

Do not produce a list file.

/LIBRARY:file-spec

Produce a library file in the file
specified by file-spec.

/LIBRARY

Produce a library file in the file
specified
by
'input-file-name.L36, .

/NOLIBRARY

Do not produce a library file.

/MASTER-CROSS-REFERENCE:file-spec

Produce a master cross-reference
file in the file specified by
file-spec.

/MASTER-CROSS-REFERENCE

Produce a master cross-reference
file in the file specified by
'input-file-name.CRF' .

/NOMASTER-CROSS-REFERENCE

Do
not
produce
cross-reference file.

1.3.2

master

General Switches

General switches are used to specify code and debug information and to
set the value for the lexical function %VARIANT.
Some examples of
using general switches follow:
•

To include the necessary debug linkage in the compiled
program, use the /DEBUG switch in the bliss-compilation:
BLISS>ALPHA/DEBUG
The compiler reads the source from ALPHA.BLI and creates an
object file ALPHA.REL,
which includes additional code for
interface with SIX12.

•

To syntax-check a program that you do not intend to execute,
use the /NOCODE switch to save compilation time, as follows:
BLISS>ALPHA/NOCODE

•

To set the value of the lexical function %VARIANT to
the /VARIANT switch as follows:

17,

use

the

BLISS>ALPHA/VARIANT:17
•

To limit the number of errors
/ERROR-LIMIT switch as follows:
BLISS>ALPHA/ERROR-LIMIT:IO

1-8

diagnosed

la,

TOPS-20 OPERATING PROCEDURES
1.3.2.1

Syntax - General-switch syntax is:
/DEBUG
I
/CODE
I
/VARIANT { :
/ERROR-LIMIT
/EXIT

general-switch

1.3.2.2 Defaults - In the absence of
switches, the following are assumed:
/NODEBUG

/CODE

/VARIANT:O

/NODEBUG
/NOCODE
value }
{ : value

explicit

choices

general

/ERROR-LIMIT:30

The compiler produces code, does not include the additional debugging
information in the object file, and sets the value of %VARIANT to O.
If the general switch /VARIANT is given without a specified
value of 1 is assumed.

value,

If the /ERROR-LIMIT is given without a specified value, a value
is assumed.

1.3.2.3 Semantics - The interpretation of
given in the following list:

the

command

switches

/DEBUG

Generate debugging linkage and do not do certain
optimization so that a user may effectively use
SIX12. Also, include symbolic information in the
object file produced,
and maintain the frame
pointer (FP) in routine prologs and epilogs.

/NODEBUG

Produce symbolic information but no debug linkage,
and do not limit optimizations for effective use
of SIX12.

/CODE

Generate object code for the BLISS source module.

/NOCODE

Perform only a syntax check of the program.

/VARIANT

Set %VARIANT to 1.

/VARIANT:n

Set %VARIANT to n, where n is a decimal integer in
the range:
-(2**35) < n < (2**35)-1

/EXIT

Terminate the compiler operation and
returns
control to the system.
/EXIT can appear in a
command line or on a separate line.

/ERROR-LIMIT

Set error limit to 1.

/ERROR-LIMIT: n

Limit to n the number of errors
terminating compilation.

1-9

diagnosed

before

TOPS-20 OPERATING PROCEDURES
1.3.3

Check Switch

The check switch controls the level of semantic checking done during
compilation.
The switch allows all legal BLISS syntax to be examined
for semantic irregularities.
Some examples of the use of the check
switch are as follows:
•

To suppress field-name checking on structure accesses if the
data-segment declaration has no field-attribute, use the check
switch as follows:
BLISS>ALPHA/CHECK:NOFIELD

•

To check for the use of uninitialized storage, use
switch as follows:

the

check

1.3.3.2 Defaults - In
the
absence
of
specific
choices
check-values, the following values are assumed by default:

BLISS>ALPHA/CHECK:INITIAL

1.3.3.1

Syntax - Check switch syntax is defined as follows:

check switch
check-value

FIELD

INITIAL

{

{check-value ,
check-value

( FIELD
, INITIAL
) OPTIMIZE
( REDECLARE

NOFIELD
NOINITIAL
NOOPTIMIZE
NOREDECLARE

/CHECK:

OPTIMIZE

...

NOREDECLARE

1.3.3.3 Semantics - The /CHECK switch indicates that one or more
check-values follow.
The check-values have the following meanings:
Check-Value

Meaning

FIELD

Do not suppress field-name checking.

NOFIELD

If
the
data-segment
declaration
has
no
field-attribute,
suppress field-name checking on
the structure accesses.

INITIAL

Check for the use of uninitialized storage.

NOINITIAL

Do not check for uninitialized storage.

OPTIMIZE

Check for suspicious optimizations.
For example,
constant folding expressions of a form that is
always false, such as:
.X<0,8,1> EQL %X'FF'

1-10

TOPS-20 OPERATING PROCEDURES
NOOPTIMIZE

Do not check for suspicious optimizations.

REDECLARE

Check for the redeclaration of a
nested scope.

NOREDECLARE

Do not check for the redeclaration of a name.

1.3.4

name

within

Terminal Switches

Terminal switches are used to control the output that is sent to the
terminal.
You can have errors or statistics printed or suppressed on
the terminal during the compilation of a BLISS program.
Some examples
of using the terminal switches are as follows:
•

To see the statistics for each routine as they are produced
during
the compilation,
use the /STATISTICS switch,
as
follows:
BLISS>ALPHA/STATISTICS

•

To suppress error messages and
following:

get

statistics,

use

the

BLISS>ALPHA/STATISTICS/NOERRS
/NOERRS is useful when there are too many errors to be
on the terminal and the user is requesting a listing.

1.3.4.1

listed

Syntax - Terminal-switch syntax is:
/ERRS
{ /STATISTICS

terminal-switch

1.3.4.2 Defaults - In the absence of
switches, the following are assumed:
/ERRS

/NOERRS
}
/NOSTATISTICS

explicit

choices

during

the

switches

have

terminal

/NOSTATISTICS

Errors are reported on the
statistics are suppressed.

1.3.4.3 Semantics - The
meanings:

terminal

compilation,

but

following

the

Switch

Meaning

/ERRS

List each error on the terminal
encountered in the compilation.

/NOERRS

Do not list errors on the terminal.

/STATISTICS

List the name and size (in words) of each routine
on the terminal after each routine is compiled.

/NOSTATISTICS

Do not list routine names and sizes.

1-11

TOPS-20 OPERATING PROCEDURES
1.3.5

Optimization Switches

Optimization switches are used to supply directions to the compiler
about the degree and type of optimization wanted,
and to make
assertions about the program so that the compiler can select the
appropriate optimization strategies.
Some examples of using the
optimization switches are as follows:
"
•
To increase the compilation speed by omitting some standard
optimizations, use the /QUICK switch, as follows:
BLISS> ALPHA/QUICK
•

To get minimum optimization, use the /OPTLEVEL switch with the
value 0, as follows:
BLISS>ALPHA/OPTLEVEL:O

•

To obtain maximum optimization, use the /OPTLEVEL switch
the value 3, as follows:

with

BLISS>ALPHA/OPTLEVEL:3
•

To direct the compiler to use techniques that may use more
storage for the program to increase its operating speed, use
the /ZIP switch, as follows:
BLISS>ALPHA/ZIP

To inform the compiler that the program uses pointers
• manipulate
named data, use the /NOSAFE switch, as follows:

BLISS>ALPHA/NOSAFE
A detailed discussion of the optimizations resulting
optimization switches is given in Chapter 8.

1.3.5.1

from

using

the

Syntax - Optimization-switch syntax is:

optimization-switch

( optimize-switch )
) optlevel-switch (
·1 safe-switch
zip-switch
quick-switch

optimize-switch

{ /OPTIMIZE

optlevel-switch

0 I 1 I 2 I 3
/OPTLEVEL
J'*
/SAFE I /NOSAFE

safe-switch

/NOOPTIMIZE

zip-switch

/ZIP I /NOZIP }

quick-switch

/QUICK I /NOQUICK

1.3.5.2 Defaults - In the absence of an explicit optimization switch,
the following are assumed:
/NOQUICK

/NOZIP

/OPTLEVEL:2

1-12

/SAFE

/OPTIMIZE

TOPS-20 OPERATING PROCEDURES
The compiler is directed:
•

To perform normal optimization,
trade-off in favor of space

balancing

the

•

To assume that all variables are addressed by name

•

To perform optimization across mark points

•

To perform flow analysis.

time/space

(Re,fer to Section 8.1.2.2.)

1.3.5.3 Semantics - Optimization switches indicate that one
optimize options are specified.
The optimize switches
following meanings.
.

or more
have the

Optimize-Value

Meaning

/QUICK

Omit some standard optimizations to
compilation speed.

/NOQUICK

Include standard optimizations.

/ZIP

Increase the execution efficiency of the program
being
compiled
by
using
more space where
appropriate.
For more information on the effect
of this value, see Section 8.1.4.

/NOZIP

Do not increase the space occupied by the program
to
improve
its
operating speed.
For more
information on the effect of this value,
see
Section 8.1.2.2.

/OPTLEVEL:n

Optimize the program being compiled
the optimize-level n, as follows:
Optimize-Level

o
1

2
3

increase

the

according

Meaning
Minimum optimization
Subnormal optimization
Normal optimization
Maximum optimization

n=3 optimizes speed at the expense of space in the
same way as /ZIP.
/OPTLEVEL:3 is equivalent to
/OPTLEVEL:2/ZIP.
For more information on the
effect of this value, see Section 8.1.2.
/SAFE

Assume that all named data-segments are referenced
by name and not manipulated in any way indirectly,
and use optimization techniques that exploit this
fact.
For more information on the effect of this
value, see Section 8.1.2.1.

/NOSAFE

Assume that sometimes a named data-segment is
referenced by means of a computed expression and,
therefore, some optimization techniques cannot be
used.

/OPTIMIZE

Perform full flow analysis over an entire routine.

/NOOPTIMIZE

Restrict flow analysis so that all data is assumed
to be changed across mark points.
(See Chapter 8
for a more complete discussion.)

1-13

TOPS-20 OPERATING PROCEDURES
1.3.6

Listing Switches

Listing switches are used to supply information about the form of the
output listing and are used in conjunction with the /LISTING output
switch.
Some examples of using the~listing switches follow:
•

To obtain a paged listing with 44 lines on each page, give the
following command line:
BLISS>ALPHA/LISTING/PAGSIZ:44

•

To obtain an unpaged listing, in which
are given, use the following switches:

the

macro

expansions

BLISS>ALPHA/LISTING/NOHEADER/FORMAT:EXPAND
•

To obtain a listing that contains the contents of the REQUIRE
files
given in REQUIRE declarations,
use the following
switches:
BLISS>ALPHA/LISTING/FORMAT:REQUIRE

To obtain an output listing that is intended to be assembled
• by
the MACRO assembler, use the ASSEMBLY option, as follows:
BLISS>ALPHA/LISTING/FORMAT:ASSEMBLY
•

To obtain a listing that is intended to be assembled and
does not contain binary, include the NOBINARY option:
BLISS>ALPHA/LISTING/FORMAT:(ASSEMBLY,NOBINARY)

The form of the output listing is described in Section 3.2.

1.3.6.1

Syntax - Listing-switch syntax is:

listing-switch
number-of-lines

(/PAGSIZ: number-of-lines
)
I /NOHEADER
(
) /HEADER
I /NOUNAMES
(
) /UNAMES
(/FORMAT : format-option-list)
21

(option,
format-option-list

option

. .. ) }

{ option
ASSEMBLY
BINARY
COMMENTARY
EXPAND
LIBRARY
OBJECT
REQUIRE
SOURCE
SYMBOLIC
TRACE

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

1-14

NOASSEMBLY
NOBINARY
NOCOMMENTARY
NOEXPAND
NOLIBRARY
NOOBJECT
NOREQUIRE
NOSOURCE
NOSYMBOLIC
NOTRACE

that

TOPS-20 OPERATING PROCEDURES
1.3.6.2 Defaults - In the absence of an explicit
switches, the following are assumed:

choice

listing

/PAGSIZ:52
/NOUNAMES
/NOHEADER
/FORMAT:(NOASSEMBLY,BINARY,COMMENTARY,NOEXPAND,NOLIBRARY,
OBJECT, NOREQUIRE, SOURCE, SYMBOLIC, NOTRACE)
The compiler produces a listing with 52 lines on each page;
the
listing includes no expansion or tracing.
The listing resembles a
typical macro source file but cannot be assembled.

1.3.6.3 Semantics - The listing switches indicate that one or more
listing options are given for the compilation.
Command-line switches
are preceded by a slash, while switches that can appear as a part of
the /FORMAT switch are not.
The source-values have the following
meanings:
Source-Value

Meaning

/HEADER

Page the listing produced on the
include a heading on each page.

/NOHEADER

Do not page the listing, do not include headings,
and do not produce statistics in the compilation
summary.

/PAGSIZ:lines

Use the number of lines specified for each page of
the list file.
The number of lines must lie in
the range:
20 < lines < 52.

/UNAMES

Replace names by machine-generated names so that
all names are unique and independent of scope,
resulting in a
listing that can be correctly
assembled.

/NOUNAMES

Do not replace names by unique names.

/FORMAT:

One (or more
options:

parentheses)

list

the

file

and

following

LIBRARY
Produce a trace in the listing file identifying the library after
a LIBRARY declaration and the first use of each name whose
definition is obtained from a library file.
For an example of a
library trace, see Section 3.2.4.2.
NOLIBRARY
Do not produce
contributions.

trace

identifying

any

libraries

and

their

listing

file.

REQUIRE
Include the contents of the specified file in the
For an example, see Section 3.2.4.2.
NOREQUIRE
Do not include the contents of the specified REQUIRE file in
listing.

1-15

the

TOPS-20 OPERATING PROCEDURES
EXPAND
Include the expansion of each macro call in the listing
For an example of a macro expansion, see Section 3.2.4.3.

file.

NOEXPAND
Do not include the expansion of macros.

TRACE
Include a trace of each macro expansion;
that is,
include the
parameter binding and any intermediate forms of expansion, as
well as the result of the expansion.
For an example of a macro
trace, see Section 3.2.4.4.

NOTRACE
Do not include a trace of macro expansions.

SOURCE
Increment the listing control counter. output is listed when the
listing control counter is positive and not listed when the
counter is zero or negative.

NOROURCE
Decrement the listing control counter.

OBJECT
Produce the object part of the output listing.

NOOBJECT
Suppress the object part of the output listing.

ASSEMBLY
Produce a listing that can be assembled, by listing the assembler
instructions produced as a result of compiling the BLISS program
and including all other information within comments.

NOASSEMBLY
Do not list the assembler instructions.

SYMBOLIC
Include a machine code listing that uses
source program.

names

from

the

BLISS

NOSYMBOLIC
Do not include a machine code listing that
names.

uses

source

program

COMMENTARY
Include a machine-generated commentary in the
listing.
At this time,
the machine-generated
limited to a cross-reference.

1-16

object
code
commentary is

TOPS-20 OPERATING PROCEDURES
NOCOMMENTARY
Do not include a commentary field in the object code listing.

BINARY
Include a listing of the
object code listing.

binary

for

each

instruction

the

NOB I NARY
Do not include a listing of the binary.
Each of the code-values is described and illustrated in Section 3.2.2
in connection with the discussion of the output listing produced by a
BLISS compilation.
Understanding the purpose of these code-values
requires knowledge of the format and purpose of the output listing, as
discussed in that section.

1.3.7

Reference Switches

The reference switches allow a cross-reference listing to be included
with the compiler listing, and/or a cross-reference data file to be
created (refer to Section 1.3.1) to produce a master cross-reference
listinq
(refer to master cross-reference utility program BCREF in
Section 9.3).
Some examples of using the reference switches are as
follows:
•

To have a cross-reference listing included with the normal
source compiler listing,
use the /CROSS-REFERENCE switch in
the command line as follows:
BLISS>ALPHA/LISTING/CROSS-REFERENCE
The compiler produces an object file and list file
to which a cross-reference listing is appended.

•

ALPHA. LST,

To have only a cross-reference listing produced
(without
normal source compiler listing), use the following:

the

BLISS>ALPHA/LIST/FORMAT:(NOSOURCE,NOOBJECT)/CROSS-REF
The compiler produces an object file and list file
which contains only the cross-reference listing.
•

To create only a master cross-reference data
/MASTER-CROSS-REFERENCE switch as follows:

file,

ALPHA.LST,
use

the

BLISS>ALPHA/MASTER-CROSS-REFERENCE
The compiler produces an object file and,
as suitable
for BCREF, master cross-reference file ALPHA.CRF.
•

input

To produce a compiler listing which includes a cross-reference
listing,
and a master cross-reference data file, use the
following:
BLISS>ALPHA/LIST/CROSS-REFERENCE/MASTER-CROSS-REFERENCE
The compiler produces an object file and list file ALPHA.LST,
to which a cross-reference listing is appended, and master
cross-reference file ALPHA.CRF.

1-17

TOPS-20 OPERATING PROCEDURES
•

To produce a listing with cross-references that include
multiple references to the same type symbol, occurring on the
same source line, use the following:
BLISS>ALPHA/LIST/CROSS-REFERENCE:(MULTIPLE)
The compiler produces an object file and list file ALPHA. LST,
to which a cross-reference listing is appended that includes
multiple references to the same symbol.

1.3.7.1

Syntax - Reference switch syntax is defined as follows:

referenceswitch
referencevalue

{( reference-value , ... )
{ : { reference-value
/CROSS-REFERENCE
{
/MASTER-CROSS-REFERENCE {:file-spec
{ MULTIPLE I NOMULTIPLE }

1.3.7.2 Defaults - In the absence of an explicit choice of
value, the following value is assumed by default:

reference

NOMULTIPLE

1.3.7.3 Semantics - The /CROSS-REFERENCE switch indicates that a
reference-value may be given for the compilation.
The reference-value
has the fOllowing meaning:
Reference-Value

Meaning

MULTIPLE

Allow all multiple references
(of the same
reference-type) to a symbol that occurs on the
same source line to be
included
in
the
cross-reference listing.

NOMULTIPLE

Exclude
from
the
cross-reference
listing
multiple references to symbols that occur on the
same source line.

1.3.8

Environment Switches

Environment switches are used to specify the processor model and the
operating system of the target system for which code is to be
generated.
Some examples of using the environment switches are as
follows:
•

To generate code that uses instructions available
KLIO processor, use the following command line:
BLISS>ALPHA/KLIO

1-18

only

TOPS-20 OPERATING PROCEDURES
The compiler reads the source from ALPHA.B36 or ALPHA.BLI and
creates an object file ALPHA.REL, which makes use of KLIO
instructions, such as ADJSP, to make stack adjustments and the
EXTEND instruction to· implement various character-handling
functions.
•

To generate code that makes calls on the TOPS-20 monitor using
JSYS instructions, use the following command-line:
BLISS>ALPHA/TOPS20
If ALPHA contains the main routine of the program,
the
compiler generates a RESET% JSYS before the call to the main
routines and a HALTF% JSYS immediately after the call to the
main routine.

1.3.8.1

Syntax - Environment-switch syntax is:

environment-switch

/KAlO I /KIIO I /KLIO I /KSIO
).
/TOPSIO
I /TOPS20
{
/EXTENDED
I /NOEXTENDED
(
/EXTENDED : SECTION-INDEPENDENT J

I
1.3.8.2 Defaults - If no
following are assumed:
/KLIO

/TOPS20

environment

switches

are

specified,

the

/NOEXTENDED

1.3.8.3 Semantics - Environment switches identify the target system
for which code is being generated.
Environment switches have the
following meanings:
/KAlO

Generate code that uses only the KAlO
instruction set; this code executes on
all processor models.

/KIIO

Generate code that uses only the KIlO
instruction set; this code executes on
KIlO, KLlO, and KSIO processor models.

/KLIO

Generate code that uses the
KLIO
instruction set; this code executes on
KLIO and KSIO processor models.

/KSIO

Generate code that uses the
KSIO
instruction set; this code executes on
the KIlO and KSIO processor models.

/TOPSIO

Generate code that makes calls to
TOPS-IO monitor.

the

/TOPS20

Generate code that makes calls to
TOPS-20 monitor.

the

/EXTENDED

Give partial support for the extended
addressing option for the KLIO Model
B.
This switch is valid only when the
/KLIO
and
/TOPS20
switches
are
specified or implied.

1-19

TOPS-20 OPERATING PROCEDURES
The same as /EXTENDED, except code is
generated that can be executed from
any section.

/EXTENDED:SECTION-INDEPENDENT

NOTE
A compiler-state-function is a
lexical-function that
expands
to a numeric-literal of 1 or 0 during
compilation to indicate whether a certain condition
exists.
The %SWITCHES lexical-function can be tested
during compilation to determine the setting of one or
more environment switches.
For example, the following
command line causes the %SWITCHES function to return
the indicated numeric-literal:
BLISS>ALPHA/KLlO/TOPSlO
%SWITCHES(KAlO)
%SWITCHES(KIlO)
%SWITCHES(KLlO)
%SWITCHES(KSlO)
%SWITCHES(TOPSlO)
%SWITCHES(TOPS20)

0
0
1
1
1
0

For additional information, refer to "Module-Switches"
in the BLISS Language Guide.
The preceding discussion also relates to the options of the same
to the module-head switch ENVIRONMENT.

1.3.9

name

Placement of Switches

Some directions can be given to the compiler either by command-line
switches or by switch settings contained in the module being compiled.
In some cases, the command-line switch name is the same as the switch
name
contained
in
the
module
(module switches and SWITCHES
declaration), and in other cases, it is similar but not identical.
Names of common switches are given in Table 1-1.

1.3.10

Switches and Default Module Switch Settings

The switches given in the command line alter the default settings
assumed for module switches.
A switch setting given in the module
head overrides the corresponding switch given in the command-line; any
switch setting given for a switches-declaration overrides the setting
given in the module head.
Suppose you are compiling two programs. The first program ALPHA.BLI
has a module switch CODE.
The second program BETA has no switches.
The bliss-command-line is as follows:
BLISS>/NOCODE ALPHA, BETA
The switch /NOCODE changes the initial default from /CODE to /NOCODE.
When the program ALPHA.BLI is compiled,
code is produced because
ALPHA.BLI has the module head switch CODE, which overrides the default
setting.
When the program BETA.BLI is compiled, no code is produced
because it takes its setting of that switch from the initial default
established in the command line.

1-20

TOPS-20 OPERATING PROCEDURES
Table 1-1: Command Line, Modul'e Switch, and SWITCH Names on TOPS-20
Command Line Name

Module Switch Name

SWITCHES Name

/CHECK

n/a

/CODE

CODE

n/a

/CROSS-REFERENCE

n/a

/DEBUG

DEBUG

n/a

/EXTENDED{:ext-option}l

ENVIRONMENT(EXTENDED{:ext-option}l)

n/a

/ERRS

ERRS

/FORMAT:ASSEMBLY

LIST(ASSEMBLY)

/FORMAT:BINARY

LIST(BINARY)

/FORMAT:COMMENTARY

LIST (COMMENTARY)

/FORMAT:EXPAND

LIST(EXPAND)

/FORMAT:LIBRARY

LIST(LIBRARY)

/FORMAT:OBJECT

LIST(OBJECT)

/FORMAT:REQUIRE

LIST(REQUIRE)

/FORMAT:SOURCE

LIST(SOURCE)

/FORMAT:SYMBOLIC

LIST(SYMBOLIC)

/FORMAT:TRACE

LIST(TRACE)

/KAIO

ENVIRONMENT(KAIO)

n/a

/KIIO

ENVIRONMENT (KIlO)

n/a

/KLIO

ENVIRONMENT(KLIO)

n/a

/KSIO

ENVIRONMENT(KSIO)

n/a

/MASTER-CROSS-REFERENCE

n/a

/OPTLEVEL:n

OPTLEVEL=n

n/a

/SAFE

SAFE

/TOPSIO

ENVIRONMENT(TOPSIO)

n/a

/TOPS20

ENVIRONMENT(TOPS20)

n/a

/UNAMES

UNAMES

/ZIP

ZIP

1. The EXTENDED{:ext-option} implies EXTENDED:SECTION-INDEPENDENT for the
command-line and EXTENDED:SECTION INDEPENDENT for the module switch.
n/a (not applicable) indicates that no corresponding switch exists.

1-21

TOPS-20 OPEftATING PROCEDURES
1.3.11

Positive and Negative Forms of Switches

In general, two forms of a switch are allowed:
a positive form and a
negative form.
For example,
/CODE (the positive form) directs the
compiler to generate code, and /NOCODE (the negative form) directs the
compiler to suppress code generation.
positive and negative forms of
a switch are mutually exclusive: only one form for any switch should
be given in a b1iss-command-line.

1.3.12

Abbreviations of Switch and Value Names

The command switch names and value names can be abbreviated as long as
the COMND% JSYS can complete the command unambiguously.
This is true
both for switches that can take values and switches that take no
value.
(Refer to Appendix A for a summary of positive and negative
forms of switches and values.)

1.4

SPECIAL FEATURES

1.4.1

Indirect Files

An indirect file is a file referenced within a BLISS command line:
it
is used to complete a BLISS command.
The indirect file may contain a
complete or partial BLISS command line:
for example, file names and
switch settings.
You reference the file by specifying an "at sign"
(@) followed by the file-spec,
the contents of which expand and
complete the command line.
For example, if the file TTY.CMD contains
one line with the following switch settings:
/LISTING:TTY:/FORMAT:(NOBINARY,NOCOMMENTARY)/NOHEADER
and the following command, using the indirect file TTY.CMD to
the remainder of a command line, is issued:

specify

BLISS>ALPHA@TTY.CMD
The compiler compiles ALPHA and sends the listing to the terminal
without
the binary,
commentary,
and page headers.
This is a
convenient shorthand method of specifying a commonly used set of
switches.
For another example,
assume
following command line:

that

the

file

LIB.CMD

contains

and that a reference to the indirect file
command line:

specified

the

LIB1+LIB2+LIB3/LIBRARY:LIB.L36
a

BLISS

BLISS>@LIB.CMD
The compiler uses the concatenation of files LIB1, LIB2, and
input and produces a library file, LIB.L36.

1-22

LIB3

TOPS-20 OPERATING PROCEDURES
1.4.2

EXEC Command

A b1iss-command-1ine may be specified on the same line as
command invoking the compiler as follows:

that

@BLISS bliss-command-line
The compiler will be invoked, compile the specified file or files, and
then exit back to the EXEC.
Command recognition, file specification
completion, and the question mark character features are not available
in this mode of operation.

1-23

CHAPTER 2
TOPS-IO OPERATING PROCEDURES

This chapter discusses the TOPS-IO operating procedures used to
compile a BLISS program.
The form of the command line is considered
first.
Then, the input to a BLISS-36 compilation is described and
illustrated.
Finally,
the command-line switches relevant to a
BLISS-36 compilation are given.
Compiling,
linking, and executing
a
BLISS-36
program
is
a
straightforward procedure.
In the simplest case,
to compile and
execute a program that consists of a single module, you enter the
module in a file (for example ALPHA.B36) and then compile it with the
BLISS-36 compiler, link it using LINK, and then run the linked image.
The EXECUTE command automatically invokes LINK as follows:
.R BLISS
*ALPHA=ALPHA
*"C
.EXECUTE ALPHA

The first command invokes the BLISS compiler to compile the module in
the file ALPHA.B36 and to produce an object file ALPHA.REL.
The
second command uses the object module in the file ALPHA.REL to produce
an executable image in memory and to execute the image.
To save the linked image, use the LOAD command and save the
image as follows:

resulting

.R BLISS
*ALPHA=ALPHA
*"C
.LOAD ALPHA
.SAVE ALPHA

You can control the compiler by using command-line switches.
These
switches add a
level of complexity to the compilation process, but
they also provide a significant number of options by which you can
vary the performance of the compiler in the production of output, the
formatting of listings, and the degree of optimization performed.

2.1

COMPILING A BLISS PROGRAM

The BLISS compiler uses the standard TOPS-IO command interpreter,
SCAN, to parse the command line.
As such, various features of command
line processing that are common to many programs and the TOPS-IO
monitor are also common to the BLISS compiler.
Some of these include
formats for file specifications and common switches.

2-1

TOPS-IO OPERATING PROCEDURES
To compile a BLISS program, you run the BLISS compiler from the
command level and wait for the '*' prompt.
(The simplest way to run
the BLISS compiler is to have the compiler, BLISS.EXE,
reside on
logical device SYS~. For the remainder of this chapter, it is assumed
that you have invoked the compiler by typing
'R BLISS'
in monitor
mode.)
You
then
provide
a
source-file
list,
an optional
output-file-list, and the number of switches desired;
some examples
are given in the following list:
•

To compile a program, give the following command:
*MYPROG=MYPROG
The BLISS compiler uses the file MYPROG.B36 or MYPROG.BLI as
its input, compiles the source in that file, and produces
object file MYPROG.REL.

•

To produce
follows:

listing

file,

specify

the

listing

file

*MYPROG,MYPROG=MYPROG
The BLISS compiler produces, in addition to the
listing file MYPROG.LST.
•

object

file,

To produce an object file with a name different from that
the source file, give the name in the command as follows:

*GAMMA=ALPHA
The BLISS compiler produces the object file GAMMA.REL.
•

To produce a library file instead of an object file,
command switch /LIBRARY as shown in the following:

use

the

*ALPHA=ALPHA/LIBRARY
The BLISS compiler compiles input file ALPHA.R36 and
library file ALPHA.L36.
•

produces

To compile a program that consists of several pieces, each in
a separate file, include all file names on the command line
*ALPHA=ALPHA,BETA,GAMMA
The BLISS compiler compiles the program formed by
concatenation of ALPHA.B36,
BETA.B36,
and GAMMA.B36,
produces the single object file ALPHA.REL.
NOTE
The TOPS-lO EXEC does not support BLISS-36 in
COMPIL-class commands. Therefore, the command
.EXECUTE ALPHA.BLI
will not compile and execute ALPHA as a
BLISS-36 module.
However, it will attempt to
use BLISS-lO to compile ALPHA.BLI.

2-2

the
and

TOPS-I0 OPERATING PROCEDURES
2.1.1

Command-Line Syntax
bliss-command-line

(output-file-list} =
source-file-list (switch ... }

source-file-list

source-file-spec, ...

output-file-list

Object-file-spec , ... }
,listing-file-spec , .. .
{ ,master-cref-spec

source-file-spec }
object-file-spec
listing-file-spec
master-cref-spec

file-spec

See Section 2.2

switch

See Section 2.4

2.1.2

Command-Line Semantics

The
BLISS-36
compiler
uses
any
switches
given
in
the
bliss-command-line
to
modify
the
initial
defaults for each
compilation.
Then, the concatenated input is compiled in the context
of the initial defaults.
The switches and the initial default for
each switch are described in Section 2.4.
Unless a switch is used to change the compiler's behavior, the output
compilation initiated from your terminal (or batch file) will consist
of an object file (if specified), a listing file (if specified), and a
terminal listing.
The compiler begins with the first file given and continues until an
end-of-file is reached.
The compiler continues reading input from the
next file specified, and so on, until all the files in the source file
list are used.

2.2

FILE SPECIFICATIONS

File specifications are used to name the source of program text to be
compiled and the destination of output from the compilation.
More
precisely, file specifications can occur in three contexts:
•

The source-file-list of a bliss-command-line

•

REQUIRE and LIBRARY declarations in the module being compiled

•

The OTS module switch

2-3

TOPS-10 OPERATING PROCEDURES
2.2.1

Syntax

The standard TOPS-IO file specification is:
file-spec

{ device:}

device

any logical or physical device name
of 1 to 6 alphanumeric characters

file-name

1 to 6 alphanumeric characters

extension

o to 3 alphanumeric characters

ppn

project-number,programmer-number

2.2.2

file-name { .extension } { [ppn] }

Semantics

A file specification is interpreted as follows:
1.

If an extension is not given a default extension is used,
described in the next section~

If the file-spec applies to an output file and a file name is
not
given,
the name of the first input file
in the
source-file-list is used.

This same interpretation is also used by the compiler when processing
the file specification given in a REQUIRE or LIBRARY declaration.
The file-spec must be fully specified in the OTS module switch.
is, no defaults are supplied by the compiler.

2.2.3

That

Default Extension

The compiler has two ordered lists of default extensions to be tried
The list
for a source-file-spec that does not include an extension.
that the compiler applies depends on the output specified for the
compilation, as indicated in the following list:
File Use

Default Extension List

Input-spec used to
produce an object module

.B36,

.BLI

Input-spec used to
produce a library file

.R36,

.REQ,

.B36,

.BLI

If the program being compiled contains a
REQUIRE
or
LIBRARY
declaration,
the compiler uses the following list to search for the
appropriate extension according to the type of declaration:
File Use

Default Extension List

File given in a
REQUIRE declaration

.R36,

File given in a
Library declaration

.L36

2-4

.REQ,

.B36,

.BLI

TOPS-IO OPERATING PROCEDURES
For example, suppose you have entered the
file ALPHA.BLI:

following

program

the

MODULE MYTEST
BEGIN
REQUIRE 'CBLISS':
IJIBRARY 'TBLISS':
END
ELUDOM
And, suppose further that you compile it as follows:
*ALPHA=ALPHA
Since the bliss-command-line shown does not contain
a
switch
requesting the production of a
library file,
the output of the
compilation is an object module.
The compiler, therefore, chooses the
list of default extensions associated with object module output and
searches first for ALPHA.B36,
then,
not finding that file,
for
ALPHA.BLI,
which it finds and compiles.
In processing the module
MYTEST in that file, the compiler encounters the REQUIRE declaration
for the file CBLISS.
Since an extension for CBLISS is not given, the
compiler uses the list of default extensions for files
in a REQUIRE
declaration
and searches for CBLISS.R36,
then CBLISS.REQ,
then
CBLISS.B36, and finally CBLISS.BLI. When the compiler processes the
LIBRARY declaration,
it uses the default extensions list associated
with library declarations and searches for TBLISS.L36.

2.3

OUTPUT SPECIFICATIONS

An output specification is used to indicate the type of output to be
produced from a BLISS-36 compilation and to give names for the files
to be produced when you do not want to use the default names.
There
are two ways of specifying output specifications to the compiler.
The
first is to specify an object or list file specification in the
bliss-command-line.
The second is to specify both an object file
specification and the /LIBRARY switch,
in which case the compiler
creates a library file, rather than an object file.
Thus, the syntax
for the output-specification could appear as follows:
output-spec

library-spec }
{ file-;-spec-list
nothlng

file-spec-list

{library-switch

object-spec ,... }
,list-spec , ...
{ ,master-cref-spec

Some examples of ways to give output specifications
are given in the following list:
•

the

To suppress the production of an object file, omit the
file specification as follows:

compiler
object

*=ALPHA
The BLISS-36 compiler reads the source file ALPHA.B36 but
produces no output files.
However, error messages and summary
information are produced at the terminal.

2-5

TOPS-I0 OPERATING PROCEDURES
•

To obtain a list file, give a listing file specification:
*ALPHA,ALPHA=ALPHA
The BLISS-36 compiler produces an object file ALPHA.REL and
list file ALPHA. LST.

•

To use a different name for the object or list files,
following command line:

use

the

The compiler reads the source file ALPHA.B36 and produces
object file BETA.REL and the list file GAMMA. LST.

the

*BETA,GAMMA=ALPHA

•

To produce a master cross-reference data file, use the
cross-reference file specification:

master

*"MASTER=ALPHA

•

The compiler reads the source file ALPHA.B36 and produces
master cross-reference data file MASTER.CRF.

the

To produce a library file rather than an object file
/LIBRARY switch, as follows:

use

the

The compiler reads the source file ALPHA.B36 and produces
library file ALPHA.L36.

the

* ALPHA=ALPHA/LI BRARY

2.4

COMMAND-LINE SWITCHES

The switches in the command line allow you to give the compiler
information about the status of the compilation. A library switch,
for example, tells the compiler something about the kind of output you
want from the compilation.
An optimization switch describes the
amount and type of optimization to be performed. A source-list switch
indicates the switch of the source part of the output, and so on.
The
kinds of switches are indicated in the following syntax:

switch

2.4.1

library-switch
general-switch
check-switch
terminal-switch
optimization-switch
listing-switch
reference-switch
environment-switch

Library Switches

Library switches are used to indicate whether an object spec refers to
an object file or to a library file.
The object-spec can specify
either a program's object file or a library file, but not both.
The
/LIBRARY switch is used to specify that the object-spec refers to a
library file.

2-6

TOPS-10 OPERATING PROCEDURES
2.4.1.1

Syntax - Library-switch syntax is:

library-switch

{/LIBRARY

2.4.1.2 Defaults - If
follo\\ring is assumed:
'Ie', ,

/NOLIBRARY

output-specification

specified,

the

=source-file-spec/NOLIBRARY

Both t~he commas and equals sign are unnecessary if the object-spec,
list-spec,
and master-cref-spec are omitted.
The equals sign is
required but the commas are not, if only the object-spec is specified.
However,
both
are
required
if
the
list-spec
and/or
the
master-cref-spec is specified.
No object file is produced if the object-spec is omitted. No listing
file is produced if the list-spec is omitted.
And no master
cross-reference data file is produced if the master-cref-spec is
omitted.
/NOLIBRARY is assumed if the library switch is omitted.
If the file type is omitted from a file-spec, the following
defaults are supplied, according to the file-designator:
File-Designator

Default Extension

object-spec/NOLIBRARY

.REL

object-spec/LIBRARY

.L36

list-spec

.LST

master-cref-spec

.CRF

2.4.2

file-type

General Switches

General switches are used to specify code and debug information and to
set t.he value for the lexical function %VARIANT.
Some examples of
using general switches follow:
•

To include the necessary debug linkage in the compiled
program, use the /DEBUG switch in the bliss-compilation:
*ALPHA=ALPHA/DEBUG
The compiler reads the source from ALPHA.BLI and creates an
object file ALPHA.REL, which includes additional code for
interface with SIXl2.

•

To check the syntax of a program you do not intend to execute,
use the /NOCODE switch to save compilation time, as follows:
*=ALPHA/NOCODE

•

To set the value of the lexical function %VARIANT to
the /VARIANT switch as follows:

17,

use

*ALPHA=ALPHA/VARIANT:l7
•

To limit the number of errors diagnosed to 10, use the /ERRLIM
switch as follows:
*ALPHA=ALPHA/ERRLIM:IO
2-7

TOPS-lO OPERATING PROCEDURES
2.4.2.1

Syntax - General-switch syntax is:

/DEBUG I /NODEBUG}
I /NOCODE
/CODE
/VARIANT {:value}
/ERRLIM {:value}

general-switch

2.4.2.2 Defaults - If
following are assumed:
/NODEBUG

/CODE

general

switches

/VARIANT:O

are

specified,

the

/ERRLIM:30

value,

If the general switch /ERRLIM is given without a
value of 1 is assumed.

value,

specified

2.4.2.3

Semantics - General switches perform the following functions:

/DEBUG

Generate debugging linkage and limit optimization so
that SIX12 optimizations may be effectively used.
Also, include symbolic information in the object file
produced.

/NODEBUG

Produce symbolic information but no debug linkage,
and
do not limit optimizations (required for the effective
use of SIX12).

/CODE

Generate object code for the BLISS source module.

/NOCODE

Perform only a syntax check of the program.

/VARIANT

Set %VARIANT to 1.

/VARIANT:n

Set %VARIANT to n, where n is a decimal integer in
range:
-(2**35)

(2**35)-1

/ERRLIM

Set limit to 1.

/ERRLIM:n

Limit to n the number of
terminating the compilation.

2.4.3

the

errors

diagnosed

before

Check Switch

The check switch controls the level of semantic checking done during
compilation.
The switch allows all legal BLISS syntax to be examined
for semantic irregularites.
Some examples of the use of the check
switch are as follows:
•

To suppress field-name checking on structure accesses if the
data-segment declaration has no field-attribute, use the check
qualifier as follows:
*ALPHA=ALPHA/CHECK:NOFIELD
2-8

TOPS-10 OPERATING PROCEDURES
•

To check for the use of
qualifier as follows:

un~nitialized

storage, use

the

check

*ALPHA=ALPHA/CHECK:INITIAL

2.4.3.1

Syntax - Check switch syntax is defined as follows:

check switch

/CHECK:

(check-value ,... )}
{ check-value

FIELD
INITIAL
OPTIMIZE
REDECLARE

check-value

NOFIELD
NOINITIAL
NOOPTIMIZE
NOREDECLARE

2.4.3.2 Defaults - In the absence
of
a
specific
check-value, the following values are assumed by default:
FIELD

INITIAL

OPTIMIZE

choice

NOREDECLARE

2.4.3.3 Semantics - The /CHECK switch indicates that one or more
check-values follow.
The check-values have the following meanings:
Check-Value

Meaning

FIELD

Do not suppress field-name checking.

NOFIELD

If
the
data-segment
declaration
has
no
field-attribute,
suppress field-name checking on
the structure accesses.

INITIAL

Check for the use of uninitialized storage.

NOINITIAL

Do not check for uninitialized storage.

OPTIMIZE

Check for suspicious optimizations. For example,
constant folding expressions of a form that is
always false, such as:
.X<O,8,l> EQL %X'FF '

NOOPTIMIZE

Do not check for suspicious optimizations.

REDECLARE

Check for the redeclaration of a
nested scope.

NOREDECLARE

Do not check for the redeclaration of a name.

2.4.4

name

within

Terminal Switches

Terminal switches are used to control the output that is sent to the
terminal.
You can have errors or statistics printed or not printed on

2-9

TOPS-10 OPERATING PROCEDURES
the terminal during the compilation of a BLISS program.
of using terminal switches follow:

Some examples

see the statistics for each routine as they are produced
• To
during
the compilation,
use the /STATISTICS switch,
as
follows:
*ALPHA=ALPHA/STATISTICS
•

To suppress error messages, use the
example, consider the following:

/NOERRS

switch.

Note that the /STATISTICS switch is abbreviated to /ST in
above example.

the

*ALPHA=ALPHA/ST/NOERRS

/NOERRS is useful in preventing a profusion of error messages
from being listed on the terminal when a listing is requested.

2.4.4.1

Syntax - Terminal-switch syntax is:
/ERRS
{ /STATISTICS

terminal-switch

2.4.4.2 Defaults
If
following are assumed:
/ERRS

terminal

/NOERRS
}
/NOSTATISTICS

switches

are

specified,

the

during

the

compilation,

but

/NOSTATISTICS

Errors are reported on the
statistics are suppressed.

2.4.4.3 Semantics - Terminal
functions:

terminal

switches

perform

the

following

Switch

Meaning

/ERRS

List each error on the terminal
encountered in the compilation.

/NOERRS

Do not list errors on the terminal.

/STATISTICS

List the name and size of each routine
terminal after each routine is compiled.

/NOSTATISTICS

Do not list routine names and sizes.

2.4.5

the

Optimization Switches

Optimization switches are used to supply directions to the compiler
about the degree and type of optimization wanted,
and to make
assertions about the program so that the compiler can select the

2-10

TOPS-IO OPERATING PROCEDURES
appropriate optimization strategies.
optimization switches are as follows:
•

Some

examples

using

To increase the compilation speed by omitting some standard
optimizations,
use the /QUICK switch in the command line, as
follows:
*ALPHA=ALPHA/QUICK

•

To get minimum optimization, use the /OPTLEVEL switch with the
value 0, as follows:
*ALPHA=ALPHA/OPTLEVEL:O

•

To obtain maximum optimization, use the /OPTLEVEL switch
the value 3, as follows:

with

*ALPHA=ALPHA/OPTLEVEL:3
•

To direct the compiler to use techniques that may use more
storage for the program to increase its operating speed, give
the /ZIP switch, as follows:
*ALPHA=ALPHA/ZIP

•

To inform the compiler that the program uses pointers
manipulate named data, use the /NOSAFE switch, as follows:

*ALPHA=ALPHA/NOSAFE
A detailed discussion of the optimizations resulting from the
the optimization switches is given in Chapter 8.

2.4.5.1

use

Syntax - Optimization-switch syntax is:

optimization-switch

optlevel-switch

Optlevel-switch}
safe-switch
{ zip-switch
quick-switch
/OPTLEVEL : optimization-level

optimization-level

safe-switch

/SAFE

/NOSAFE

zip-switch

/ZIP

/NOZIP }

quick-switch

/QUICK

2.4.5.2 Defaults - If no optimization
following are assumed:

/NOQUICK

/NOZIP

/OPTLEVEL:2

/NOQUICK

switches

are

specified,

the

/SAFE

The compiler is directed to perform normal optimization, balancing the
time/space trade-off in favor of space, to assume that all variables
are addressed by name, to perform optimization across mark points, and
to perform flow analysis.
(See Section 8.1.2.)

2-11

TOPS-IO OPERATING PROCEDURES
2.4.5.3 Semantics - The optimization switches indicate that one or
more optimize options are specified. The optimize switches have the
following meanings:
Optimize-Value

Meaning

/QUICK

Omit some standard optimizations to
compilation speed.

/NOQUICK

Include standard optimizations.

/ZIP

Increase the execution efficiency of the program
being
compiled
by
using
more space where
appropriate.
For more information on the effect
of this value, see Section 8.1.4.

/NOZIP

Do not increase the space occupied by the program
to
improve
its
operating speed.
For more
information on the effect of this value,
see
Section 8.1.2.2.

/OPTLEVEL:n

Optimize the program being compiled
the optimize-level n, as follows:
Optimize-Level

increase

the

according

Meaning
Minimum optimization
Subnormal optimization
Normal optimization
Maximum optimization

2
3

n=3 optimizes speed at the expense of space in the
same way as /ZIP.
For more information on the
effect of this value, see Section 8.1.2.
/SAFE

/NOSAFE

Assume that sometimes a named data-segment is
referenced by means of a computed expression and,
therefore, some optimization techniques cannot be
used.

2.4.6

Listing Switches

Listing switches are used to supply information about the form of the
source code on the output listing. Some examples of using the listing
switches are as follows:
•

To obtain a paged listing with 44 lines on each page, give the
following listing switch:
*,ALPHA=ALPHA/PAGSIZ:44

•

To obtain an unpaged listing in which the macro expansions are
given but header information is not,
use the following
switches:
*,ALPHA=ALPHA/LIST:EXPAND/NOHEADER

2-12

TOPS-10 OPERATING PROCEDURES
•

To obtain a listing that contains the contents of the REQUIRE
files
given in REQUIRE declarations,
use the following
switches:
* ,ALPHA=ALPHA/LIST: REQUIRE

To obtain an output listing that is intended to be assembled
• by
the MACRO assembler, use the ASSEMBLY option, as follows:
*,ALPHA=ALPHA/LIST:ASSEMBLY
•

To obtain a listing that is intended to be assembled and
does not contain binary, include the NOBINARY option:

that

*,ALPHA=ALPHA/LIST:{ASSEMBLY,NOBINARY)
The form of the output listing is described in Section 3.2.

2.4.6.1

Syntax - Listing-switch syntax is:

/PAGSIZ: number-of-lines
}
/HEADER I /NOHEADER
/UNAMES
I /NOUNAMES
/LIST
: format-aptian-list

listing-switch
number-of-lines

format-aptian-list

{( option,
option

)}

ASSEMBLY
BINARY
COMMENTARY
EXPAND
LIBRARY
OBJECT
REQUIRE
SOURCE
SYMBOLIC
TRACE

option

2.4.6.2 Defaults - If
following are assumed:

listing

switches

... I

NOASSEMBLY
NOBINARY
NOCOMMENTARY
NOEXPAND
NOLIBRARY
NOOBJECT
NOREQUIRE
NOSOURCE
NOSYMBOLIC
NOT RACE

are

specified,

the

/PAGSIZ:52
/NOUNAMES
/NOHEADER
/LIST:(NOASSEMBLY,BINARY,COMMENTARY,NOEXPAND,NOLIBRARY,
OBJECT,NOREQUIRE,SOURCE,SYMBOLIC,NOTRACE)
The compiler produces a listing, with 52 lines on each page, in which
no expansion or tracing is included. The listing resembles a typical
macro source file.

2.4.6.3 Semantics - Listing switches indicate that one or
more
listing options are given for the compilation. The source-values have
the following meanings:
Source-Value

Meaning

/HEADER

Page the listing produced on the
include a heading on each page.
2-13

list

file

and

TOPS-IO OPERATING PROCEDURES
Source-Value

Meaning

/NOHEADER

Do not page the listing, do not include headings,
and do not produce statistics in the compilation
summary.

/PAGSIZ:lines

Use the number of lines specified for each page of
the list file.
The number of lines must lie in
the range:
20 < lines < 52.

/UNAMES

Replace names by machine-generated names so that
all names are-unique and independent of scope; the
resulting listing can thus be correctly assembled.

/NOUNAMES

Do not replace names by unique names.

/LIST:

One (or more
options:

parentheses)

the

following

trace

identifying

any

libraries

and

their

listing

file.

Include the expansion of each macro call in the listing
For an example of a macro expansion, see Section 3.2.4.3.

file.

REQUIRE
Include the contents of the specified file in the
For an example, see Section 3.2.4.2.
NOREQUIRE
Exclude the REQUIRE file contents from the listing.
EXPAND

NOEXPAND
Do not include the expansion of macros.
TRACE
Include a trace of each macro expansion.
That is,
include the
parameter binding and any intermediate forms of expansion, as
well as the result of the expansion.
For an example of a macro
trace, see Section 3.2.4.4.
NOTRACE
Do not include a trace of macro expansions.
SOURCE
Increment the listing control counter. Output is listed when the
listing control counter is positive and not listed when the
counter is zero or negative.

2-14

TOPS-IO OPERATING PROCEDURES
NOSOURCE
Decrement the listing control counter.

OBJECT
Produce the object part of the output listing.

NOOBJECT
Suppress the object part of the output listing.

ASSEMBLY
Produce a listing that can be assembled, by listing the assembler
instructions produced as a result of compiling the BLISS program
and including all other information within comments.

NOASSEMBLY
Do not list the assembler instructions.

SYMBOLIC
Include a machine code listing that uses
source program.

names

from

the

BLISS

NOSYMBOLIC
Do not include a machine code listing that
names.

uses

source

program

COMMENTARY
Include a machine-generated commentary in the
listing.
At this time,
the machine-generated
limited to a cross-reference.

object
code
commentary is

NOCOMMENTARY
Do not include a commentary field in the object code listing.

BINARY
Include a listing of the
object code listing.

binary

for

each

instruction

the

NOB I NARY
Do not include a listing of the binary.
Each listing switch is described and illustrated in Section 3.2.2 in
connection with the discussion of the output listing produced by a
BLISS compilation.
Understanding the purpose of these
listing
switches requires knowledge of the format and purpose of the output
listing, as discussed in that section.

2.4.7

Reference Switches

The reference switches allow a cross-reference listing to be included
with t~he compiler listing.
Further, a master cross-reference data
file can be created (refer to Section 2.3)
to produce a master

2-15

TOPS-10 OPERATING PROCEDURES
cross-reference listing (refer
program BCREF in Section 9.3).
switches are as follows:
•

to master cross-reference utility
Some examples of using the reference

To have a cross-reference listing included with the normal
source compiler listing, use the /CREF switch in the command
line as follows:
*,ALPHA=ALPHA/LIST/CREF
which

To have only a cross-reference listing produced (without
normal source compiler listing), use the following:

the

The compiler produces list file ALPHA.LST
cross-reference listing is appended.
•

*,ALPHA=ALPHA/LIST:(NOSOURCE,NOOBJECT}/CREF
The compiler produces list file ALPHA.LST, which contains only
the cross-reference listing.
•

To create only a master cross-reference data
master cross-reference file specification:

use

file,

the

* , , ALPHA=ALPHA
The compiler
ALPHA.CRF.

produces

master

data

cross-reference

file

produce a compiler listing that includes a cross-reference
• To
use the
listing and a master cross-reference data file,
fOllowing:
*,ALPHA,ALPHA=ALPHA/CREF
The compiler produces list file ALPHA.LST,
cross-reference
listing
is
appended,
cross-reference data file ALPHA.CRF.
•

to which
a
and
master

To produce a listing with cross-references that include
multiple references to the same type symbol occurring on the
same source line, use the following:
*,ALPHA=ALPHA/CREF:MULTIPLE
The compiler produces list file ALPHA.LST,
to which
a
cross-reference listing is appended that includes multiple
references to the same symbol.

2.4.7.1

Syntax - Reference qualifier syntax is defined as follows:

reference-switch
reference-value

{ (reference-value , ... )
/CREF { :{ reference-value}

J.}

MULTIPLE I NOMULTIPLE }

2.4.7.2 Defaults - In the absence of an explicit choice of
value, the following value is assumed by default:
NOMULTIPLE

2-16

reference

TOPS-IO OPERATING PROCEDURES
2.4.7.3 Semantics - The /CREF switch indicates that cross-references
are to be included in the listing and that zero or one reference-value
will be given for the compilation.
The reference-value have the
following meanings:
Reference-Value

Meaning

MULTIPLE

Allow all multiple references
(of the same
reference-type) to a symbol occurring on the
same source line,
to be included
in
the
cross-reference listing.

NOMULTIPLE

Exclude from the cross-reference listing all
multiple references to a symbol occurring on the
same source line.

2.4.8

Environment Switches

Environment switches are used to specify the processor model and the
operating system of the target system for which code is to be
generated.
Some examples of using environment switches are as
follows:
•

To generate code that uses instructions available
KL10 processor, use the following command line:

only

*ALPHA=ALPHA/KLlO
The compiler reads the source from ALPHA.BLI and creates
object
file
ALPHA.RELj
this
file makes use of KL10
instructions, such as ADJSP (which makes stack adjustments)
and
EXTEND
(which implements various character-handling
functions) .
•

To generate code that makes calls on the TOPS-20 monitor using
JSYS instructions, use the following command line:
*ALPHA=ALPHA/TOPS20
If ALPHA contains the main routine of the program,
the
compiler generates a RESET% JSYS before the call to the main
routine and a HALTF% JSYS immediately after the call to the
main routine.

2.4.8.1

Syntax - Environment switch syntax is:

environment-switch

2.4.8.2 Defaults - If no
following are assumed:
/KA10

/KAlO I /KI10 I /KL10 I /KS10}
{

/TOPS10

environment

/TOPS10

2-17

I /TOPS20

switches

are

specified,

the

TOPS-IO OPERATING PROCEDURES
2.4.8.3 Semantics - Environment switches identify the target system
for which code is being generated. Environment switches have the
following meanings:
/KAIO

Generate code that uses only the KAIO ins"truction
set; this code executes on all processing models.

/KIlO

Generate code that uses only the KIlO instruction
set; this code executes on KIlO and KLlO processor
models.

/KLlO

Generate code that uses the KLlO instruction set;
this code executes on KLlO and KSlO processor
models.

/KSlO

Generate code that uses the KSlO instruction set;
this code executes on a KSlO processor models.

/TOPSlO

Generate code that
monitor.

makes

calls

the

TOPS-lO

/TOPS20

Generate code that
monitor.

makes

calls

the

TOPS-20

NOTE
A compiler-state-function is a
lexical-function that
expands
to a numeric-literal of 1 or 0 during
compilation to indicate" whether a certain condition
exists.
The %SWITCHES lexical-function can be tested
during compilation to determine the setting of one or
more environment switches. For example, the following
command line causes the %SWITCHES function to return
the indicated numeric-literal:
*ALPHA=ALPHA/KLlO/TOPSlO
%SWITCHES(KAlO)
%SWITCHES(KIlO)
%SWITCHES(KLlO)
%SWITCHES(KS19)
%SWITCHES(TOPSlO)
%SWITCHES(TOPS20)

0
0
1
0
1
0

For additional information, refer to "Module-Switches"
in the BLISS Language Guide.

2.4.9

Placement of Switches

Some directions can be given to the compiler either by command line
switches or by switch settings contained in the module being compiled.
The command line switch name is in some cases the same as the switch
name
contained
in
the
module
(module switches and SWITCHES
declaration) and in other cases similar but not identical. The names
for the common switches are given in Table 2-1.

2.4.10

Switches and Default Settings

Command-line switches alter default" settings assumed for module
switches.
A switch setting in the module head overrides the
corresponding switch given in the command line.
A switch setting for
a switches-declaration overrides the setting given in the module head.
2-18

TOPS-lO OPERATING PROCEDURES
Suppose you are compiling two programs. The first program ALPHA.BLI
has a module switch CODE. The second program BETA has no switches.
The bliss-command-line is as follows:
*=:ALPHA,BETA/NOCODE
The switch /NOCODE changes the initial default from /CODE to /NOCODE.
When t.he program ALPHA. BLI is compiled,
code is produced because
ALPHA.BLI has the module head switch CODE, which overrides the default
setting.
When the module BETA.BLI is compiled, no code is produced
because it takes its setting of that switch from the initial default
established in the command line.
Table 2-1: Command Line, Module Switch, and SWITCH Names on TOPS-10
Command Line
Name

Module Switch
Name

SWITCHES Name

/CHECK

n/a

/CODE

CODE

n/a

/CREF

n/a

/DEBUG

DEBUG

n/a

/ERRS

ERRS

/LIST:ASSEMBLY

LIST (ASSEMBLY)

/LIST:BINARY

LIST(BINARY)

/L,IST: COMMENTARY

LIST (COMMENTARY)

/LIST:EXPAND

LIST (EXPAND)

/LIST:LIBRARY

LIST(LIBRARY)

LIST{LIBRARY)

/LIST:OBJECT

LIST{OBJECT)

LIST(OBJECT)

/LIST:REQUIRE

LIST(REQUIRE)

LIST{REQUIRE)

/LIST:SOURCE

LIST(SOURCE)

/LIST:SYMBOLIC

LIST{SYMBOLIC)

/LIST:TRACE

LIST{TRACE)

LIST(TRACE)

/OPTLEVEL:n

OPTLEVEL:n

n/a

/SAFE

SAFE

/UNAMES

UNAMES

/ZIP

ZIP

n/a (not applicable) indicates that no corresponding switch
exists.

2-19

TOPS-10 OPERATING PROCEDURES
2.4.11

positive and Negative Forms of Switches

In general, two forms of a switch are allowed: a positive form and a
negative form.
For example,
/CODE (the positive form) directs the
compiler to generate code and /NOCODE (the negative form) directs the
compiler to suppress code generation.
The positive and negative forms of a switch are mutually exclusive;
only one form for any switch should be given in a bliss-command-line.

2.4.12

Abbreviations

The command switch names and value names can be abbreviated as long as
SCAN can recognize the command unambiguously. This is true both for
switches that can take values and switches that take no value.

2.5

SPECIAL FEATURES

2.5.1

Indirect Files

An indirect file is a file referenced within a BLISS command line; it
is used to complete a BLISS command. The indirect file may contain a
complete or partial BLISS command line: for example,
filenames and
switch settings.
You reference the file by specifying an "at sign"
(@) followed by the file-spec,
the contents of which expands and
complete the command line.
For example, assume the file MYPROG.CCL contains the following command
lines:
LIB.L36=LIBl,LIB2,LIB3/LIBRARY
MYPROG=MYPROG
and that you issue the following command,
using
MYPROG.CCL to specify command lines to be read:

the

indirect

file

*@MYPROG.CCL
The compiler produces library file LIB.L36 from the concatenation of
source files LIBl, LIB2,
and LIB3, compiles indirect file MYPROG,
produces object file MYPROG.REL, ~nd prompts again with an asterisk.

2.5.2

Option File

An option file named DSK:SWITCH.INI may reside in your logged in disk
area; in it, you can set switches for use with various programs.
These switches allow you to override system defaults for individual
programs.
The BLISS compiler is such a program.
The syntax of the lines in the option file for BLISS is as follows:
BLISS switch
or
BLISS:option-name switch
where option-name is a 1- to 6-character name.

2-20

TOPS-IO OPERATING PROCEDURES
For example, suppose that option file SWITCH.INI contains the lines:
BLISS /STATISTICS/DEBUG
BLIS16 /STATISTICS/DEBUG
BLISS:TERM /LIST:(NOBINARY,NOCOMMENTARY)/NOHEADER
The following command would cause the first line to be read; this sets
the STATISTICS and DEBUG switches to be on as a default.
*ALPHA=ALPHA
The compiler compiles ALPHA, produces debug code, and
names and sizes on the terminal.
Note that the BLISS-36 compiler looks for BLISS,
compiler looks for BLIS16.

while

prints

routine

the

BLISS-16

To suppress debug code, type:
* J\LPHA=ALPHA/NODEBUG
To suppress both statistics and debug code, type:
*ALPHA=ALPHA/NOSTATISTICS/NODEBUG
or
*ALPHA=ALPHA/NOOPTION
Specifying the /NOOPTION switch prevents the compiler from reading the
SWITCH.INI file.
Given the following command, the compiler ignores the first BLISS line
in the option file and reads only the second:
*,TTY:=ALPHA/OPTIONS:TERM
The compiler compiles ALPHA and sends the listing to the terminal.
The listing would contain no binary, commentary, or page headers.

2-21

CHAPTER 3
COMPILER OUTPUT

This chapter discusses compiler output, starting with terminal output,
followed by list file considerations, and finally error messages.
The input to a BLISS compilation is a BLISS program.
As an example
consider the following module:
It contains two OWN declarations and
three ROUTINE declarations.
The routine IFACT computes the factorial
of its argument by an iterative method.
The routine RFACT computes
the factorial of its argument by a
recursive method.
The routine
MAINPROG provides some test calls on IFACT and RFACT.
Factorial
routines are discussed in Chapter 12 of the BLISS Language Guide.
MODULE TESTFACT (MAIN = MAINPROG)
BEGIN
OWN
A,
B~

ROUTINE IFACT (N)
BEGIN
LOCAL
RESULT~

RESULT = l~
INCR I FROM 2 TO .N DO
RESULT = .REULT*.I~
. RESULT
END~

ROUTINE RFACT (N)
IF .N GTR 1
THEN
.N*RFACT (.N - 1)
ELSE
1·
I

ROUTINE MAINPROG :NOVALUE
BEGIN
A = IFACT (5)~
B = RFACT (5)~
ENDi

END
ELUDOM
This module is used in the following sections to illustrate various
BLISS compilation output listings.
Two coding errors (missing equal
sign after the module-head and misspelled data-name) are included to
illustrate the error-reporting facility of BLISS.

3-1

COMPILER OUTPUT
3.1

TERMINAL OUTPUT

The compiler produces three kinds of information on the terminal:
error messages,
statistics,
and a compilation summary.
You can
request or suppress error messages and statistics by using a /ERRS or
/STATISTICS terminal-switch in the command line.
(Refer to Section
1.) By default, error messages are reported during compilation, but
statistics are suppressed. A compilation summary is always produced
on the terminal when the compilation ends.
Error messages show the source program line associated with the error
followed by a description of the error. The statistics show the name
of each routine declaration in the module and the number of data words
associated with that declaration.
The compilation summary gives the
number of warning and error messages, the number of words of code and
data used by the program, the run time and the elapsed time required
for the compilation, the number of lines and lexemes processed per CPU
minute,
and
the number of pages of memory required for the
compilation.
The last line of the terminal output indicates whether the compilation
produced an object file or a
library file.
If an object file is
produced, the last line is:
; Compilation Complete
If a library file is produced, the last line is:
; Library Precompilation Complete
Consider the terminal output for the sample module TESTFACT contained
in the file MYPROG.BLI.
To obtain all three kinds of information, the
module is compiled by one of the following bliss-command-lines:
=>20
BLISS>MYPROG/STATISTICS
=>10
*MYPROG=MYPROG/STATISTICS
The /STATISTICS switch is used so that all three types of
sent to the terminal.
The terminal output is as follows:
0002 0
BEGIN
% WARN#048
1 Ll:0002
Syntax error in module head
0014 2
RESULT = .REULT*.I;
% WARN#OOO
. . . . . . . . . . . . . . . . . . 1 Ll: 0014
Undeclared name:
REULT
IFACT 9
RFACT 14
MAINPROG 9
.MAIN. 16
Information:
0
Warnings:
2
Errors:
0
Size:
48 code + 2050 data words
Run time:
00:00.6
Elapsed time:
00:01.0
Lines/CPU Min:
3356
Lexemes/CPU-Min: 13426
Memory used:
3 pages
Compilation Complete

3-2

output

are

COMPILER OUTPUT
This ·terminal output for compiling MYPROG includes two warnings, which
are described in the following sections.
statistics follow the
warnings and show the number of data words required for each routine.
The example module TESTFACT contains three routine declarations:
IFACT, RFACT, and MAINPROG.
IFACT uses 9 words; RFACT uses 14 words;
MAINPROG uses 9 words.
Each main program is called by a small
predefined routine (.MAIN.), which is called by the operating system;
it requires 16 words.
The compilation summary shows that the compilation of TESTFACT
required 0.6 second of processor time and 1.0 second of elapsed time
to compile; moreover, 3356 source lines comprising 13426 lexemes were
processed per CPU minute.
The compilation required three pages of
memory, exclusive of the memory required for the compiler itself.

3.2

OUTPUT LISTING

The output listing produced as a result of a BLISS compilation can be
output on any suitable display device.
It consists of source listings
(including any error messages), optional object listings (as specified
through command-line switches), and a compilation summary.
When the compiler completes the processing of a routine declaration,
it produces the source and object listing for that declaration and any
nonroutine declarations that preceded it.
In this way,
the output
listing is divided into a sequence of segments (see Figure 3-1).
SOURCE
} SEGMENT 1
OBJECT
SOURCE
} SEGMENT 2
OBJECT
SOURCE
OBJECT
SOURCE
} SEGMENT n
OBJECT
CROSS-REFERENCE
OBJECT SUMMARY
COMPILATION STATISTICS
ZK-1368-83

Figure 3-1: Compiler Output Listing Sequence
You can suppress both the source and the object parts of a routine
segment, and change the format of the object part, by the inclusion of
switches in the module or in the command line.
In the absence of any
explicit instruction,
both source and object parts are produced.
If
the object part of the program is produced,
an object summary is
given.
The object surrunary contains a high and low segment length
summary and, if the compilation included any LIBRARY declarations,
a
summary of library usage.
The compilation summary contains the same
information as given in the compilation summary at the terminal.

3-3

COMPILER OUTPUT
The complete output listing for the module TESTFACT occupies several
pages
(refer to Appendix F).
Only the first routine segment of that
module is used here.
The routine segment for the routine IFACT
contains the module heading,
the OWN declaration, and the routine
declarations for IFACT.
The following sections discuss each part of
the output listing for that routine segment in detail.

3.2.1

Listing Header

Listing headers consist of two lines;
each line consists of three
fields
separated by at least one column.
The first field contains
information in columns 1 through 15; the second extends from columns
17 through 63;
the last extends from columns 65 through 132. The
contents of each field are left-justified within the field.
The
listing header format appears in Figure 3-2.
The listing header format appears as follows:
PRINT
POSITION

63 65

15 17

132

NAME

TITLE

PROCESSOR IDENTIFICATION

IDENT

SUBTITLE

SOURCE IDENTIFICATION
ZK-1369-83

Figure 3-2: Listing Header Format
The name and ident fields contain the same information as that
contained in the object file module headers.
Some processors must
generate the first page header before this information is available.
Thus,
the first page of a module may be blank; subsequent pages must
include the information if it appears in the object module.
If the
module name exceeds 15 characters, the title field begins 8 columns
further to the right.
The title and subtitle fields contain user-supplied information;
they
identify the purpose of the module and routine.
User title and
subtitle entries that are too long are right-truncated at column 63.
If the language processor makes no provision for you to supply this
information, the fields are ignored and the processor and source
identifications start in column 17.
If the language processor allows
only one set of title information, the subtitle field is used for
standard identification of the portion of the listing represented.
When you update the title or subtitle information in the first line of
the source page,
the listing for that page includes the updated
information.
The processor identification field contains the date and time of
compilation (in the form dy-mon-year hh:mm:ss) and the full product
name of the language processor.
This field includes the release
version number, with the edit number appended to it.
The page listing
number appears as the last entry in this field.
This number
increments by 1 for each listing page produced from a concatenated
source file, that is, in the listing file.
The source identification field contains the date and time of creation
or last modification of the source file being read at the start of
this page.
It also contains the resultant file name of this source
file.
It is a
fully qualified name, including the actual version

3-4

COMPILER OUTPUT
number.
If the name is too
long,
the
leftmost
field
is
right-truncated.
The source file page number appears last,
in
parentheses, and is one greater than the number of page marks
(form
feeds) read from the source.

3.2.2

Source Listing

The source part of the output listing reproduces the input to the
BLISS compilation with annotation supplied by the compiler.
The
compiler annotation includes a 16- or 24-character preface string that
precedes each line of input, and error' message lines that follow each
line on which one or more errors are detected.
The basic difference in preface string length is due to the fact that
the 24-character preface contains the editor's line sequence numbers
while the l6-character string does not.
The l6-character preface
string has the general form:
;byznnnnbnnbbbbb
The 24-character preface string has the general form:
;xxxxxbbyznnnnbnnbbbbbbb
Table 3-1 describes the components of each string.
(An asterisk
denotes the components and columns of the 24-character string.)
For example, consider the following line from the BLISS input:
RESULT

= 1;

If the above declaration is the fourteenth line in the
the output listing for that line appears as follows:
0014

RESULT

compilation,

= 1;

The line number 0014 is the line assigned by the BLISS compiler,
and
the begin-end block depth number 2 indicates that the line of code
occurs in the second block-level.
If the input line had an editor
line sequence number of 02300, the output listing for the line would
be:
;02300

0014

RESULT

If the input line comes from
includes an R, as follows:
R0014

RESULT

= 1;

REQUIRE

file,

RESULT

output

listing

= 1;

If the input line is contained within a macro
output listing includes an M, as follows:
M 0014

the

declaration,

then

the

= 1;

The y item in preface string column 3 (9 for a 24-character preface)
is useful for detecting lexical errors.
For example, if you forget to
terminate a macro declaration, all the following lines in the program
are then assumed to be part of that macro declaration, and the error
is not detected until the end of the program.
However, you can find
the beginning of the unterminated macro by locating the point at which
the M code first appeared in the y field before the runaway.

3-5

COMPILER OUTPUT
Table 3-1: Format of Preface String in Source Listing
Item

Meaning

Column
1

The comment character; used to comment out the
source line 50 that the output listing can be
assembled by the PDP-lO MACRO assembler.

xxxxx*
or
b

2-6*
or
2

The line number,
if the file contains line
sequence numbers; otherwise, one blank column.

bb*

7-8*

Blanks

9*
or

code that indicates the lexical processing
level of the compiler.
The codes that can
appear in this column are described below:

Code
C

Meaning
Embedded comment, that is, text

within

%( ••• ) %.

D
L
M
P
U

Default lexeme stream for a keyword
macro formal.
Parameter list of a lexical function.
Body of a macro definition.
Parameter list of a macro call.
Source text which is discarded by an
unsatisfied lexical condition.

If more than one such code applies
(for
example,
an embedded comment nested within a
macro body), the lIinnermost code is printed.
ll

10*
or
4

specified in a
If the line comes from a file
otherwise,
REQUIRE declaration, the code IIRII;
a blank.

nnnn

11-14*
or
5-8

The BLISS line sequence number, beginning with
0001, is increased by 1 each time a source
line is read.
This line number is referenced
by error messages and by the commentary field
of the object code listing.
It is always
incremented for source lines read from REQUIRE
files, even though those lines may not be
listed.

15*
or

Blank

16-17*
or
10-11

The begin-end block level number reflects the
depth of the code within each block structure.

bbbbbbb*

18-24*

Blanks

bbbbb

12-16

Blanks

3-6

COMPILER OUTPUT
An example of the source listing for the first segment of the module
TESTFACT, which uses the 16-character preface string, appears below.

0001 0
MODULE TESTFACT (MAIN
MAINPROG)
BEGIN
0002 0
1 Ll:0002
WARN#048
Syntax error in module head
0003 1
0004 1
OWN
A,
0005 1
0006 1
B;
0007 1
0008 1
ROUTINE IFACT (N)
0009 2
BEGIN
0010 2
LOCAL
RESULT;
0011 2
0012 2
RESULT = 1;
INCR I FROM 2 TO .N DO
0013 2
RESULT = .REULT*.I;
0014 2
. . . . . . . . . . . . . . . . . . 1 Ll:0014
WARN#OOO
Undeclared name:
REULT
. RESULT
0015 2
0016 1
END;

Following the three heading lines, which have been omitted in this
example,
the source of the module TESTFACT is reproduced.
The
16-character preface string begins with a semicolon
(;).
Since the
input file that contains the module TESTFACT does not have sequence
numbers, column 2 of the source listing is blank.
Columns 3 and 4 are
blank, because the lexical processing level is normal and the material
is not from a REQUIRE file.
Line numbers generated by the compiler
begin in column 5.
(See Figure 3-9 for a complete listing.)
Both error messages are reported as part of the source listing.
Section 3.4 contains a discussion of error messages in general and of
the meaning of these errors in particular.

3.2.3

Object Listing

The object part of the output listing has
four possible parts:
assembler input, assembler output, binary, and commentary field.
The
parts of the object listing that are produced depend on the choice of
listing switches specified in the command line.
Each part of the
object listing has associated with it a code-value that allows it to
be either printed or suppressed.
However, although 16 different forms of listings are theoretically
possible,
in practice only a few combinations of format-options are
meaningful.
The following combinations of the format options are reasonable:
ASSEMBLER

SYMBOLIC
{

}

COMMENTARY

NOSYMBOLIC

3-7

BINARY
{

NOBINARY

}
{

UNAMES

(

NOUNAMES

COMPILER OUTPUT
The commentary field requires
little space and provides useful
information about source line numbers, so that, currently, you have no
need for the NOCOMMENTARY switch.
Also, there is little reason to
specify the NOASSEMBLER switch, since its only effect is to suppress
the macro END statement.
The question of whether to have the binary appear on the listing is
one of personal preference. However, it may be useful for debugging
purposes.
The compiler produces the following information for each field.
ASSEMBLER field

Instructions in assembler form.
MOVEI

SYMBOLIC field

Operands
example:
I

BINARY field

AC16,
using

For example:

1
symbolic

source

names.

For

Octal equivalent of instructions and data to
facilitate
debugging.
The octal instructions
appear as much as possible in the same format as
that produced by the MACRO assembler.
The following codes may be appended to octal
values in the binary field to provide information
about relocation of quantities:
Code

Meaning

Blank

Absolute quantity (no linker action)

Forward relocatable

Relocated by POLISH expression
Relocated relative to PSECT

*
COMMENTARY field

Relocated relative to external symbol

A cross-reference to the source program line
generating the code.
If a program line generates
more than one instruction line, commentary fields
in the lines following the instruction generated
first are left blank.

The partial printout of a default object listing appearing in Figure
3-3 illustrates the object part of the routine segment.
The command
line
=>20
BLISS>TESTFACT/LIST
=>10
*TESTFA,TESTFA=TESTFA
generated the listing, in which the assembler field appears first,
followed by the symbolic field, the binary field, and the commentary
field.
Note that the default switch settings in effect are ASSEMBLER,
SYMBOLIC, COMMENTARY, BINARY, and NOUNAMES.

3-8

A:
B:
ACO=
ACl=
AC2=
AC3=
AC4=
AC5=
AC6=
AC7=
ACI0=
ACll=
AC12=
AC13=
AC14=
FP=
AC16=
SP=

w
I
\.0

IFACT:

TITLE
TESTFACT
TWOSEG
. REQUEST SYS:B360TZ.REL
RELOC
0
BLOCK
1
BLOCK
1
EXTERN REULT
0
1
2
3
4
5
6
7
10

000000'
000000'
000001'

12
13
14
15
16

n
0

."
H

RELOC
MOVEI

400000
ACl,l

RESULT, 1

400000'
400000' 201 01 0 00 000001

0012

t'I

til
~

MOVEI

AC2,l

1,1

400001' 201 02 0 00 000001

L.l :

JRST
MOVE

L.2
ACl, REULT

L.2
RESULT,REULT

400002' 254 00 0 00 400005'
400003' 200 01 0 00 000000*

."
C

L.2:

IMUL
ADDI

ACl,AC2
AC2,l

RESULT, I
1,1

400004' 220 01 0 00 000002
400005' 271 02 0 00 000001

CAMG
JRST
POPJ

AC2,-l(SP)
L.l
SP,

l,N

400006' 317 02 0 17 777777
400007' 254 00 0 00 400003'
400010' 263 17 0 00 000000

1-3

0013
0014
0013
L.l
SP,

0008
Routine Size:

9 words

Figure 3-3: Default Object Listing Example

1-3

COMPILER OUTPUT
3.2.4

Source Part Options

The following sections contain more output listings to illustrate
different options for the source part of the list file.
To illustrate
different forms, the sample program TESTFACT has to be made more
interesting, along the lines given in the following paragraphs.
Suppose the testing of the same program TESTFACT is complete,
source
code errors contained in the preceding examples have been corrected,
and the data on the relative performance of the two factorial routines
obtained.
The next step is to produce a new module TEST, which uses
the factorial routine to take combinations according to the following
formula for obtaining the number of combinations of m items taken n at
a time:
m!
(m-n)! n!
where m! is the notation for the factorial of m.
First, enter the routine declarations for IFACT and RFACT into
separate REQUIRE files,
named IFACT and RFACT, respectively.
The
module TEST can then use either routine by including the appropriate
REQUIRE declaration.
Next, write a macro for obtaining the combinations, namely:
MACRO
COMBINATIONS(M,N)
(IF (M) LSS (N)
THEN ERROR()
ELSE COMB(M,N)) %,
COMB(M,N)
FACT(M)/(FACT«M)-(N))*FACT(N)) %i
Then, precompile the macro declaration into a LIBRARY file as
(include a LIBRARY declaration in the module TEST):

follows

=>20
BLISS>COMBN!LIBRARY
=>10
*COMBN=COMBN/LIBRARY
Finally, include some test combinations.
The following sections illustrate the different output
obtained for that module by varying the command switches.

3-10

listings

COMPILER OUTPUT
3.2.4.1

Default Source Listing - The command line

=>20
BLISS>TEST/LIST/NOCODE
=>10
*TEST,TEST=TEST/NOCODE
generated the output listing in Figure 3-4 for the module TEST.
Note
that although the contents of the REQUIRE file are not printed, the
lines within the file are numbered by the compiler.
The output
listing shows that lines 0011 through 0014 are used for this purpose.

3.2.4.2

Listing with LIBRARY/REQUIRE Information - The command line

=>20
BLISS>TEST/NOCODE/LIST/FORMAT:(LIBRARY,REQUIRE)
=>10
*TEST,TEST=TEST/NOCODE/LIST:(LIBRARY,REQUIRE)
generated the output listing in Figure 3-5, which contains information
from the LIBRARY and REQUIRE files.
The LIBRARY file is identified
following line 0009 and the first use of a name from that library is
noted following line 0018. The contents of the REQUIRE file are given
in lines 0011 through 0014.

3.2.4.3

Listing with Macro Expansions - The command line

=>20
BLISS>TEST/NOCODE/LIST/FORMAT:EXPAND
=>10
*TEST,TEST=TEST/NOCODE/LIST:EXPAND
generated the output listing in Figure 3-6 to illustrate macro
expanslons, which follow lines 0018 and 0019. Note that expansions
are listed in the order in which they occur.
The innermost expansion
is printed first, followed by the outer expansion, which includes the
expanded form of the inner macro.
The last line of the macro
expansion, therefore, is the fully expanded form.

3.2.4.4

Listing with Macro Tracing - The command line

=>20
BLISS>TEST/NOCODE/LIST/FORMAT:TRACE
=>10
*TEST,TEST=TEST/NOCODE/LIST:TRACE
produced the output listing in Figure 3-7, which contains macro
tracing and macro expansions. The macro trace gives information about
parameter binding in addition to the expansion information.

3-11

w
I

0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0017
0018
0019
0020
0021
0022
0023
0024
0025

0
1
1
1
1
1
1
1
1
1
1
1
2
3
2
1
1
1
0

MODULE TEST (MAIN
BEGIN

MAINPROG)

OWN
A,
B;
EXTERNAL ROUTINE
ERROR;
LIBRARY 'COMBN'
REQUIRE 'RFACT'

ROUTINE MAINPROG =
BEGIN
A = COMBINATIONS (3, 2);
B = COMBINATIONS (6, 4);
END;
END
ELUDOM

I-'

LIBRARY STATISTICS

I\)

File

-------- Symbols -------Total
Loaded
Percent

Blocks
Read

Processing
Time

100

00:00.0

Run Time:
00:00.3
Elapsed Time:
00:00.8
Lines/CPU Min:
5952
Lexemes/CPU-Min: 49523
Memory Used:
3 pages
Compilation Complete

Figure 3-4: Default Source Listing Example

w
I
f-'
W

0001 0
MODULE TEST (~~IN
MAINPROG)
BEGIN
0002 1
0003 1
OWN
0004 1
A,
0005 1
B;
0006 1
0007 1
EXTERNAL ROUTINE
ERROR;
0008 1
0009 1
LIBRARY 'COMBN' ;
Library file produced by TOPS-20 Bliss-36 3A(177) on
REQUIRE 'RFACT' ;
0010 1
ROOll 1
ROUTINE FACT (N) =
IF .N GTR 1
R0012 1
R0013 1
THEN
.N*FACT (.N - 1)
R0014 1
R0015 1
ELSE
R0016 1
1;
0017 1
0018 1
ROUTINE MAINPROG
BEGIN
0019 2
0020 2
A = COMBINATIONS (3, 2);
Loaded symbol COMBINATIONS from library
Loaded symbol COMB from library
0021 2
B = COMBINATIONS (6, 4);
0022 1
END;
0023 1
0024 1
END
ELUDOM
0025 o
LIBRARY STATISTICS
File

3-May-1983 16:10:24

-------- Symbols -------Total
Loaded
Percent

Blocks
Read

processing
Time

100

00:00.0

Run Time:
00:00.3
Elapsed Time:
00:01.3
Lines/CPU Min:
4823
Lexemes/CPU-Min: 40128
Memory Used:
3 pages
Compilation Complete

Figure 3-5: Output Listing with Library and Require File Data

0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0017
0018
0019
0020

o
1
1
1
1
1
1
1
1
1
1
1

MODULE TEST (MAIN
BEGIN

MAINPROG)

OWN
A,
B;
EXTERNAL ROUTINE
ERROR;
LIBRARY 'COMBN'
REQUIRE 'RFACT'

ROUTINE MAINPROG =
BEGIN
2
A = COMBINATIONS (3, 2);
[COMB]= FACT ( ) / ( FACT ( - ) * FACT ( ) )
[COMBINATIONS]=
IF LSS THEN ERROR ( ) ELSE FACT
/
0021 2
B = COMBINATIONS (6, 4);
[COMB]= FACT ( ) / ( FACT ( - ) * FACT ( ) )
[COMBINATIONS]=
IF LSS THEN ERROR ( ) ELSE FACT ( ) /
0022 1
END;
0023 1
0024 1
END
ELUDOM
0025 0
LIBRARY STATISTICS
2

File

* FACT

FACT
( FACT ( -

)

* FACT ( ) ) )

-------- Symbols -------Total
Loaded
Percent

Blocks
Read

processing
Time

100

00:00.0

Run Time:
00:00.3
Elapsed Time:
00:01.2
Lines/CPU Min:
4983
Lexemes/CPU-Min: 41461
Memory Used:
3 pages
Compilation Complete

Figure 3-6: Output Listing with Macro Expansion Data

; ;
; ;

I
~

; ;
; ;
; ;
; ;
; ;
; ;
; ;
; ;

0001 0
MODULE TEST (MAIN
MAINPROG)
BEGIN
0002 1
0003 1
OWN
0004 1
A,
0005 1
B;
0006 1
0007 1
EXTERNAL ROUTINE
ERROR;
0008 1
0009 1
LIBRARY 'COMBN' ;
REQUIRE 'RFACT' ;
0010 1
0017 1
0018 1
ROUTINE MAINPROG =
0019 2
BEGIN
0020 2
A = COMBINATIONS (3, 2);
[COMBINATIONS]: Parameter binding
[COMBINATIONS](l)= 3
[COMBINATIONS](2)= 2
[COMBINATIONS]: Expansion
[COMB]: Parameter binding
[COMB](l)= 3
[COMB](2)= 2
[COMB]: Expansion
[COMB]= FACT ( ) / ( FACT ( - ) * FACT ( ) )
[COMBINATIONS]= (IF LSS THEN ERROR ( ) ELSE FACT ( ) /
0021 2
B = COMBINATIONS (6, 4);
[COMBINATIONS]: Parameter binding
[COMBINATIONS](l)= 6
[COMBINATIONS](2)= 4
[COMBINATIONS]: Expansion
[COMB]: Parameter binding
[COMB](l)= 6
[COMB] (2)= 4
[COMB]: Expansion
[COMB]= FACT ( ) / ( FACT ( - ) * FACT ( ) )
[COMBINATIONS]= (IF LSS THEN ERROR ( ) ELSE FACT ( ) /
0022 1
END;
0023 1
0024 1
END
0025 0
ELUDOM
LIBRARY STATISTICS
File

( FACT ( -

) * FACT ( ) ) )

( FACT ( -

)

* FACT ( ) ) )

-------- Symbols -------Total
Loaded
Percent

Blocks
Read

Processing
Time

100

00:00.0

Run Time:
00:00.3
Elapsed Time:
00:01.2
Lines/CPU Min:
4687
Lexemes/CPU-Min: 39000
Memory Used:
3 pages
Compilation Complete

Figure 3-7: Output Listing with Macro Expansion and Tracing Data

COMPILER OUTPUT
3.3

CROSS-REFERENCE LISTING

The cross-reference listing is an optional part of the output listing
that is produced by the compiler on request.
Cross-reference data are
generated on a module basis;
therefore,
the reference information
associated with a given module appears as the last module-specific
item in the listing file, before the compilation summary and before
any subsequent module data.

3.3.1

Cross-Reference Header

The cross-reference header is separated from the output listing header
by a blank line and subsequently appears on the first two lines of
each page of the reference listing.
The cross-reference header is as
follows:
Symbol

3.3.2

Type

Defined

Referenced ...

Cross-Reference Entries

The reference entries listed under each header name
fields that are separated by a single space.

are

fixed-length

Symbol Field
The Symbol field is used to list the names of the different symbols.
The length of the field is fixed at the length of the longest name in
the module. A name appears just once in the symbol field,
defining
its initial recognition by the compiler as a declared symbol.
If
multiple symbols are declared with the same name,
lines directly
following the first appearance of the name are used; however, for each
subsequent recognition the symbol field is left blank.
For example:
ALPHA
GAMMA
Type Field
The Type field describes the condition
(such as LOCAL,
BIND,
or
BUILTIN)
under which the symbol-name was used when it was declared.
The field is
eight
characters
long;
therefore,
symbol-type
abbreviations are used.
The symbol-type abbreviations are listed in
Table 3-2.
The NotDecl abbreviation indicates the use of a symbol that has not
been declared.
Thus,
the appearance of NotDecl in the type field
indicates an error.
The Enable, Forward, ForwRout, or Map abbreviation refers to symbols
that are declared elsewhere as routine or data-segment names.
Thus,
the appearance of any of these abbreviations in the type field usually
indicates an error.
The Unbound abbreviation indicates that the compiler made no attempt
to find a declaration for the symbol name because the name is not
bound to a symbol.
For example, a symbol in a macro actual-list,
or
in the false branch of a %IF compile-time conditional-function, is
declared as Unbound.
3-16

COMPILER OUTPUT
Table 3-2: Symbol Type Abbreviations
Meaning

Abbreviation

Bind
Bind Routine
Builtin
Compiletime
Enable
External
External Literal
External Register
External Routine
Field
Fieldset
Forward
Forward Routine
Global
Global Bind
Global Bind Routine
Global Literal
Global Register
Global Routine
Keyword Macro
Keyword Macro Formal
Label
Linkage
Literal
Local
Macro
Map
Macro Formal
Symbol without a declaration
Own
Psect
Register
Routine
Routine Formal
Structure
Stack local
Structure Formal
Name which is not bound
Undeclare

Bind
BindRout
Builtin
Comptime
Enable
External
ExtLit
ExtReg
ExtRout
Field
Fieldset
Forward
ForwRout
Global
GlobBind
G1BiRout
GlobLit
GlobReg
GlobRout
KeyWMacr
KeyWForm
Label
Linkage
Literal
Local
Macro
Map
MacrForm
NotDecl
Own
Psect
Register
Routine
RoutForm
Structur
Stackloc
StruForm
Unbound
Undeclar

As an example of the use of the symbol name and type
the following code segment:
00050
00051
00052
00053

BEGIN
LOCAL

00080
00081
00082
00083
00084

END;

00095

END;

ALPHA,
GAMMA;

BEGIN
LOCAL
ALPHA;

3-17

fields

consider

COMPILER OUTPUT
The appearance of the symbols in the cross-referencing
be as follows:
ALPHA
GAMMA

Local
Local
Local

listing

would

52
84

Defined Field
The Defined field identifies the compiler listing line number of the
declaration,
or the library (Lib) file number, and has a fixed length
of five characters. Exceptions occur with the NotDecl and Unbound
symbol types.
Since the symbol name in these cases cannot be
associated with a declaration, no line number can appear and the field
is blank.
The following example depicts the appearance of line
numbers, and a library file number, in the defined field.
A
B

COMB

Own
Own
Macro

5
6

LibOl

20=
20=
20

Note that a cross-reference map appears at the bottom of the listing
which locates and identifies each compiled file (source, require, or
library) by its intial line number and its file-specification.
Referenced Field
The Referenced field lists additional references and uses of the
symbol.
Each entry consists of a 5-character line number (or a
library file number) and a 2-character usage field.
If the references
require
more than one line,
the additional entries appear on
subsequent lines.
The 2-character usage-fields describe the way in which the symbols are
used. A usage-field may consist of none, one, or two of the following
characters.
Flag

Meaning

Declaration-Usage
e

EXTERNAL, EXTERNAL ROUTINE, or
declaration

FORWARD declaration

MAP declaration

Condition handler enabling

UNDECLARE declaration

Data-Usage
Fetch
Store
c

Routine call

Address use

Indirect use

3-18

EXTERNAL

LITERAL

COMPILER OUTPUT
A blank usage field indicates that usage is implied by the type of
symbol -- for example, a macro name used within a macro expansion, or
a structure name used as a structure-attribute in a declaration.
An (e), (f), (m), (h), or
(u)
flag appearing in the usage field
indicates a reference to the symbol name within an EXTERNAL, FORWARD,
MAP, ENABLE, or UNDECLARE type declaration.
The fetch flag (.) indicates that a data segment has been "fetched
from" a location defined by the symbol name, while the store flag (=)
indicates that a value has been "stored into" a
location defined by
the symbol name.
The address-use flag (a) indicates that the address of a data segment,
defined by the symbol name, has been stored into another data segment.
For example, A = B indicates that the address of the data segment
defined by B is stored in data segment A.
Thus, symbol B would be
flagged (a) for its use as an address, and symbol A would be flagged
(=) for its use as storage.
The indirect-use flag (@) never appears alone.
This flag is always
combined with the remaining data-usage flags to indicate that a data
segment has been used indirectly, such as fetched from (@.) or stored
into (@=)i however, note that all multiple levels of indirection are
flagged the same as a single level of indirection.
The following list provides samples of the two-character data-usage
codes. The examples reflect direct and indirect data uses of symbol B
as a BLOCK structure and then as a REF BLOCK structure.
Code

B:BLOCK[n]

B:REF BLOCK[n]

.. B

... B

@•

B[eJ

.B[eJ

( . B)

B[eJ =.A

B() = A

(.B)() = A

Thus, in relation to direct and indirect addressing,
the utility
recognizes ordinary structures and FIELD references.
For example,
consider the following code segment where explicit FIELD references
are made to data segments:
00030
00031
00032
00033
00034
00035

FIELD
My_fields =
SET
This field
That-field

[O,O,8,oJ,
[O,l,8,OJ

TESi

3-19

COMPILER OUTPUT
00036
00037
00038
00039

OWN
B : REF BLOCK[J FIELD (My_fields);
B[This fieldJ = .B[That fieldJ + Ii

The cross-reference listings for Bare:
B

Own

39@=

THAT FIELD
THIS FIELD

Field
Field

34
33

39.
39=

Note that since B is declared as a REF
references to B are indirect references.

39@.

structure,

the

structure

The next code example reflects an indirect address usage of B:
00030
00031
00032
00033
00034
00035
00036
00037
00038

00108

FIELD
My- fields =
SET
This - field
That field

[O,O,8,OJ
[O,l,8,OJ

TESi

OWN
B

REF BLOCK[J FIELD (My- fields) ;

C = B[That fieldJ

The listing for B is now:
B

Own

108@a

THAT FIELD

Field

108a

In this example, B points to a BLOCK in memory.
Through B, an address
within the BLOCK is indirectly stored in Ci thus, an indirect address
is flagged for B.

3.3.3

Output Listing with Cross-Reference Listing

The listing in Figure 3-8 includes a cross-reference listing that
produced by compiling module TEST with the following options:

was

=>20
BLISS>TEST/FORMAT:REQUIRE/LIST/CROSS-REFERENCE
=>10
*TEST,TEST=TEST/LIST:(REQUIRE)/CREF
Note that the listing includes cross-referenced information for the
LIBRARY and REQUIRE files.
The reference list is followed by a
cross-reference map, which specifies the first and last lines of the
files,
and a
flags legend, which describes the codes used in the
Referenced field.

3-20

COMPILER OUTPUT

(header)
0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
R0011
R0012
R0013
R0014
R0015
R0016
0017
0018
0019
0020
0021
0022
0023
0024
0025
Symbol

0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
1
1
1
0

MODULE TEST (MAIN
BEGIN

MAINPROG)

OWN
A,
B;
EXTERNAL ROUTINE
ERROR;
LIBRARY 'COMBN ' ;
REQUIRE 'RFACT ' ;
ROUTINE FACT (N) =
IF .N GTR 1
THEN
.N*FACT (.N - 1)
ELSE
1;

ROUTINE MAINPROG : NOVALUE =
BEGIN
A = COMBINATIONS (3, 2);
B = COMBINATIONS (6, 4);
END;
END
ELUDOM
Type Defined

Referenced ...

Own
5
20
6
21
Own
Macro
Lib01
COMB
20
Lib01
COMBINATIONS Macro
20
ExtRout
ERROR
8
20
Routine
11
14
FACT
Routine
MAINPROG
18
RoutForm
11
12
N
CROSS REFERENCE MAP
Line #:
Event
File
A
B

21
21
21
20

...

1
1
9
11
16
25

Source (start)
PS:<DIRECTORY>TEST.B36.3
Module TEST
Library #1
Require (start)
PS:<DIRECTORY>RFACT.R36.3
Require (end)
E1udom TEST
KEY TO REFERENCE TYPE FLAGS
Fetch
Store
c
Routine call
a
Address use
Indirect use
f
Forward or forward routine declaration
m
Map declaration
h
Condition handler enabling

Figure 3-8: Output Listing with Cross-Reference Listing Included

3-21

COMPI~R

3.4

OUTPUT

COMPILATION SUMMARY

The compilation summary appears at ·the end of
listing and consists of the following information:

3.5

every

psect-relative

compilation

starting

address

•

The routine size
and
(following each routine)

•

A program section summary (at the end of the module)

•

If a cross-reference listing is added, a
cross-reference map
of the files used and the line number where each file is first
referenced

•

If a cross-reference listing is added, a key to the meaning of
the usage-field characters

•

Library usage statistics indicating the libraries used and the
number of names loaded from each library (omitted if no
libraries are used)

•

The number of memory pages mapped and the processing time

•

The command line used to compile the module

•

Number of warnings and
errors exist)

•

Summary of statistics for the module, consisting of:
size of
code and data
(in bytes), run time, elapsed time, number of
lines and lexemes processed per CPU minute, memory used, and a
statement that the compilation is complete

errors

{omitted

warnings

ERROR MESSAGES

The BLISS compiler detects two types of errors:
fatal and warning.
A
fatal error is one that the compiler cannot handle without potentially
skipping some source. A warning error is one for which the compiler
has an effective recovery technique that permits it to generate an
executable object module.
Both the warning and the fatal errors
messages are listed separately in Appendix E.
The warnings are listed
by number, and each warning includes an explanation of the error and a
recommended user action.
If a fatal error is detected, the compiler continues to check syntax
of the remainder of the program;
any subsequent errors can be
detected, but neither an object module nor the object part of the
output listing is produced following the detection of the fatal error.
A warning error message begins with the identification WARN.
For
example,
the routine declaration for IFACT includes a coding mistake,
as follows:
RESULT

= .REULT*.I;

The BLISS compiler detects this error and reports the warning
shown in the following segment from the output listing:
0014 2
RESULT = .REULT*.I;
WARN#OOO
. . . . . . . . . . . . . . . . . 1 Ll:0014
Undeclared name:
REULT

3-22

message

COMPILER OUTPUT
The message is not fatal because the compiler can declare the
undeclared name REULT as EXTERNAL and continue processing without
omitting the compilation of any source.
Consider a different kind of coding error, as follows:
ROUTINE RFACT (N

The BLISS compiler detects this error and reports the
in the following segment from the output listing:

messages

given

0013 2
INCR I FROM 2 TO .NDO
....•.......•........ 1
Ll:0013
WARN#OOO
Undeclared name: NDO
0014 2
RESULT = .REULT*.Ii
........ 1 Ll:0014
WARN#066
Two consecutive operands with no intervening operator.
A DO has been inserted
WARN#OOO
. . . . . . . . . . . . . . . . . 1 Ll: 0014
Undeclared name: REULT
0015 2
. RESULT
0016 1
end;
0017 1
0018 1
ROUTINE RFACT (N =
2 •..••• 3 .•.•••••. 1
ERR #071
Ll:0018 L2:0018 L3:0016
Missing comma or closing bracket in formal parameter list for RFACT
The incorrect delimiter was "="
Omitting the blank between the name N and the keyword DO caused
another warning error, while omitting the close parenthesis (that is,
(N =) caused one fatal error. With the absence of a blank separator,
the compiler sees NDO and RESULT as two consecutive operands with no
intervening operator and inserts a DO.
However,
when the compiler
fails to find the close parenthesis, it cannot make syntactic sense of
the linesj therefore, it reports a fatal error message and suppresses
the production of an object file.
Note that although the compiler continues to check the syntax of the
remainder of the module, some text may remain unscanned. Also, the
scan sometimes causes genuine errors to be missed or spurious errors
to be reported. A module cannot be assumed to be fully checked by the
compiler until all error messages are eliminated.
The BLISS compiler supplies a great deal of information in its error
messages.
Each error message occupies two lines. The first line
classifies and pinpoints the error, and the second line gives a short
description of the error.
For example, consider the following error
message from the above example:
0013 2
INCR I FROM 2 TO .NDO
. . . . . . . . . . . . . . . . . . . . . 1 Ll:0013
WARN#OOO
Undeclared name: NDO
The first line classifies the error as a nonfatal by the string WARN
and gives the error number 000, followed by a pointer to the place in
the input line at which the error was detected, and a line indicator.
The second line describes the error.
The first line of an error message lines up with the input column at
which the compiler detected the error.
Under the preface for the
input line, the error message has a preface part that gives the type
of error (warning or fatal) and the error number (refer to Appendix
E). Under the text part of the input line, the error message can have

3-23

COMPILER OUTPUT
up to three pointers and three line indicators.
The pointers are
numbered from 1 to 3 and the meaning associated with each of the
pointers is given in the following list:
Pointer

Meaning

Indicates the point in the input text
error was detected

Indicates the beginning of the current control scope

Indicates the end of the last control scope that was
successfully closed prior to the detection of the
error

which

the

The line indicators are closely related to the pointers in meaning,
but whereas the pointers indicate a position within a line, the line
indicators indicate a line within the program, as follows:
Line Indicator

Meaning

Ll:nnnn

Indicates the line nnnn in the
error was detected

L2:nnnn

Indicates the line nnnn at which the current
scope begins

control

L3:nnnn

Indicates the line nnnn at which
scope was successfully closed

control

input

the

which

last

the

Line indicators are usually not too informative when the error is
confined within a program line, as in the examples given above, but
they are very useful for errors that span several lines.
For example,
consider the full source listing for the module TESTFACT given in
Figure 3-9.
This version of TESTFACT includes the coding error
illustrated in the above examples.
The error message at the end of
the program identifies with line indicators the point at which the
error was detected
(line 0032), the line at which the control scope
began (line 0013), and the line at which the control scope was closed
(line 0032).
With the information provided by the line indicators for error message
#012,
the source of the error is identified as the typing error in
line 0013.

3-24

COMPILER OUTPUT

(header)
0001 0
MODULE TESTFACT (MAIN
MAINPROG)
BEGIN
0002 0
WARN#048
1 Ll:0002
Syntax error in module head
0003 1
0004 1
OWN
A,
0005 1
0006 1
B;
0007 1
ROUTINE IFACT (N)
0008 1
0009 2
BEGIN
0010 2
LOCAL
0011 2
RESULT;
RESULT = 1;
0012 2
INCR I FROM 2 TO .NDO
0013 2
. . . . . . . . . . . . . . . . . . . . . 1 Ll:0013
WARN#OOO
Undeclared name:
NDO
0014 2
RESULT = .REULT*.I;
WARN#066
........ 1 Ll:0014
Two consecutive ,operands with no intervening operator. A "DO" has been inserted
WARN#OOO
.! ............... 1 Ll:0014
Undeclared name:
REULT
0015 2
. RESULT
0016 1
END;
0017 1
0018 1
ROUTINE RFACT (N =
ERR #071
2 ...... 3 . . . . . . . . . 1 Ll:0018 L2:0018 L3:0016
Missing comma or closing bracket in formal parameter list for RFACT
The incorrect delimiter was "="
0019 1
IF .N GTR 1
0020 1
THEN
0021 1
. N * RFACT ( . N - 1)
0022 1
ELSE
0023 1
1;
0024 1
0025 1
ROUTINE MAINPROG : NOVALUE
0026 2
BEGIN
0027 2
A = IFACT(5);
0028 2
B = RFACT(5);
0029 1
END;
0030 1
0031 1
END
0032 0
ELUDOM
Information:
o
Warnings:
4
Errors:
1

Figure 3-9: Error Messages in Source Listing Example

3-25

CHAPTER 4
LINKING, EXECUTING, AND DEBUGGING

This chapter describes the
debugging a BLISS program.

4.1

process

linking,

executing,

and

LINKING

Before you can execute your program, you must link the various pieces
of it together to form an executable image.
The linking process makes
the connection between external variables and names referenced in one
module and global variables defined in another module.
To invoke LINK, use the following command:
=>20
=>10

@LINK
.R LINK

LINK builds an executable image of your program.
The /GO switch
causes LINK to terminate.
To create a file from the image, issue the
SAVE or NSAVE command as follows:
=>20
=>10

@SAVE ALPHA
.NSAVE ALPHA

In both cases a
single image file
(ALPHA.EXE)
is saved.
(Other
versions of SAVE are available on TOPS-IO.
Consult the DECsystem-lO
Operating System Commands Manual for details.)
The following command causes ALPHA to be executed:
=>20
=>10

@RUN ALPHA
.RUN ALPHA

Some examples of linking are:
•

To link a single module, use the following commands:
*ALPHA
*/GO
In response to this
command,
the linker reads the
module in ALPHA.REL and creates the executable image.

•

To link the modules ALPHA, BETA, and GAMMA, use the
commands:
*ALPHA
*BETA
*GAMMA
*/GO

4-1

object

following

LINKING,

EXECUTING~

AND DEBUGGING

In response to this command, the linker combines the object
module in the file ALPHA.REL with the object module in the
file BETA.REL and the object module in the file GAMMA.REL to
produce a single executable image.
Linking a program compiled for extended addressing requires special
coding considerations and link commands.
Due to linker restrictions,
the compiler generates PSECTED code for all programs using the
extended addressing option (/EXTENDED). Such programs are then linked
into a specified nonzero section; however,
if the compiled program
uses /EXTENDED:SECTION-INDEPENDENT code, which allows loading into any
section, section zero must be specified at link time (refer to Section
6.4 for examples).
The default PSECTS generated are:
$OWN$,
$GLOBAL$,
$CODE$, the origins of which are set at link time.

$PLIT$,

The following example shows how a program using the
addressing option is linked and loaded into section one.

and

extended

@LINK
*ALPHA/SAV
*/SET:$OWN$:1200000
*/SET:$GLOBAL$:1300000
*/SET:$PLIT$:1400000
*/SET:$CODE$:1500000
*/SYMSEG:PSECT:$OWN$/PVBLOCK:PSECT:$CODE$
* ALPHA
*/GO
Note that when an extended addressing program is loaded, the placement
of the program's data vector (PVBLOCK) and symbol table (SYMSEG) must
be specified.
The link operation is described "in detail in the LINK-IO Programmer IS
Reference Manual and the DECSYSTEM-20 LINK Reference Manual.

4.1.1

Syntax

The following syntax for linking a BLISS program works under both
TOPS-IO and TOPS-20,
and is sufficient for a simple BLISS program.
The full description of LINK commands can be found in the appropriate
link manual.
link-command

test-:-line }
{ nothlng

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

----------------------------------.---------

test-line

/TEST

object-line

object-spec

exit-line

/GO

A carriage return is used to terminate
and exit-line.

4.1.2

object-line ... exit-line

each

test-line,

object-line,

Defaults

If a file type is not included in the object-spec, the file type
is assumed.

4-2

.REL

LINKING, EXECUTING, AND DEBUGGING
4.1.3

Semantics

LINK reads the object modules contained in each object file named in
the link command to create a linked, executable image.
The name of
the executable image is specified in the SAVE command (see Section
4.1) .
There are a number of minor differences between LINK under TOPS-IO and
TOPS-20.
Under TOPS-lO, /TEST causes DDT to be loaded at the end of
the program's low segment, while under TOPS-20, DDT gets "mapped" at
page 770.
Under TOPS-IO,
a run-time symbol table is omitted by
default:, unless /TEST is specified, while under TOPS-20,
symbols are
included for all nonoverlayed images, unless /NOLOCAL is specified.
The /MAXCOR and /SAVE switches are TOPS-IO specific.
Under TOPS-20, when accessing files from a directory other than that
currently connected to,
either use a programmer-project number or
define a logical name for the new directory.
The TRANSLATE and DEFINE
commands can be used for this purpose.
NOTE
For additional information related to linking BLISS-36
modules with modules written in assembly language or
BLISS-IO, refer to Appendices G and H.

4.2

EXECUTING

To run your program, use the executable image produced as a result
the link operation, in a RUN command, as shown above.
Your program, ALPHA, then executes.
Any input or output
it
program takes place.
If your program is correct,
completion and returns to the command processor.
The
processor then prompts for another command.

4.3

in your
runs to
command

DEBUGGING

If your program has problems or if you want to examine some data
within your program, you can use the SIX12 debugger.
Using the switch
/DEBUG in the compilation operation tells LINK to load SIX12 and to
pass the symbol tables from the REL files to the image file.
The
executable image formed as a result contains SIX12, and when the image
is executed, control first goes to SIX12 instead of your program. You
can then examine and deposit values in storage, set breakpoints,
call
routines,
or do any of a number of other debug or test operations.
The SIX12 debugger is described basically in SIX12.HLP (a help file
distributed with the compiler), while a more comprehensive description
can be found in the SIX12.DOC file, distributed with the compiler.

4.3.1

Debug Example

As an example of using the debug facility, consider the testing of the
program MYPROG.
Errors detected in MYPROG in Section 3 are corrected,
and then MYPROG is compiled, linked with SIX12, and run.

4-3

LINKING, EXECUTING, AND DEBUGGING
Assume that MYPROG has been
switch.

successfully

compiled

with

the

/DEBUG

@LINK
*/TEST
*MYFROG
*/GO
EXIT
@SAVE MYPROG
MYPROG SAVED
@RUN MYPROG
SIX12 V8-4 (TOPS-20 I/O) FOR BLISS-36
&IFACT(S)
170

.STACK + 26

170

.STACK + 26

&RFACT(S)

&GO
@
In the above example, the first step is to invoke LINK, which prompts
with the asterisk (*).
Next,
the /TEST switch is specified to
indicate that a debugging version of a program is to be built.
Then
follows a sequence of object files that are to be included in the
build.
In this case there is only one: MYPROG.
The final command
given to LINK is /GO, which causes LINK to terminate and leave the
image file in memory. The user saves MYPROG with the SAVE command and
executes it with the RUN command.
In this case, SIX12 gets control when MYPROG is run, and informs you
as to which version of SIX12 this is, and whether TOPS-IO or TOPS'-20
I/O is being used. SIX12 prompts with an ampersand (&). The user has
requested that SIX12 call routine IFACT and routine RFACT with actual
parameter 5 in each case.
In each case, the resultant value is 120
(170 octal).
The default radix that SIX12 uses is octal.
To
integer to SIX12, precede it by a hash mark (#).

4.3.2

specify

decimal

Other SIX12 Commands

Some commonly used SIX12 commands are now described. The basic syntax
of SIX12 is similar to BLISS. Therefore, to examine GLOBAL or OWN
data (for example, A) type:

To examine the current stack of routine invocations, type:
&CALLS
To change the value of an OWN or GLOBAL variable A, type:
&A=new-va1ue
To set a breakpoint on entry to a routine, type:
&BREAK routine-name

4-4

LINKING, EXECUTING, AND DEBUGGING
To set a breakpoint on routine exit, type:
&ABREAK routine-name
The commands DBREAK and
respectively.

DABREAK

clear

the

above

two

breakpoints,

To begin execution, type:
&00

As the above example indicates, to call a routine, type:
&routine-name(actual-parameter-list)
To invoke DDT, type:
&DDT
To return from DDT to SIXI2, type the following to DDT:
&SIXRET$X

(where $ is altmode or escape)

To examine the n'th actual parameter
stopped at its entry or exit, type:

the

current

routine

when

&n%A
SIXl2 prints out the values of the actual parameters when
command is given or when a breakpoint has been reached.

4-5

the

CALLS

CHAPTER 5
MACHINE-SPECIFIC FUNCTIONS

Machine-specific functions allow you to perform specialized operations
within the BLISS language.
A machine-specific function call is
similar to a BLISS routine call.
It requires parameters and returns a
value.
The compilation of a machine-specific function results in
the
generation of some inline code, often a single instruction, rather
than a call to an external routine.
The one exception to this is the
Convert Double to Floating (CVTDF) function.
The compiler attempts to optimize the code it produces for a
machine-specific
function
call by choosing the most efficient
instruction sequence.
In some cases, optimization procedures generate
a different machine instruction from the one specified in the call.
Machine-specific functions
in BLISS-36 are
divided
into
four
categories,
as illustrated in Table 5-1. A separate description of
each function appears below.
For a more detailed discussion,
consult
the DECsystem-10/DECSYSTEM-20 Hardware Reference Manual.

5.1

GENERAL CONVENTIONS

The definitions of these functions
require addresses,
values,
or
register names as parameters, even though register names do not have
values in BLISS-36.
All expressions can be run-time computable expressions,
specified otherwise in the descriptions that follow.

unless

In each description, the calling sequence is given first, followed by
a description of the parameters.
The actual semantics of the function
are specified under "Return Value."

5.1.1

Machine Code Insertion Functions

Machine code insertion functions provide a means to specify a
particular -10/-20 instruction to be executed.
These functions are
intended for highly specialized applications which cannot be otherwise
directly specified in the language.
The user of these functions is
cautioned that no extensive analysis of the instruction is performed
by the compiler; it is possible for the user to specify an instruction
that interferes with compiler-generated instructions and results in an
incorrect program.
Therefore,
avoid the use of these functions to
perform an operation that can be expressed more directly in the
language.
In particular,
user manipulation of the stack pointer is
very risky and requires extreme care.

5-1

MACHINE-SPECIFIC FUNCTIONS
Table 5-1: Machine-Specific Functions
Logical Functions
ASH
FIRSTONE
LSH
ROT

Arithmetically shift a value
Find the leftmost non-zero list in a value
Logically shift a value
Rotate a given value

Byte Manipulation Functions
COPYII
COPYIN
COPYNI
COPYNN
DPB
INCP
LDB
POINT
REPLACEI
REPLACEN
SCANI
SCANN

Increment both source and destination byte pointers
and copy a byte
Increment a source byte pointer and copy a byte
Increment a destination byte pointer and copy a byte
Copy a byte
Deposit a byte
Increment a byte pointer
Load a byte
Build a -10/-20 byte pointer
Increment a byte pointer and store a byte
Store a byte given a byte pointer
Increment a byte pointer and fetch a byte
Fetch a byte given a byte pointer

Arithmetic Functions
ADDD
ADDF
ADDG
DIVD
DIVF
DIVG
MULD
MULF
MULG
SUBD
SUBF
SUBG

Add double operands
Add floating operands
Add float-G operands
Divide double ogerands
Divide floating operands
Divide float-G operands
Multiply double operands
Multiply floating operands
Multiply float-G operands
Subtract double operands
Subtract floating operands
Subtract float-G operands

Arithmetic Comparison Functions
CMPD
CMPF
CMPG

Compare double operands
Compare floating operands
Compare float-G operands

Arithmetic Conversion Functions
CVTDF
CVTDI
CVTFD
CVTFG
CVTFI
CVTGF
CVTGI
CVTID
CVTIG
CVTIF

Convert double to floating
Convert double to integer
Convert floating to double
Convert floating to float-G
Convert floating to integer
Convert float-G to floating
Convert float-G to integer
Convert integer to double
Convert integer to float-G
Convert integer to floating
(continued on next page)

5-2

MACHINE-SPECIFIC FUNCTIONS
Table 5-1 (Cont.): Machine-Specific Functions
Machine Code Insertion Functions
MACHOP
MACHSKIP

Execute a -10/-20 instruction
Execute a -10/-20 instruction and
skip occurred

record

whether

System Interface Functions
JSYS
UUO

5.1.2

Perform a TOPS-20 Monitor call
Perform a TOPS-lO Monitor call

Logical Functions

If the arguments to the functions defined in this section are
compile-time constant expressions, the result is also a compile-time
constant expression.

5.1.3

Arithmetic Functions

The arithmetic functions provide single-,
double-,
and extended
double-precision floating-point operations.
Note that where the
parameters for these functions require the addresses of operands,
regist,ers may only be used for single-precision float operands (ADDF,
SUBF, MULF, CMPF, CVTFx, and CVTxF) and integer operands
(CVTIx and
CVTxI) .

5.1.4

System Interface Functions

BLISS provides a way to request that TOPS-lO and TOPS-20 system
services be performed.
For TOPS-lO, the machine-specific function
used t,o communicate this request for service is UUO.
For native mode
TOPS-20
programs,
the JSYS linkage-type should be used.
For
compatibility mode programs on TOPS-20,
that is,
TOPS-lO programs
running with the PAl050 Emulator, UUO is used.
Using both JSYS and UUO together is not recommended;
the TOPS-IO
Emulator PAI050 is not guaranteed to handle UUOs correctly while the
program contains JSYS requests.
An example of using JSYS and UUO can be found in section 9.6.
Information on specific system services can be found in the TOPS-20
Monitor Calls Reference Manual and the DECsystem-lO Monitor Calls
Manual.

5 .2

A,DDD (ADD DOUBLE OPERANDS)

Calling Sequence:
ADDD (SRCIA, SRC2A, DSTA)

5-3

MACHINE-SPECIFIC FUNCTIONS
Parameters:
SRClA

Address of a double-precision floating-point value
used as the addend

SRC2A

Address of a double-precision floating-point value
used as the augend

DSTA

Address where the sum of operand 1 and
is stored

operand

Return Value:
NOVALUE

5.3

ADDF (ADD FLOATING OPERANDS)

Calling Sequence:
ADDF (SRClA, SRC2A, DSTA)
Parameters:
SRClA

Address of a single-precision floating-point value
used as the addend

SRC2A

Address of a single-precision floating-point value
used as the augend

DSTA

Address where the sum of operand 1 and
is stored

operand

Return Value:
NOVALUE

5.4

ADDG (ADD FLOAT-G OPERANDS)

Calling Sequence:
ADDG (SRClA, SRC2A, DSTA)
Parameters:
SRClA

Address of an extended double-precision
point value used as the addend

floating

SRC2A

Address of an extended double-precision
point value used as the augend

floating

DSTA

Address where the sum of operand 1 and
is stored

Return Value:
NOVALUE

5-4

operand

MACHINE-SPECIFIC FUNCTIONS
5.5

ASH (ARITHMETIC SHIFT)

Calling Sequence:
ASH(EXP,CEXP)
Parameters:
EXP

Value to be arithmetically shifted

CEXP

Number of bit positions to be shifted

Return Value:
If EXP is greater than zero, EXP is shifted left by CEXP bit
positions;
otherwise,
EXP is shifted right CEXP bits.
During a
right shift, bits shifted out of bit 1 are replaced with a copy
of the sign bit.

5.6

CMPD (COMPARE DOUBLE OPERANDS)

Calling Sequence:
CMPD (SRC1A, SRC2A)
Parameters:
SRC1A

Address of a double-precision floating-point value
for comparison

SRC2A

Address of a double-precision floating-point value
for comparision

Return Value:

5.7

-1

SRC1A less than SRC2A

SRC1A equal to SRC2A

SRC1A greater than SRC2A

CMPF (COMPARE FLOATING OPERANDS)

Calling Sequence:
CMPF (SRC1A, SRC2A)
Parameters:
SRC1A

Address of a single-precision floating-point value
for comparison

SRC2A

Address of a single-precision floating-point value
for comparison

Return Value:
-1

SRClA less than SRC2A

SRClA equal to SRC2A

SRClA greater than SRC2A
5-5

MACHINE-SPECIFIC FUNCTIONS
5.8

CMPG (COMPARE FLOAT-G OPERANDS)

Calling Sequence:
CMPG (SRCIA, SRC2A)
Parameters:
SRCIA

Address
of
an
extended
double-precision
floating-point value for comparison

SRC2A

Address
of
an
extended
double-precision
floating-point value for comparison

Return Value:

5.9

-1

SRCIA less than SRC2A

SRCIA equal to SRC2A

SRCIA greater than SRC2A

COPYII, COPYIN, COPYNI, AND COPYNN (COPY A BYTE)

Calling Sequence:
COPYII(SAPI, DAPI)
COPYIN(SAPI, DAP)
COPYNI(SAP, DAPI)
COPYNN(SAP, DAP)
Parameters:
SAP

Address of a source byte pointer

SAPI

Address of a source byte-pointer to be incremented

DAP

Address of a destination byte pointer

DAPI

Address of
incremented

destination

byte

pointer

Return Value:
COPYNN copies the field defined by the first parameter int.o the
field defined by the second parameter.
COPYNI increments the
second byte pointer and proceeds as
for
COPYNN.
COPYIN
increments the first byte pointer and proceeds as for COPYNN.
COPYII increments both byte pointers and proceeds as for COPYNN.
In all cases the value returned is the value fetched.

5.10

CVTDF (CONVERT DOUBLE TO FLOATING)

Calling Sequence:
CVTDF(SRCA, DSTA)

5-6

MACHINE-SPECIFIC FUNCTIONS
Parameters:
SRCA

Address of a double-precision floating-point value
for conversion

DSTA

Address where the single-precision
conversion is stored

floating-point

Return Value:
NOVALUE

5.11

CVTDI (CONVERT DOUBLE TO INTEGER)

Calling Sequence:
CVTDI (SRCA, DSTA)
Parameters:
SRCA

Address of a double-precision floating-point value
for conversion

DSTA

Address where the integer conversion is stored

Return Value:

5.12

No integer overflow

Integer overflow

CVTFD (CONVERT FLOATING TO DOUBLE)

Calling Sequence:
CVTFD (SRCA, DSTA)
Parameters:
SRCA

Address of a single-precision floating-point value
for conversion

DSTA

Address where the double-precision
conversion is stored

Return Value:
NOVALUE

5.13

CVTFG (CONVERT FLOATING TO FLOAT-G)

Calling Sequence:
CVTFG (SRCA, DSTA)

5-7

floating-point

MACHINE-SPECIFIC FUNCTIONS
Parameters:
SRCA

Address of a single-precision floating-point value
for conversion

DSTA

Address where
the
extended
double-precision
floating-point conversion is stored

Return Value:
NOVALUE

5.14

CVTFI (CONVERT FLOATING TO INTEGER)

Calling Sequence:
CVTFI (SRCA, DSTA)
Parameters:
SRCA

Address of a single-precision floating-point value
for conversion

DSTA

Address where the integer conversion is stored

Return Value:
1

No integer overflow

Integer overflow

5.15

CVTGF (CONVERT FLOAT-G TO FLOATING)

Calling Sequence:
CVTGF (SRCA, DSTA)
Parameters:
SRCA

Address
of
an
extended
double-precision
floating-point value for conversion

DSTA

Address where the single-precision
conversion is stored

Return Value:

5.16

No integer overflow

Integer overflow

CVTGI (CONVERT FLOAT-G TO INTEGER)

Calling Sequence:
CVTGI (SRCA, DSTA)

5-8

floating-point

MACHINE-SPECIFIC FUNCTIONS
Parameters:
SRCA

Address
of
an
extended
double-precision
floating-point value for conversion

DSTA

Address where the integer conversion is stored

Return Value:

5.17

No integer overflow

Integer overflow

CVTID (CONVERT INTEGER TO DOUBLE)

Calling Sequence:
CVTID (SRCA, DSTA)
Parameters:
SRCA

Address of an integer value for conversion

DSTA

Address where the double-precision
conversion is stored

floating-point

Return Value:

NOVALUE

5.18

CVTIF (CONVERT INTEGER TO FLOATING)

Calling Sequence:
CVTIF (SRCA, DSTA)
Parameters:
SRCA

Address of an integer value for conversion

DSTA

Address where the single-precision
conversion is stored

floating-point

Return Value:

NOVALUE

5.19

CVTIG (CONVERT INTEGER TO FLOAT-G)

Calling Sequence:
CVTIG (SRCA, DSTA)
Parameters:
SRCA

Address of an integer value for conversion

DSTA

Address where
the
extended
double-precision
floating-point conversion is stored

5-9

MACHINE-SPECIFIC FUNCTIONS
Return Value:
NOVALUE

5.20

DIVD (DIVIDE DOUBLE OPERANDS)

Calling Sequence:
DIVD (DIVSR, DIVID, QUOT)
Parameters:
DIVSR

Address of a double-precision floating-point value
used as the divisor

DIVID

Address of a double-precision floating-point value
used as the dividend

QUOT

Address where the quotient is stored

Return Value:
NOVALUE

5.21

DIVF (DIVIDE FLOATING OPERANDS)

Calling Sequence:
DIVF (DIVSR, DIVID, QUOT)
Parameters:
DIVSR

Address of a single-precision floating-point value
used as the divisor

DIVID

Address of a single-precision floating-point value
used as the dividend

QUOT

Address where the quotient is stored

Return Value:
NOVALUE

5.22

DIVG (DIVIDE FLOAT-G OPERANDS)

Calling Sequence:
DIVG (DIVSR, DIVID, QUOT)
Parameters:
DIVSR

Address
of
an
extended
double-precision
floating-point value used as the divisor

DIVID

Address
of an
extended
double-precision
floating-point value used as the dividend

QUOT

Address where the quotient is stored

5-10

MACHINE-SPECIFIC FUNCTIONS
Return Value:
NOVALUE

5.23

FIRSTONE (FIND FIRST BIT)

Calling Sequence:
FIRSTONE(EXP)
Parameters:
EXP

The value to be examined

Return Value:
-1 if EXP is equal to zero; otherwise, the number of
zero bits to the left of the first one bit in EXP.

5.24

high-order

INCP (INCREMENT A BYTE POINTER)

Calling Sequence:
INCP(AP)
Parameters:
AP

Address of a byte pointer

Return Value:
Increment the byte pointer at location AP.

5.25

Return O.

JSYS (INVOKE A TOPS-20 SYSTEM SERVICE)

Calling Sequence:
J'SYS (skips, number { , regname ,

... } )

Parameters:
skips

A compile-time constant expression whose value is
in
the range -1 to 2.
The value of this
expression indicates the manner in which control
may return following the JSYS instruction.

number

The low-order 18 bits of this value become the
effective address of the JSYS instruction (must
not be a register name nor a %REF function).

regname

The name of a register. Any number of register
names
(or none) may be given as the third through
last parameters.

A JSYS instruction (opcode 104) with the specified
(and a zero accumulator field) is executed.

effective

address

The value of the "skips" parameter must agree with the characteristics
of the JSYS which is executed.
It defines the manner in which control
may return following the JSYS, and the value of the JSYS function.
5-11

MACHINE-SPECIFIC FUNCTIONS
If the JSYS is one which has skip returns, the skips parameter must be
specified as 1 or 2, depending upon the number of alternate returns.
If the JSYS is one which has a single return, the skips parameter must
be specified as -lor O.
If you desire a software interrupt on the
occurrence of a JSYS error, the value 0 is selected.
If you desire to
handle the occurrence of a JSYS error at the call site by using the
ERJMP facility, the value -1 is selected.
Note that the GOTO return possible by specifying a
nonzero reparse
dispatch address to the COMND JSYS is not supported by the JSYS
machine- specific function.
Detailed specifications of the value of the IIskipsll parameter follow:
SKIPS Value

Interpretation

-1

Control always returns to the calling location plus
1.
This
location contains an ERJMP instruction.
The value of the function is
zero if an error
occurred during execution of the JSYS, and 1 if no
error occurred.

Control always returns to the calling location plus
1.
(This
location will not contain an ERJMP
instruction.) The value of the function is zero.

Control returns either to the calling location plus
1 or to the calling location plus 2.
The value of
the function is zero if control returns to the
calling location plus 1, and 1 if control returns to
the calling location plus 2.

As for 1, except that control may also return to the
calling location plus 3, in which case the value of
the function is 2.

The usage of accumulators by the JSYS to receive parameters and to
return values is specified by the list of IIregnamell parameters.
Each
parameter is the name of a
register data segment which has been
allocated by the programmer to a specific machine register by means of
a declaration similar to the following:
REGISTER
AC1=1;
Each accumulator which may be referenced by the JSYS,
either as an
input or as an output, must be identified by this means.
The compiler
assumes that accumulators which are not mentioned in this list are not
used or changed by the JSYS.
The programmer must initialize the input parameter accumulators and
access the values returned by including appropriate assignments to and
from the register data segments identified in the register name list
before and after the JSYS call.
Note that it is important to minimize the scope of a specific register
declaration to ensure that allocation of registers is possible.

5-12

MACHINE-SPECIFIC FUNCTIONS
5.26

LSH (LOGICAL SHIFT)

Calling Sequence:
LSH(EXP, CEXP}
Parameters:
EXP

Value to be logically shifted

CEXP

Number of bit positions to be shifted

Return Value:
EXP is logically shifted by CEXP bit positions.
If CEXP is
nonnegative,
shift is to the left; otherwise, shift is to the
right.
Bits shifted out of EXP are replaced with zero bits.

5.27

MACHOP AND MACHSKIP (EMIT AN INSTRUCTION)

Calling Sequence:
MACHOP(OP, AC, Y, X, I}
MACHSKIP(OP, AC, Y, X, I}
Parameters:
OP

Low nine bits become the operation code of the
compile-time constant
instruction;
must be a
expression.

Register name or an expression.
If an expression,
the low-order four bits becomes the accumulator
(A)
field of the instruction;
otherwise,
the
register number corresponding to the register name
must be a compile-time constant expression.

The low-order 18 bits become the address (y) field
of the instruction

The low-order four bits
field of the instruction

The low-order bit becomes the indirect
(I)
field
of
the
instruction;
must be a
compile-time
constant expression.

becomes

the

index

(X)

By default, any omitted parameter defaults to zero.
Return Value:
For MACHOP, the value returned is the contents of the register
OP must
specified by AC after the execution of the instruction.
not specify an instruction that can skip.
For MACHSKIP, the value returned is 1 if the
and 0 otherwise.

5-13

instruction

skips,

MACHINE-SPECIFIC FUNCTIONS
5.28

MULD (MULTIPLY DOUBLE OPERANDS)

Calling Sequence:
MULD (SRCIA, SRC2A, DSTA)
Parameters:
SRCIA

Address of a double-precision floating-point value
used as the multiplier

SRC2A

Address of a double-precision floating-point value
used as the multiplicand

DSTA

Address where the product of operand 1 and operand
2 is stored

Return Value:
NOVALUE

5.29

MULF (MULTIPLY FLOATING OPERANDS)

Calling Sequence:
MULF (SRCIA, SRC2A, DSTA)
Parameters:
SRCIA

Address of a single-precision floating-point value
used as the multiplier

SRC2A

Address of a single-precision floating-point value
used as the multiplicand

DSTA

Address where the product of operand 1 and operand
2 is stored

Return Value:
NOVALUE

5.30

MULG (MULTIPLY FLOAT-G OPERANDS)

Calling Sequence:
MULG (SRCIA, SRC2A, DSTA)
Parameters:
SRCIA

Address
of
an
extended
double-precision
floating-point value used as the multiplier

SRC2A

Address
of
an
extended
double-precision
floating-point value used as the multiplicand

DSTA

Address where the product of operand 1 and operand
2 is stored

Return Value:
NOVALUE
5-14

MACHINE-SPECIFIC FUNCTIONS
5.31

POINT (BUILD A BYTE POINTER)

Calling Sequence:
POINT(Y, P, S, X, I)
Parameters:
y

The low-order 18 bits of Y become the address
(Y)
field of the byte pointer.
There is no default.

The low-order six bits of P become the position
(p) field of the byte pointer.
The default is o.

The low-order six bits become the size field
of the byte pointer.
The default is 36.

The low-order four bits become the index (X) field
of the byte pointer.
The default is o.

The low-order bit becomes the indirect
of the byte pointer.
The default is o.

(I)

(S)

field

Return Value:
If Y is a link-time constant expression, and P, S, X, and I
are
compile-time
constant
expressions,
the return value is a
link-time constant expression.

5.32

REPLACEI AND REPLACEN (STORE A BYTE)

Calling Sequence:
REPLACEI(AP, EXP)
REPLACEN(AP, EXP)
Parameters:
AP

Address of a byte pointer

EXP

Value to be stored

Return Value:
REPLACEI
increments the byte pointer at address AP.
Both
REPLACEN and REPLACEI then store the value EXP in the field
defined by the byte pointer.
The value returned is EXP.

5.33

ROT (ROTATE A VALUE)

Calling Sequence:
ROT(EXP, CEXP)
Parameters:
EXP

Value to be rotated

CEXP

Number of bits positions to be rotated

5-15

MACHINE-SPECIFIC FUNCTIONS
Return Value:
EXP rotated by CEXP bit positions.
rotate left; otherwise, rotate right.

5.34

CEXP

nonnegative,

SCANN AND SCANI (FETCH A BYTE)

Calling Sequence:
SCANN(AP)
SCANI(AP)
Parameters:
AP

Address of a byte pointer

Return Value:
SCANI increments the byte pointer at address AP.
Both SCANN and
SCANI then fetch the field defined by the byte pointer and use
that as the returned value.

5.35

SUBD (SUBTRACT DOUBLE OPERANDS)

Calling Sequence:
SUBD (SRClA, SRC2A, DSTA)
Parameters:
SRClA

Address of a double-precision floating-point value
used as the subtrahend

SRC2A

Address of a double-precision floating-point value
used as the minuend

DSTA

Address where the difference between operand land
operand 2 is stored

Return Value:
NOVALUE

5.36

SUBF (SUBTRACT FLOATING OPERANDS)

Calling Sequence:
SUBF (SRClA, SRC2A, DSTA)
Parameters:
SRClA

Address of a single-precision floating-point value
used as the subtrahend

SRC2A

Address of a single-precision floating-point value
used as the minuend

DSTA

Address where the difference between operand 1 and
operand 2 is stored

5-16

MACHINE-SPECIFIC FUNCTIONS
Return Value:
NOVALUE

5.37

SUBG (SUBTRACT FLOAT-GOPE~DS)

Calling Sequence:
SUBG (SRClA, SRC2A, DSTA)
Parameters:
SRCIA

Address
of
an
extended
double-precision
floating-point value used as the subtrahend

SRC2A

Address
of
an
extended
double-precision
floating-point value used as the minuend

DSTA

Address where the difference between operand 1 and
operand 2 is stored

Return Value:
NOVALUE

5.38

UUO (INVOKE A TOPS-IO SYSTEM SERVICE)

Calling Sequence:
UUO (skips, opcode, acexp, effexp )
Parameters:
skips

A compile-time constant expression whose value is
in the range 0 to 1.
The value of this expression
indicates the manner in which control may return
following the UUO instruction.

opcode

The low-order nine bits of this value become the
operation
code of the generated instruction.
(Must not be a register name nor a %REF function.)

acexp

If this parameter is a register name,
the number
of the register becomes the accumulator field of
the
generated
instruction.
Otherwise,
the
low-order four bits of this value become the
accumulator field of the generated instruction
(must not be a %REF function).

effexp

If this parameter is a register name,
the number
of the register becomes the effective address of
the
generated
instruction.
Otherwise,
the
low-order
18 bits of this value become the
effective address of the generated instruction
(must not be a %REF function).

An instruction with the indicated operation code,
and effective address is executed.

5-17

accumulator

field,

MACHINE-SPECIFIC FUNCTIONS
Note that the INIT UUO, which has inline parameters, is not supported
by the UUO machine-specific function.
The OPEN UUO may be used
instead.
The value of the skips parameter must agree with the characteristics
of the instruction or UUO which is executed.
It defines the manner in
which control may return following the instruction, and the value of
the UUO function, according to the following table:
SKIPS Value

Interpretation

Control always returns to the instruction
The value of the function is zero.

Control returns either to the instruction plus 1 or
to the instruction plus 2.
The value of the
function is zero if control
returns
to
the
instruction plus 1, and 1 if control returns to the
instruction plus 2.

5-18

plus

CHAPTER 6
PROGRAMMING CONSIDERATIONS

This chapter gives some practical help in writing BLISS programs.
First,
the usage differences between LIBRARY and REQUIRE files are
considered.
Then, some common BLISS programming errors are discussed.

6.1

LIBRARY AND REQUIRE USAGE DIFFERENCES

BLISS library files are used in a manner similar to that of required
files;
declarations that are common to more than one module are
centralized in a single file automatically incorporated into other
modules
during
compilation
by
means
of REQUIRE or LIBRARY
declarations.
Library files are more efficient for doing this
for two reasons.

than

required

files

First, with files invoked by REQUIRE declarations,
the compilation
cost of processing the source occurs every time the file is used in a
compilation. With library files, the major compilation cost occurs
once when the library is compiled, and a much smaller cost occurs each
time the library file is used in a compilation.
A library file
closely approximates the internal symbol table representation used by
the compiler; hence, costs of lexical processing (including scanning,
lexical-conditionals,
lexical-functions,
and macro expansions) and
declaration parsing and checking occur only during the
library
precompilation.
Second, with files invoked by REQUIRE declarations,
all declarations
contained in the file are incorporated into the compiler symbol table.
With library files, the compiler does not incorporate the declarations
into the normal symbol table unless and until the declaration is
actually needed.
Declarations of names that are not used do not fill
up the symbol table.
The difference in cost depends on many factors, including the size of
the library, the size of the module being compiled, and the percentage
and kind of declarations used from a
library.
Experimental results
indicate that compiler time and space requirements may typically be
improved by a factor of 4 by using library files
instead of source
files.
Library files and the same declarations used from source files
using
the REQUIRE declarations are similar.
However, the differences are:
•

Files invoked by REQUIRE declarations are source (text) files;
files
invoked by LIBRARY declarations must be special files
created by the compiler in a previous library precompilation.

•

Files invoked by REQUIRE declarations may contain any source
text that is valid when that source text is substituted for
6-1

PROGRAMMING CONSIDERATIONS
the
REQUIRE
declaration.
Files
invoked
by
LIBRARY
declarations must be compiled from sources that consist of a
sequence of (only) the following declarations:
BINDI
BUILTINI
COMPILETIME
EXTERNAL
EXTERNAL LITERAL
EXTERNAL ROUTINE
FIELD
KEYWORDMACRO
LIBRARY
LINKAGE
LITERAL
MACRO
REQUIRE
STRUCTURE
SWITCHES
UNDECLARE
•

SWITCHES declarations contained in files invoked by the
REQUIRE declaration may affect the module being compiled;
those contained in files used to produce library files affect
only
the library compilation.
Switch settings are not
incorporated into the compilation that uses the library file.

•

Files invoked by REQUIRE declarations may have effects that
are dependent on previous declarations and/or switch settings
in the module being compiled.
This can
occur
in
a
lexical-conditional
(%IF-%THEN-%ELSE-%FI) or macro expansion
that depends on the lexical functions %SWITCHES, %DECLARED, or
%VARIANT,
or on values of predeclared literals,
such as
%BPVAL.
Files invoked by LIBRARY declarations do not have
effects that are dependent on previous declarations or switch
settings, because SWITCHES declarations, REQUIRE declarations,
lexical conditionals or macro calls contained in sources used
to produce a library file are processed during the library
precompilation.

•

Appropriately written source files can be invoked by REQUIRE
declarations that exist in a module which may be compiled by
any BLISS compiler; however, Library files must only be
invoked by the same compiler that created the library file.

In compiling a module, identical effects are normally achieved by
using either a REQUIRE declaration to invoke the source files used to
create a library or by using a LIBRARY declaration to invoke the
library itself.
However, the differences presented above may lead to
problems that are difficult to identify. Therefore, for each set of
declarations, one form or the other should be used consistently.

6.2

FREQUENT BLISS CODING ERRORS

Certain user coding errors occur frequently, especially for new BLISS
users, when compiling and debugging a new module.
The following list
may be useful as a check list when you cannot seem to find the source
of a problem.

Some restrictions apply to these declarations.
6-2

PROGRAMMING CONSIDERATIONS
6.2.1

Missing Dots

The most frequent error is to forget a dot.
Except for the left side
of an assignment, the appearance of a data segment name without a
preceding fetch operator is the exception and usually a mistake.
For
example:
IF A THEN ...
should almost certainly be:
IF .A THEN ...

6.2.2

Valued and Nonvalued Routines

The BLISS compiler does not diagnose useless value expressions in
For example, in the following
contexts that do not use a value.
routine:
ROUTINE R(A): NOVALUE
BEGIN
RETURN 5;
END;
the apparent return value 5 is discarded since
NOVALUE attribute.

the

routine

has

the

However, in the following case:
ROUTINE S(B)
BEGIN
RETURN;
END;
a required RETURN value is missing; therefore,
an informational
message is issued indicating that a value expression is missing in a
context that implies a value.
(The compiler assumes a value of zero
for missing expressions.)

6.2.3

Semicolons and Values of Blocks

It is common to think of a semicolon as a terminator of an expression;
this is,
however,
untrue and can lead to errors.
In the following
example:
IF .A
'rHEN
X=.Y;
ELSE
X=-5;
the first semicolon terminates the initial IF-THEN and the
ELSE is in error.

subsequent

A more subtle error is to place a semicolon after the last expression
of a block when that expression is supposed to be the value of the
block.
(This is very similar to Section 6.2.2 above concerning valued
and nonvalued routines.)
6-3

PROGRAMMING CONSIDERATIONS
6.2.4

Complex Expressions Using AND, OR, and NOT

When you are writing complex tests involving the AND,
OR,
and NOT
operators,
it is easy to confuse the relative precedence of the
operators.
Explicit parentheses can, however, make your intent clear
to the compiler
(as well as to yourself and to other readers). For
example, instead of the following:
IF .X {EQL 0 AND .Y {OR NOT .J THEN ...
use:
IF {(.X (EQL 0) AND .Y) OR (NOT .J) THEN ...

6.2.5

Computed Routine Calls

When computing the address of a routine to be called,
enclose the
expression that computes the address in parentheses followed by the
parameters.
For example:
BEGIN
EXTERNAL ROUTINE
Ri

LOCAL
Li

= Ri

(.L)(O)
END
calls the routine at address R with a parameter of zero.

However:

.L(O)
calls the routine at address L (most likely an address on the stack)
and uses the returned value as the operand of the fetch.
Since there
is no code at address L, an illegal instruction exception is likely at
execution.
An alternative is to use a general routine call. Assuming the desired
you could write the
linkage is the default calling convention,
computed call as:
BLISS36C(.L,0)

6.2.6

Signed and Unsigned Fields

Be careful when using signed and unsigned fields that are smaller than
a
fullword.
Consistent use of the sign extension rules and of signed
versus unsigned operations is important.
For example,
in
the
following:
BEGIN
FIELD LOW9 = [O,O,9,OJi
OWN
X : BLOCK[IJ FIELD(LOW9)i
IF .X[LOW9J EQL -5
THEN
END
the expression .X[LOW9J EQL -5 is always false because the
value fetched from X is necessarily in the range 0 to 511.
6-4

(unsigned)

PROGRAMMING CONSIDERATIONS
6.2.7

Complex Macros

The BljISS macro facility has many capabilities but also has some very
subtle properties.
Most problems arise when features that have
side-effects on the compilation are used, such as:
•

Macro expansions that produce declarations
particularly other macro declarations

•

Use of compile-time names to control
%ASSIGN

•

Use of %QUOTE, %UNQUOTE, and %EXPAND

macro

any

kind,

expansions

using

Be particularly careful when trying to use these featuresi indeed, you
may not really need them in the first place.
(Refer to Section 6.3
for examples of advanced macro usage.)

6.2.8

Missing Code

You may discover that some of your program seems to be missing from
the compiled code.
Check the compiled code carefully to make sure
that it really is missing rather than cleverly optimized.
If code is
missing, most likely you have made a coding error. Many coding errors
tend t.o result in code that can be optimized.
For example, consider the following:
BEGIN
FIELD LOW9 = [0,9Ji
OWN
X : BLOCK[lJ FIELD(LOW9)i
IF .X[LOW9J EQL -5
THEN
X= 100
END
In the above example, the value of the test expression .X[LOW9J EQL -5
is always false.
(See Section 6.2.6 above concerning signed and
unsigned fields.) As a result, the compiler produces no code for the
following:
•

The test expression, and

•

The alternative, X = 100 (it can never be executed).

Consequently, the entire IF expression disappears from the compiled
code.
The problem is not erroneous compiler optimization, but a
missing extension expression in the field declaration of LOW9.
A similar error occurs if the fact is overlooked that TRUE/FALSE is
based on the value of the low bit of an expression.
Thus the
following fragment:
IF .X AND 2
THEN
y=O
ELSE
Y=l
always assigns the value "1" to Y because the low bit of
must always be zero (false).

6-5

".X

AND

PROGRAMMING CONSIDERATIONS
6.2.9

Conflicting Names

Be aware of both the length and content of user-defined symbolic
names.
BLISS can distinguish among ,symbols that differ in any of the
first
31
characters.
However,
linkers
currently
on
the
DECsystem-10/20 cannot distinguish beyond the sixth character.
For
this reason, any GLOBAL or EXTERNAL symbol should be unique within six
characters.
If a file is created for assembly outside of BLISS, all
symbols appearing within the file should be unique within six
characters or the /UNAMES switch should be specified. This includes
symbols defined by OWN, GLOBAL, LABEL, EXTERNAL, GLOBAL ROUTINE,
and
EXTERNAL ROUTINE.
BLISS issues a diagnostic message when a name exceeds 31 characters
and ignores any characters beyond that.
Thus, to avoid confusion
among names, distinguish a name within a name as soon as possible; for
example,
use IN A VALUE and IN B VALUE instead of IN VALUE A and
IN VALUE B.
BLISS also issues a dIagnostic message when two unique
GLOBAL names match in the first six characters; the linker also
diagnoses this problem.
BLISS allows the declaration of the same symbolic name in different
contexts,
provided the declarations appear in distinct blocks.
However, the MACRO assembler neither r(~cognizes blocks nor permits any
redefinition of symbols.
If a file is created for assembly outside of
BLISS, all symbols declared by ROUTINE, OWN, and GLOBAL must be unique
within the entire module.
If this is not true, the /UNAMES switch
must be used to avoid an assembly error.
Good programming practice dictates that duplicate symbolic names
should be avoided wherever possible, since they cause confusion and
add to debugging and program maintenance time.
If any duplication
occurs, use the names for the same purpose in parallel construction.
This code is acceptable:
MACRO
ADD (A, B)
SUB(A, B)

A + B%
A
B%

but the following code is not recommended:
BEGIN
OWN
A;
BEGIN
LITERAL
A=5;
END;
END

6.2.10

Routines Within Routines

Declaring a routine within the declaration of another routine must
avoided for the following reasons:
•

Although an embedded routine can take a name identical to that
of an unembedded routine, without error, you may inadvertently
cause confusion and subsequent errors by using this name to
refer to the outer routine.

6-6

PROGRAMMING CONSIDERATIONS
•

A degree of complexity is added to the compilation process,
causing the compiler to take longer to compile your program.

•

It is more difficult to follow the code when each routine does
not "stand by itself."

6.2.11

Indexed Loop Coding Error

A
common
coding
error
occurs
indexed-loop-expressions of the form:

the

use

unsigned

DECRU I FROM HIGH TO 0 DO
This code results in an infinite loop because you are attempting to
decrement through zero. Since the rules of unsigned arithmetic state
that zero is the smallest integer, the .1 will never be less than zero
and the loop cannot terminate.
The proper interpretation of these expressions is as follows:
BEGIN
LOCAL I;
I = HIGH;
IF .1 GTRU 0 DO ( I
END;

.1 - 1) UNTIL .1 LSSU 0;

Thus, when .1 is zero and is decremented to -1, it becomes the largest
unsigned number. The expression .1 LSSU 0 is always FALSE because -1
LSSU 0 is always FALSE.
Therefore,
the unsigned
indexed-loop
expression must be coded as either:
DECRU I FROM HIGH + 1 TO 1 DO
or
DECRU I FROM HIGH TO 0 DO
BEGIN
IF .1 EQL 0 THEN EXITLOOP
END;
The semantics of the DECRA expression are the same,
LSSU are GTRA and LSSA.

6.3

except

GTRU

and

ADVANCED USE OF BLISS MACROS

This section provides some examples of the advanced use of BLISS
macros.
In particular,
the examples demonstrate the use of the
following:
•

Conditional compilations

•

Iterative macros

•

Lexical functions (such as %QUOTE and %EXPAND)

6-7

PROGRAMMING CONSIDERATIONS
6.3.1

Advantageous Use of Machine Dependencies

The following examples show how machine-independent constructs may
modified to take advantage of machine dependencies.

Assume a high-level construct is needed to move a fullword sequence
from
a
source
to
a destination; the simplest transportable
implementation of this might be as follows:
MACRO
MOVE CORE ( SRC, DST, LENTH )
BEGIN
BIND
$S=(SRC)
VECTOR,
VECTOR;
$D=(DST)
INCR I FROM 0 TO (LENTH)-l DO $D[.IJ
END %;

.$S[.IJ

Notice that the BIND of SRC and DST guards against their producing any
extraneous side-effects. For example, if the assignment-expression in
the INCR loop used a general structure reference of the form:
VECTOR[ DST,

.1 J = .VECTOR[ SRC,

.1 J;

and the DST or SRC expressions were routine-calls,
a call would be
executed every time a pass was made through the loop. Thus, the BIND
to $D and $S ensures that this side-effect occurs only once.
Using String Instructions
The macro shown in the previous example is, however,
inefficient for
use in moving large blocks of memory due to excessive execution time
and instruction size; more efficient coding would take advantage of
string instructions supported by the VAX-II and DECsystem 10/20
hardware.
As an example, the transportable CH$MOVE function can be used, with
appropriate adjustments,
to deal with 8-bit bytes on the VAX and
36-bit bytes on the 10/20 as follows:
MACRO
WORD_PTR(A) = CH$PTR( A %BLISS36(, 0,

36) ) %,

MOVECORE(SRC,DST,LENTH) = CH$MOVE(
(LENTH)*%UPVAL,
WORD PTR(SRC),
WORD=PTR(DST) ) %;
This method produces fairly efficient code; but for DECsystem 10/20 an
even more efficient implementation is possible with the use of the BLT
(Block Transfer) instruction as follows:
MACRO
MOVECORE(SRC,DST,LENTH)=
%IF %BLISS(BLISS36)
%THEN
BEGIN
BIND
$D = (DST);
BUILTIN MACHOP;
LITERAL BLT=%0'251';
REGISTER
RQQQ,
SQQQ=l;
6-8

BLT opcode
Must not be ACO

PROGRAMMING CONSIDERATIONS
RQQQ<18,18> = (SRC);
RQQQ<O,18> = ($0);

Source-ptr in LH
Destination in RH

Effective address
%IF %LTCE( LENTH )
%THEN
tells where to stop
SQQQ = .RQQQ<O,18>;
MACHOP( BLT, RQQQ, (LENTH)-l, SQQQ )
%ELSE
SQQQ = ($0) + (LENTH);
MACHOP(BLT, RQQQ, -1, SQQQ)
%FI
END
%ELSE
CH$MOVE((LENTH)*%UPVAL, SRC, DST)
%FI %,
The BLISS-36 version of MOVE CORE is now heavily conditionalized to
generate the best possible code when the length of the memory block is
known at compile or link time.
For example, the %LTCE lexical function determines if the PDP-10
effective-address calculation can be used to completely evaluate the
expression:
.SQQQ + (LENTH) - 1
Otherwise, if the expression is not a link-time constant,
it is
necessary to compute the ending address by a combination of run-time
addition and effective-address computation.
It should be noted, however, that there is some risk involved with
this implementation,
in that the BLT always moves at least one word.
Thus, if the LENTH parameter is zero, the BLT method incorrectly moves
one word to the destination.

6.3.2

Dealing with Enumeration Types

One of the more powerful features of languages such as PASCAL and ADA
is the ability to define a finite set of elements. This capability is
known as an
enumerated type
because the set is defined by
exhaustively naming each possible element in the set.
II

II ,

While BLISS is unaware of such types, it is
adequate simulation.

possible

provide

6.3.2.1 The SET Data-Type - Sets are implemented in BLISS through a
system of MACROs.
An element of the set is given a small integer
value between zero and %BPVAL-l.
Thus,
sets are limited
(in this
implementation) to contain no more than %BPVAL elements in their
domains.
A subset is stored by turning on bits in a fullword.
For reasons to
be discussed later, the bits in the fullword are numbered in reverse
order from the normal BLISS conventions. Thus for the BLISS-36 a set
looks as follows:

0111213141516171 ........ 331341351

6-9

PROGRAMMING CON.SIDERATIONS

The digits inside the box refer to element-numbers, while the digits
(0)
and
outside
the
box
refer
to
the
most-significant
least-significant bits (35) of a word.
The following table shows some
contain:

and

the

elements

6.3.2.2 Creating a Set - The following macro is
enumeration type.

used

Set (in octal)

Contents

400000000000
400000000001
000000000002
776000000000

simple

sets

they

0,35
34
0,1,2,3,4,5,6,7

define

MACRO
ENUMERATION(NAME)=
1+
1 Creates a PASCAL-like ENUMERATION type. The parameter
1 NAME will be defined as a macro expanding to the
! comma-list of the %REMAINING parameters.
1-

COMPILTIME
NAME
LITERAL
ENUM

(NAME,%REMAINING)~

UNDECLARE NAME;
MACRO NAME = %QUOTE %EXPAND %REMAINING %QUOTE %
%,
ENUM (V)[N] = N = V

%ASSIGN(V,V+l)

Note that the ENUMERATION macro is particularly interesting due to the
use of the %QUOTE lexical function. As an example, consider the use
of the ENUMERATION macro to define the type TREES:
ENUMERATION ( TREES, OAK, MAPLE, PINE, ELM

The intended result is that the names OAK, MAPLE, PINE, and ELM should
be defined as:
LITERAL
OAK = 0,
MAPLE = I,
PINE = 2,
ELM = 3;
And the name TREES should be defined by the macro
MACRO TREES = OAK, MAPLE, PINE, ELM %i
The %QUOTE is necessary to prevent the %EXPAND from occurring until
the ENUMERATION macro is expandingi at that time, the %REMAINING will
be bound to the list of names: OAK, MAPLE, PINE, ELM.

6-10

PROGRAMMING CONSIDERATIONS

Because the macro NAME is inside another macro,
its body is being
scanned at macro-quote level when the ENUMERATION macro expands.
Thus, if the body of the ENUMERATION macro was defined as:
MACRO NAME

%REMAINING %QUOTE

The result of expanding ENUMERATION would be:
MACRO TREES

= %REMAINING %~

Since TREES is defined as not having a macro-parameter list, the value
of the %REMAINING would always be empty. Therefore, you need to force
the expansion of the %REMAINING when the ENUMERATION macro is
expanded, not when the TREES macro is expanded.
Also, if you define the ENUMERATION macro as:
MACRO NAME

%EXPAND %REMAINING %QUOTE

This would cause the %REMAINING to be expanded too soon (namely, when
the ENUMERATION macro is declared), and again, %REMAINING would be an
empty lexeme sequence.
The MACRO, which expands to the entire domain of the enumeration type,
can be used as follows:
1.

To iterate over a set, write:
INCR SPECIES FROM MIN(TREES) TO MAX(TREES) do ...

Using the CASE control-expression, write:
CASE .WOOD FROM MIN(TREES) TO MAX(TREES) OF
SET
[OAK] :
[MAPLE]: ...
[PINE, ELM]:
[OUTRANGE] :
TES~

A successor function can be defined as:
MACRO SUCCESSOR(T)

The MOD is used to cause
MIN (TREES) .

= ( (T)+l ) MOD MAX(TREES) %~

SUCCESSOR(MAX(TREES))

Of course, a more general implementation
parameter, as in:

would

to
pass

the
the

same
SET

as
a

MACRO SUCCESSOR(T) = «T)+l) MOD MAX(%REMAINING) %;
This would be invoked as SUCCESSOR( MAPLE, TREES ) to return the value
2 (the literal associated with PINE).

6.3.2.3 Placing Elements in Sets - Given elements of an enumeration
type, you want to produce a subset containing those elements. The
SUBSET macro shows another useful example of an iterative macro.
Its

6-11

PROGRAMMING CONSIDERATIONS
purpose is to OR together the single sets produced by BITS.
Notice
how the sequence "0 OR BITS( ... )" is used to force the default
separator to be OR.
BITS is notable for including defensive code to
detect attempts to produce sets that exceed the implementation limits.
MACRO
BITS[AJ=
%IF %CTCE(A)
%THEN
%IF A GTRU %BPVAL-l
%THEN
%WARN(IValue (I, %NUMBER(A),
I) in BITS Mask exceeds %BPVAL-11)
%FI
%FI
( 1 "( ( %BPVAL -1 ) - (A )
) %,
SUBSET[] = ( 0 OR BITS(%REMAINING)

) %:

Typical use of the SUBSET macro would be to initialize
test for intersections, as in:

set

OWN FOREST: INITIAL( SUBSET<OAK, MAPLE> );
IF (.FOREST AND SUBSET<PINE,ELM» EQL 0
THEN
1 No trees in common between two sets

6.3.2.4 Membership in a Set - The ONEOF macro efficiently determines
if an element is a member of a given subset.
This depends on doing a
left-shift and examining the sign-bit of the result value.
This is
why sets are stored in reverse-numbered bit fields.
This example also deals with machine dependencies,
as the BLISS-36
arithmetic shift operator
(") must choose either an ASH or a LSH
instruction.
An ASH leaves the sign-bit unchanged,
the desired
behavior when right-shifting any value; but when left-shifting, the
BLISS semantics demand that a LSH be generated.
If the shift-count is
unknown at compiletime,
BLISS-36 must generate a run-time test and
conditionally execute either the ASH or LSH.
Because you know that
the shifts are always left, the generated code is optimized by forcing
a LSH to be emitted as shown below.
MACRO
ONEOF(ELEMENT,SUBSET)=
%IF %BLISS(BLISS36)
%THEN
BEGIN
BUILTIN LSH;
LSH(SUBSET, ELEMENT) LSS 0
END
%ELSE
«(SUBSET) " (ELEMENT)) LSS 0)
%FI %;
For example consider the following:
LOCAL TREE: INITIAL( ELM ); ! An element
IF ONEOF(
THEN

.TREE, SUBSET<ELM, PINE> )

6-12

PROGRAMMING CONSIDERATIONS
This code fragment would expand to the following:
IF
BEGIN BUILTIN LSH;
LSH ( (1 "(35-3» OR (1 "(35-2» ),
END
THEN

.TREE)

LSS 0

This is equivalent to the following:
IF LSH (%1140000000000 1 ,
THEN

.TREE) LSS 0

And assuming that TREE still contains its
ELM) , you have:

( for

member

the

initial

value

ELM

IF (%0 1400000000000 1 ) LSS 0
THEN
This evaluates to TRUE and indicates that
subset {ELM, PINE}.

6.4

EXTENDED ADDRESSING DIFFERENCES

Compiling a BLISS-36 program with extended addressing differs from the
compilation of programs without this feature in the following ways:
•

The value of %BPADDR is 30.

•

If a legal character size (6, 7, 8, 9, 18) is used, the CH$PTR
function returns a
l-word global byte pointer; otherwise, a
local byte pointer is returned.

•

The compiler assumes that all relocatable
symbols
and
externals are in the same sectioni this includes the following
data- and routine-declarations: .
FORWARD, OWN, GLOBAL, EXTERNAL,
FORWARD ROUTINE, ROUTINE,
GLOBAL ROUTINE, EXTERNAL ROUTINE

•

The compiler performs all address arithmetic to 30 bits of
precision.
To accomplish this,
an XMOVEI (30-bit access)
instruction is generated in place of a MOVEI
(18-bit access)
instruction. For example:
EXTERNAL
ai

LOCAL
bi
b

The extended addressing code generates:
XMOVEI AC,A

iB,A

6-13

PROGRAMMING CONSIDERATIONS
Without extended addressing the code would be:
MOVEI AC,A
•

iB,A

Since the LINKER restricts the use of nonzero sections
PSECTED programs, PSECTED code is generated by default.

If, in addition, you use the SECTION-INDEPENDENT
addressing, the following difference occurs:
•

option

extended

The compiler generates code that, at run time, determines
section number.
For example:

the

OWN

A,
Bi

CH$PTR(A} i

The code in the example generates the
assembly instructions:

following

sequence

SECTION INDEPENDENT CODE:
1 The address of A-I is determined at run-time.
1

XMOVEI AC, A-I
TLO
AC, -120000
MOVEM AC, B

NOSECTION INDEPENDENT CODE:
!

1 The address of A-I is determined at link-time.

MOVE
MOVEM

AC, C.l
AC, B

C.l: XPOINT 7, A-I,

6-14

CHAPTER 7
TRANSPORTABILITY GUIDELINES

This chapter addresses the task of writing transportable programs.
It
shows why writing such transportable code is much easier if considered
from t~he beginning of the project, explores properties that cause a
program to lose its transportability,
and discusses techniques by
which a programmer can avoid these pitfalls.
After an introduction to the concept of transportability,
the
transportability guidelines presented in this chapter are organized
into t~hree sections.
The section on general strategies discusses some
high-level approaches to writing transportable software in BLISS.
The
section on tools describes various features of the BLISS language that
can be used in solving transportability problems. The section on
Techniques analyzes various transportability problems and suggests
solutions to them.
The dialects discussed in this chapter are the
the following BLISS compilers:

languages

defined

BLISS-16 V4
BLISS-32 V4
BLISS-36 V4

7.1

INTRODUCTION

A transportable BLISS program is one that can be compiled to execute
on at least two, and preferably all, of the three major architectures:
PDP-IO, PDP-II, and VAX-II.
Various solutions to the problem of
transportability exist,
each requiring different levels of effort.
Various kinds of solutions are recommended.
In some cases,
for
example,
program text should be rewritten.
In other cases, large
portions of programs may be written in such a way that no modification
is required and equivalent functionality is preserved in differing
archit.ectures.
The levels' of solutions in order of decreasing
desirability are:
text.

program

No change is needed to
completely transportable.

•

Parameterization solves the transportability problem.
The
program makes use of some features that have an analog on all
the other architectures.

•

Parallel definitions are required.
Either the program makes
use of features of an architecture that do not have analogs
across all other architectures,
or different,
separately
transportable
aspects
of
the
program
interact
in
nontransportable ways.

7-1

program

The

•

TRANSPORTABILITY GUIDELINES
The goal is to make transportability as simple as possible, which
means that the effort needed in transporting programs should be
minimized. Central to the ideas presented here is the notion that
transportability is more easily accomplished if considered from the
beginning.
Transporting programs after they are running becomes a
much more complex task.
It is advantageous to run parallel compilations frequently.
It is
fortunate,
therefore,
that with the right tools and techniques,
transportability is not difficult to achieve.
The first transportable
program is the hardest.
Before undertaking a
large programming
project, you may find it useful to write and transport a
less
ambitious program.
These guidelines are the result of a concentrated study of the
problems associated with transportability.
No claim is made that
these guidelines are complete.
Some of what is contained here will
not be obvious to programmers.
An attempt is made to identify those
areas that can cause problems, if the programmer is not forewarned.
Solutions to all identified problems are suggested.

7.2

GENERAL STRATEGIES

This section presents certain global considerations that are important
to the writing of transportable BLISS programs, namely:
•

Isolation

•

Simplicity

7.2.1

Isolation

You should keep in mind the following maxim
coding a program that is to be transported:
•

when

designing

and/or

If it is nontransportable, isolate it.

You will probably encounter situations for which it is desirable to
use machine-specific constructs in your BLISS program.
In these
cases, simply isolating the constructs will facilitate any future
movement of the program to a different machine.
In most cases, only a
small percentage of the program or system will be sensitive to the
machine on which it is running.
By isolating those sections of a
program or a system, you can mainly confine the effort involved in
transporting
the
program
to
these
easily
identifiable,
machine-specific sections.
Specifically, follow these rules:
•

If machine-specific data is to be allocated,
place
allocation in a separate MODULE or in a REQUIRE file.

•

If machine-specific data is to be accessed,
place
the
accessing code in a ROUTINE or in a MACRO, and then place the
ROUTINE or MACRO in a separate MODULE or in a REQUIRE file.

•

If a machine-specific function or instruction is to
isolate it by placing it too in a REQUIRE file.

•

If it is impossible or impractical to isolate this part of
your program from its module, comment it heavily.
Make it
obvious to the reader that this code is nontransportable.

7-2

the

used,

TRANSPORTABILITY GUIDELINES
The above rules are applicable in the local context of a routine or
module.
In a
larger or more global context (for instance, in the
design of an entire system) isolation is implemented by the technique
of modularization.
By separating those parts of the system which are
machine or operating system dependent from the rest of the system, you
can simplify the task of transporting the entire system.
It becomes a
matter of recoding a small section of the total system.
The major
portion of the code (if written in a transportable manner) should be
easy to move to a new machine with a minimum of recoding effort.
BLISS is a language which facilitates both the design and programming
of programs and systems in a modular fashion.
This feature should be
used to advantage when writing a transportable system.

7.2.2

Simplicity

A basic concept in writing transportable BLISS software is simplicity
in the use of the language.
BLISS was originally developed for
implementing systems software. As a result of this, BLISS is nearly
unique among high-level programming languages in that it allows ready
access to the machine on which the program will be running.
The
programmer is allowed to have complete control over the allocation of
data, for example. Unfortunately, the same language features that
allow access to underlying features of the hardware are the very
features that lead to nontransportable code.
In a system intended to
be transportable,
these features should be used only where necessary
to meet a specific functional, performance, or economy objective.
It is often the case that BLISS language features that make a program
nontransportable also make the program inherently more complex.
Reducing the complexity of data allocation, for example, results in a
transportable subset of the BLISS language.
This reduction of
complexity is one of the basic themes that runs through these
guidelines.
In effect,
coding transportable programs is a simpler
task because the number of options available has been reduced.
Simplicity in the coding effort is one of the reasons for the
development of higher-level languages like BLISS.
Using the defaults
in
BLISS will result in programs which are much more easily
transported.

7.3

TOOLS

This section on tools presents various language features that provide
a means for writing transportable programs.
These features are either
intrinsic to BLISS or
have
been
specifically
designed
for
transportability
and/or
software
engineering uses.
The tools
described here will be used throughout the companion section on
techniques.

7.3.1

Literals

Literals provide a means for associating a name with a compile-time
constant expression.
This section considers some built-in literals
which will aid in writing transportable programs.
In addition,
it
discusses restrictions on user-defined literals.

7-3

TRANSPORTABILITY GUIDELINES
7.3.1.1 Predeclared Literals - One of the key techniques in writing
transportable programs is parameterization. Literals are a primary
parameterization tool.
The BLISS language has a set of predeclared,
machine specific literals that can be most useful. These literals
parameterize certain architectural values of the three machines.
The
values of the literals are dependent on the machine for which the
program is currently being compiled.
Here are their names and values:
Description

Literal
Name

10/20

VAX-II

Bits per addressable unit
Bits per address value
Bits per BLISS value

%BPUNIT
%BPADDR
%BPVAL

36
18
36

8
32
32

8
16
16

Units per BLISS value

%UPVAL

The names beginning with '%'
are literal names that can be used
without declaration.
These literal names are used throughout these
guidelines.
Bits per value is the maximum number of bits in a BLISS value.
Bits
per unit is the number of bits in the smallest unit of storage that
can have an address.
Bits per address refers to the maximum number of
bits an address value can have.
Units per value is the quotient
%BPVAL/%BPUNIT.
It is the maximum number of addressable units
associated with a value.
We can derive other useful values from these built-in
example:
LITERAL
HALF VALUE

= %BPVAL /

literals.

For

defines the number of bits in half a word (half a longword on VAX-II).

7.3.1.2 User-Defined Literals - A literal is not strictly speaking a
self-defining term.
The value and restrictions associated with a
literal are arrived at by assigning certain semantics to its source
program representation.
It is convenient to define the value of a
literal as a
function of the characteristics of a
particular
architecture,
which means that there are certain architectural
dependencies inherent in the use of literals.
Because the size of a
BLISS value determines the value and/or the representation of a
literal, there are some transportability considerations.
BLISS value
(machine word) sizes are different on each of the three machines. On
VAX-II, the size is 32 bits; on the 10/20 systems, it is 36;
and the
11 value is 16.
There are two types
string-literals.
The
the machine word size.
are:

of BLISS literals:
numeric-literals
and
values of numeric-literals are constrained by
The ranges of values for a signed number,
i,

VAX-II:

-(2**31)

(2**31)

- 1

10/20:

-(2**35)

(2**35)

- 1

11:

-(2**15)

(2**15)

- 1

ALL:

-(2**(%BPVAL-l»

(2**(%BPVAL-l»-1

7-4

TRANSPORTABILITY GUIDELINES
A numeric literal, %C'single-character', has been implemented.
Its
value is the ASCII code corresponding to the character in quotes and
when stored,
it is right-justified in a BLISS value
(word or
longword).
A more thorough discussion of its usage can be found in
the section on character sequences.
There are two ways of using string-literals: as integer-values and as
charact.er strings. When string-literals are used as values, they are
not transportable.
This arises
out
of
the
representational
differences and from differing word sizes.
The following table
illustrates these potential differences for a %ASCII type string
literal:

Maximum number of
characters
Character placement

VAX-II

10/20

right to
left

left to
right

right to
left

This type of string literal usage and also its use as
string are discussed in the section Character Sequences.

7.3.2

character

Macros and Conditional Compilation

of
BLISS macros can be an essential tool in the development
(expand) during
transportable
programs.
Because they evaluate
compilation, it is possible to use macros to tailor a program to a
specific machine.
two
A good example can be found in the section on structures. There,
macros are developed whose functions are completely transportable.
The macros can determine the number of addressable units needed for a
vector of elements, where the element size is specified in terms of
bits. There are also predefined machine conditionalization macros
available.
These macros can be used to selectively compile certain
declarations and/or expressions depending on which compiler is being
run.
There are three sets of definitions, each containing three macro
definitions.
The definitions for the BLISS-32 set are:
MACRO
%BLISS16[]
%BLISS36[]
%BLISS32[]

% ,
% ,
%REMAINING % ;

There are analogous definitions for the other machines.
The net
effect is that in the BLISS-32 compiler, the arguments to %BLISSl6 and
%BLISS36 will disappear, while arguments to %BLISS32 will be replaced
by the text given in the parameter list.
A very explicit way of tailoring a program to a specific architecture
uses the %BLISS lexical function in conjunction with the conditional
compilation facility in BLISS.
The %BLISS lexical function takes
either BLISS36,
BLISS32, or BLISSl6 as a parameter, and returns 1 if
the parameter corresponds to the compiler currently executing,
and 0
otherwise.

7-5

TRANSPORTABILITY GUIDELINES
In the following example,
INSQUE is
BLISS-32, but is a routine for BLISS-36:

executable

function

%IF %BLISS(BLISS32)
%THEN
BUILTIN
INSQUE;
%ELSE
~IF %BLISS(BLISS36)
%THEN
FORWARD ROUTINE
INSQUE;
%FI
%FI

7.3.3

Module Switches

A module switch and a corresponding special switch are provided to aid
in the writing of transportable programs.
This switch, LANGUAGE, is
provided for two reasons:
•

To indicate the intended transportability goals
and

•

To provide diagnostic checking of the use of certain
features.

module
language

Using this switch, you can therefore indicate the target architectures
(environments) for which a program is intended.
Transportability checking consists of the
compiler
determining
whether,
in the module being compiled,
certain language features
appear that fall into either of two categories:
•

Features that are not commonly supported across
target environments.

the

intended

•

Features that most often prove to
be
troublesome
in
transporting a program from anyone environment to another.

The syntax is:
LANGUAGE (language-name , ... )
where language-name is any combination of BLISS36, BLISS16 or BLISS32.
Two other forms are possible:
LANGUAGE ( COMMON
LANGUAGE ()
If no LANGUAGE switch is specified, the default is the single language
name corresponding to the compiler used for the compilation, and no
transportability checking
is
performed.
If
more
than
one
language-name is specified, the compiler will assume that the program
is intended to run under each corresponding architecture.
If no language name is specified, no transportability checking will be
performed.
A specification of COMMON is the equivalent of the
specification of all three.

7-6

TRANSPORTABILITY GUIDELINES
Each compiler will give a warning diagnostic if its own
is not included in the list of language-names.

language-name

Within the scope of a language switch,
each compiler will give a
warning diagnostic for any non transportable or problematic language
construct relative to the specified set of languages.
This chapter
discusses most of the constructs that will be checked for.
NOTE
The precise set of language constructs that are
subject to transportability checking is specified in
Appendix C of the Bliss Language Guide.
Here is an example of how the LANGUAGE switch can be used:
MODULE FOO( ... ,LANGUAGE(COMMON), .. ;)
BEGIN

1 Full Transportability Checking is in effect.
1-

BEGIN
1+

1 BLISS36 no longer in effect: BLISS-l6/32 Subset checking
1 to be performed in this block.
1-

SWITCHES
LANGUAGE(BLISSl6, BLISS32)j

Within this block (that is, within the scope
of the SWITCHES declaration), a relaxed
form of full transportability checking
is performed. (This takes advantage of
the greater degree of commonality that
exists between the BLISS-l6 and BLISS-32
target architectures.)
The compilation of this section
of code by a BLISS-36 compiler will
result in a diagnostic warning.

gNDj

Full transportability checking is restored.
1-

7-7

TRANSPORTABILITY GUIDELINES
7.3.4

Reserved Names

The following is a list of the BLISS reserved names.
These names
cannot be user declared.
Note that, while the same names are reserved
in all three BLISS dialects, some of them do not have a predefined
meaning in each dialect.
For example, LONG is an allocation-unit
keyword in BLISS-32 and is a reserved but otherwise unsupported name
in BLISS-16 and BLISS-36 (due to basic architectural differences in
the target systems). Any attempted use of this name in the latter two
dialects will result in a compiler diagnostic.
As another example,
the name IOPAGE has no defined meaning in any BLISS dialect but is
reserved for possible future use in all dialects.
The reserved names
that are not supported in some or all dialects are marked with an
asterisk.
See Appendix A of the Bliss Language Guide for a more
complete description.
*ADDRESSING MODE
*ALIGN
ALWAYS
AND
BEGIN
BIND
*BIT
BUILTIN
BY
*BYTE
CASE
CODECOMMENT
COMPILETIME
DECR
DECRA
DECRU
DO
ELSE
ELUDOM
ENABLE
END
EQL
EQLA
EQLU
EQV
EXITLOOP
EXTERNAL
FIELD
FORWARD
FROM
GEQ
GEQA
GEQU
GLOBAL
GTR
GTRA

7.3.5

GTRU
IF
INCR
INCRA
INCRU
INITIAL
INRANGE
*IOPAGE
KEYWORDMACRO
LABEL
LEAVE
LEQ
LEQA
LEQU
LIBRARY
LINKAGE
LITERAL
LOCAL
*LONG
LSS
LSSA
LSSU
MACRO
MAP
MOD
MODULE
NEQ
NEQA
NEQU
NOT
NOVALUE
OF
OR
OTHERWISE
OUT RANGE
OWN

PLIT
PRESET
PSECT
*RECORD
REF
REGISTER
REP
REQUIRE
RETURN
ROUTINE
SELECT
SELECTA
SELECTONE
SELECTONEA
SELECTONEU
SELECTU
SET
*SHOW
*SIGNED
STACKLOCAL
STRUCTURE
SWITCHES
TES
THEN
TO
UNDECLARE
*UNSIGNED
UNTIL
UPLIT
VOLATILE
*WEAK
WHILE
WITH
*WORD
XOR

Require and Library Files

REQUIRE files are a way of gathering machine-specific declarations
and/or expressions together in one place.
LIBRARY files are a form of
precompiled REQUIRE files.
In many cases, it will be either impossible or unnecessary to code a
particular BLISS construct (for example, routines, data declarations,
etc.) in a transportable manner.
Developing parallel REQUIRE files,
one for each machine,
can often provide a solution to transporting
these constructs.
7-8

TRANSPORTABILITY GUIDELINES
For example, if a certain set of routines are very machine specific,
then the solution may be to ~ode two or three functionally equivalent
routines, one for each machine type, and segregate them each in their
own REQUIRE file.
Each BLISS compiler has a predefined search rule for REQUIRE file
names based on their file types.
Each compiler will search first for
a file with a specific file tjpe, then it will search for a file with
the file type
.BLI'.
I

The search rules for each compiler are:
Compiler

1ST

2ND

3RD

4TH

BLISS-36

.R36

.REQ

.B36

.BLI

BLISS-16

.R16

.REQ

.B16

.BLI

BLISS-32

.R32

.REQ

.B32

.BLI

Hence, the following REQUIRE declaration:
REQUIRE
I IOPACK' j

I/O Package

will search for IOPACK.R36, IOPACK.R16 or
which compiler is being run.
Failing
IOPACK.REQ, and so on.

IOPACK.R32,
depending on
that,
it will look for

Inherent in these search rules is a naming convention for REQUIRE
files.
If the file is transportable, give it the file type '.REQ' or
.BLI'.
If it is specific to a particular dialect,
give it the
corresponding file type (for example, '.R36 or '.B36
I

Each BLISS compiler, by using the /LIBRARY switch,
is capable of
precompiling files containing declarations.
Not all the declarations
can be processed in a library run howeverj those that are allowed are
described elsewhere.
The output of a library run is called a library
filej library files are processed by a compiler when it encounters a
library-declaration, for example:
LIBRARY
IOPACK' ;
I

Each compiler checks to see that the library file
it is using was
produced by itself in a previous run.
Thus, to build a transportable
library from a single transportable source,
you must build unique
LIBRARY files for each architecture of interest, using the appropriate
compilers of interest.
For example, let us assume that the file SYSDCL.BLI contains a set of
transportable declarations common to an application which is to run on
a DECSYSTEM-20 and a VAX.
To precompile it requires that we run the
BLISS-32 compiler on it using the /LIBRARY switch, and the BLISS-36
compiler using the /LIBRARY switch.
The object file produced by the
compiler is the library file, and if no extension is given for it in
the command line, a default extension is used (for example,
.L32 and
.L36, respectively).

7.3.6

Routines

The key to transportability is the ability to identify an abstraction
that can exist in several environments.
This is done by naming the
abstraction and describing its external characteristics in a way that

7-9

TRANSPORTABILITY GUIDELINES
permits implementation in any of the environments.
The abstraction
may then be implemented separately in each environment. The closed
subroutine has long been regarded as the principal abstraction
mechanism in programming languages.
With BLISS, other abstraction
mechanisms are also available,
like structures,
macros,
literals,
require files,
etc.,
but the routine can still be easily used as a
transportability abstraction mechanism.
For instance, when designing a system of transportable modules which
uses the concept of floating point numbers and associated operations,
there will be a need to perform floating point arithmetic.
The
question
naturally arises as
to the environment in which the
arithmetic should be done.
If the floating point arithmetic resides
entirely in a well-defined set of routines, and no knowledge of the
various representations of floating point numbers is used except
through these well defined interface routines,
then it becomes
possible to perform "cross-arithmetic", which is important when
writing cross-compilers, for instance.
Even if the ability to perform
cross-arithmetic is not desired, isolating floating point operations
in routines may be a good idea since these routines can then be reused
more easily in another project. A little thought will indicate that
the floating point routines themselves have to be transportable if
they are going to perform cross-arithmetic
(since the system under
construction is transportable),
but need not be transportable if
cross-arithmetic is not a goal.
The principal objection to using routines as an abstraction mechanism
is that the cost of calling a procedure is nontrivial, and that cost
is strictly program overhead.
Composing this sort of abstraction in
the limit will produce serious performance degradation.
For this
reason, a programmer should probably try not to use the routine as a
transportability mechanism if a small amount of forethought will be
sufficient to enable the writing of a single transportable module.

7.4

TECHNIQUES

This section on techniques shows you how to write
programs.
The section is organized in dictionary
construct or concept.
Each subsection contains:

transportable
form by BLISS

•

A discussion of the construct or concept.

•

Transportability problems that its use may engender.

•

Specific guidelines and
construct or concept.

•

Examples (both transportable and nontransportable).

restrictions

the

use

In all cases, the examples attempt to use the tools described
previous section.

7.4.1

the

Data

This section deals with the allocation of data in a BLISS program.
In
this section we do not deal with character sequence (string) data or
the formation of address data.
These types of data are discussed in
their own sections (see "Data: Addresses and Address Calculation" and
"Data: Character Sequences").
Primarily, we discuss the allocation
of scalar data (for example, counters, integers, pointers, addresses,
etc.) A presentation of more complex forms of data can be found in the

7-10

TRANSPORTABILITY GUIDELINES
sections entitled "Structures and Field-Selectors" and "PLITs and
Initialization." First there is a discussion of transportability
problems encountered due to differing machine architectures.
Next a
discussion of the BLISS allocation-unit attribute is presented.
Finally, a discussion of other BLISS data attributes that must be
considered when writing transportable programs is discussed.

7.4.1.1 Problem Origin - The allocation of data (via the OWN,
LOCAL,
GLOBAL,
etc.
declarations)
tends to be one of the most sensitive
areas of a BLISS program in terms of transportability.
This problem
of transporting data arises chiefly from two sources:
•

A machine's architecture

•

The flexibility of the BLISS language

When we are considering writing a BLISS program that will be
transported to another machine, we are confronted with the problem of
allocating data on (at least two) architecturally different machines.
Although we have already discussed differing word sizes,
there are
further
differences.
On the VAX-ll architecture,
data may be
typically fetched in longwords (32 bits), in words (16 bits)
and in
bytes
(8 bits); on the 11, both words and bytes may be fetched.
Only
18-bit halfwords and 36-bit words on the 10/20 systems may be fetched
without a byte pointer.
If we were writing our program in an assembly language we would not
consider these differences to be important; clearly, our assembly
language program was not intended to be transportable.
What decisions,
however,
must the BLISS programmer make in the
transportable allocation of data? Need he or she be concerned with
how many bits are going to be allocated?
These questions (and their answers) can be complicated by the other
chief source of data transportability problems,
namely the BLISS
language itself.
BLISS is unlike many other higher-level languages in that it allows
ready access to machine-specific control,
particularly in storage
allocation.
This is fortunate
for the programmer who is writing
highly
machine-specific software for efficiency purposes.
This
programmer needs much more control over exactly how many bits of data
will be used.
This feature of BLISS, however, can complicate the
decisions that need to be made by the BLISS programmer who is writing
a transportable program.
Does he or she allocate scalars by bytes, or
by words, or by longwords?

7.4.1.2 Transportable Declarations - Consider
example of a data declaration in BLISS-32:
LOCAL
PAGE COUNTER: BYTE;

the

following

simple

1 Page counter

The programmer has allocated one byte (8 bits) for a variable named
PAGE COUNTER.
No matter what the intentions were in requesting only
one byte of storage,
this ,declaration is nontransportable.
The
concept of BYTE (in this context) does not exist on the 10/20 systems.

7-11

TRANSPORTABILITY GUIDELINES
In fact, in BLISS-36 the use of the word BYTE results
in an error
message.
Since this storage is allocated on the stack or in a
register, there is even less motivation to make it a byte due to the
high reusability of these locations.
If this declaration had been originally coded as:
LOCAL
PAGE_COUNTER;

! Page counter

then this could have been transported to any of the three machines.
The functionality (in this case, storing the number of pages) has not
been lost. We allowed the BLISS compiler to allocate storage by
default
by
not
specifying
any allocation-unit in the LOCAL
declaration.
In all the BLISS dialects the default size
for
allocation-unit consists of %BPVAL bits.
Thus our first transportable
guideline is:
•

Do not use the allocation-unit
declaration.

attribute

scalar

data

The use of the default allocation~unit will sometimes result in the
allocation of more storage than is strictly necessary.
This gain in
program data size (which, in most instances,
is small)
should be
weighed against a decrease in fetching time for a particular scalar
value, and the knowledge that because of the default alignment rules,
no storage savings may, in fact, be realized.
In the BLISS language, the default size of %BPVAL bits was chosen
(among other reasons)
because this is the largest, most efficiently
accessed unit of data for a particular machine.
In other words,
the
saving of bits does not necessarily mean a more efficient program.
Besides the allocation-unit there
present transportability problems
allocating data:
•

are other
if used.

attributes that may
In particular,
when

Do not use the following attributes:
Extension (SIGNED and UNSIGNED),
Alignment,
Weak
which is to say: think twice before you write a declaration.
Do you really need to specify any data attributes other than
structure attributes?

The extension-attribute specifies whether the sign bit is to be
extended in a fetch of a scalar (or equivalently, whether or not the
left most bit is to be interpreted as a sign bit).
In any case,
no
sign extension can be performed if the allocation unit is not
specified.
The alignment-attribute tells the compiler at what kind of address
boundary a data segment is to start.
It is not supported in BLISS-36
or BLISS-16;
hence,
it is nontransportable.
Suitable
default
alignments are available dependent on the size of the scalar.
The weak-attribute is a VAX/VMS-specific attribute and is
not
supported by BLISS-36 or BLISS-16.
It therefore cannot be used in a
transportable program.

7-12

TRANSPORTABILITY GUIDELINES
These guidelines are relatively simple, yet they should relieve the
BLISS programmer of needing to worry about how the program data will
actually be allocated by the compiler. There is often very little
reason to specify an allocation-unit or any attributes.
The default
values are almost always sufficient.
There will undoubtedly be cases where it is impossible to avoid the
use of one or more of the above, attributes.
In fact, it may be
desirable to take advantage of a specific
machine feature.
In these
I
cases follow this guideline:
•

Conditionalize and/or heavily comment the use of
which may be nontransportable.

declarations

This 9uideline is the "escape-hatch in this set of guidelines.
It
should only be used sparingly and where justified.
To use it often
will only result in more code that will need to be rewritten when the
program has to be transported to another machine - and rewriting code
is not a goal.

7.4.1.3 Length of Externally Used Names - The length of
names
declared in EXTERNAL and GLOBAL declarations should be no longer than
six characters.
Linkers and task builders on PDP-II,
DECsystem-IO,
and DECSYSTEM-20 systems can not distinguish between symbols in which
th8 first six characters are identical.

7.4.2

Data:

Addresses and Address Calculations

This section discusses address values and calculations using address
values.
First,
there is a presentation of problems that might occur
when an address or the result of an address calculation is used as a
value.
A transportable solution to some of these problems is then
presented.
Next, a discussion is presented on the need for address
forms of the BLISS relational operators aQd control expressions and
how and when to use them.
Finally, some important differences in the
interpretation of address values between BLISS-IO and BLISS-36 are
discussed.

7.4.2.1 Addresses and Address Calculations - The value of an undotted
variable name in BLISS is an address.
In most cases, this address
value is used only for the simple fetching and storing of data.
When
address values are used for other purposes, we must be concerned with
the portability of an address or an address calculation.
The term
lIaddress calculation
means any arithmetic operations performed on
address values.
The primary reason for this concern is the different
sizes
(in bits)
of addressable units, addresses, and BLISS values
(machine words) on the three machines.
For convenience in writing
transportable programs, these size values have been parameterized and
are now predeclared literals. A table of their values can be found in
the section on "Literals. 1I
ll

To see how these size differences can have an effect on writing
transportable programs, consider a common type of address expression;
namely an expression that computes an address value from a base
(a
pointer or an address) and an offset.
That is, some expression of the
form:
base + index ...

7-13

TRANSPORTABILITY GUIDELINES
Now consider the following BLISS assignment expression using this form
of address calculation:
OWN
ELEMENT 2;

ELEMENT 2

= . (INPUT RECORD + 1);

The intent (most likely) was to access the contents of the second
value in the data segment named INPUT RECORD and to place that value
in an area pointed to by ELEMENT 2.
The effect, however, is different
on each machine as will be shown~
By adding 1 to an address (in this case, INPUT RECORD) the address of
the next addressable unit on the machine- is being computed.
In
BLISS-32 and BLISS-16 this would be the address of the next byte
(8
bits), but in BLISS-36 this would be the address of the next word (36
bits).
This is probably not a transportable expression because of the
different sizes of the addressable units and the resultant values.
Based on the above example, follow this guideline:
•

When a complex address calculation is not an intrinsic part of
the algorithm being coded, do not write it outside of a
structure declaration.

There is a way,
however,
of making such an address calculation
transportable.
It involves the use of the values of the predeclared
literals.
In the last example, if the index had been 4 in BLISS-32 or
2 in BLISS-16 then in each case the next word would have been
accessed.
A multiplier that will have a value of 4 in BLISS-32,
2 in BLISS-16
and 1 in BLISS-36 is needed.
Such a mUltiplier already exists as
another predeclared literal.
Its definition is %BPVAL/%BPUNIT, and it
is called %UPVAL.
Using this literal in our example yLelds:
ELEMENT 2 =
. (INPUT_RECORD + 1

* %UPVAL);

The address expression is now tranportable.
This last example raises an interesting point.
If an address
calculation of this form is used then it is very likely that the data
segment should have had a structure such as a VECTOR,
BLOCK or
BLOCKVECTOR associated with it.
The last example could have then been
coded as:
OWN
INPUT RECORD:
FLEX VECTOR[RECORD SIZE,%BPVAL],
ELEMENT 2;
-

ELEMENT_2

= .INPUT RECORD[l];

The transportable structure FLEX VECTOR and a more thorough discussion
of structures can be found Tn the section on structures and field
selectors.
7-14

TRANSPORTABILITY GUIDELINES

7.4.2.2 Relational Operators and Control Expressions - The previous
example illustrated the use of address values in the context of
computations.
other common uses of addresses are in comparisons
(testing for equality,
etc.)
and as indices in loop and select
expressions.
The use of address values in these contexts points to
another set of differences found among the three machines.
In BLISS-32 and BLISS-16, addresses occupy a full word (%BPADDR equals
%BPVAL)
and unsigned integer comparisons must be performed. However,
in BLISS-36, addresses are smaller than the machine word (18 versus 36
bits)
and signed integer operations are performed for efficiency
reasons.
It can be seen that to perform a simple
values:

relational

test

address

ADDRESS 1 LSS ADDRESS 2 ...
requires two different interpretations.
This
expression
would
evaluate correctly on the 10/20 systems.
But,
on VAX-II and 11
machines, the following would have had to have been coded for the
comparison to have been made correctly:
... ADDRESS 1 LSSU ADDRESS 2 ...
Another type of relational operator, designed specifically for address
values,
is needed.
Such operators exist and are referred to as
address-relational-operators.
BLISS-36, BLISS-16 and BLISS-32 have a
full set
(for example,
LSSA,
EQLA,
etc.) which support address
comparisons.
In BLISS-16 and BLISS-32, the address-relationals are equivalent to
the unsigned-relationals.
In BLISS-36, the address-relationals are
equivalent to the signed-relationals.
For all practical cases, a user
need not be concerned with this, since this "equivalencing" permits
address comparisons to be performed correctly across architectures.
In addition,
there are address forms of the SELECT
(SELECTA),
SELECTONE (SELECTONEA),
INCR (INCRA)
and DECR
(DECRA)
control
expressions.
The following guidelines establish a usage for these
operators and contol expressions:
•

If address values are to be compared, use the address form
the relational operators.

•

If an address is used as an index in
use the
INCR,
or DECR expression,
control expressions.

a SELECT,
SELECTONE,
address form of these

A violation of either guideline causes unpredictable results.

7.4.2.3 BLISS-IO Addresses Versus BLISS-36 Addresses - There is a
fundamental conceptual change from BLISS-IO to BLISS-36 in the defined
value of a name.
BLISS-IO defines the value of a data segment name to
be a byte pointer consisting of the address value in the low half of a
word, and position and size values of 0 and 36 in the high half of the
word.
However,
BLISS-36 defines the value simply as the address in
the low half and zeros in the high half.
This change was made solely
for reasons of transportability,
since it allows BLISS to assign
uniform semantics to an address.

7-15

TRANSPORTABILITY GUIDELINES
The fetch and assignment operators are redefined
address part of a value.
Thus, the expressions:

.Xi

F(.Y) + 2i

use

only

the

are the same in both BLISS-IO and BLISS-36, but

Y = X;
assigns a different value to Y in BLISS-36 and in BLISS-IO.
Field selectors are still available but must be thought of as extended
operands to the fetch and assignment operators, instead of as value
producing operators applied to a name.
Thus the meaning of:
Y<O,18> = .X<3,7>;
is unchanged, but

Y = X<3,7>i
is invalid.
Moreover, it is highly recommended that field selectors
never appear outside of a structure declaration, since position and
size are apt to be highly machine dependent.
A thorough discussion
can be found in the section on structures and field selectors.

7.4.3

Data:

Character Sequences

This section discusses the use of character sequences
(strings)
in
BLISS programs.
Historically, there has been no consistent method for
transportably dealing with strings and the functions operating upon
them.
AQ hoc string functions were the rule, having been implemented
by individuals or projects to suit their particular needs.
This
section views quoted strings in two contexts:
as values (integers)
and as character strings.
Transportability problems associated with
quoted strings and guidelines for their use are discussed.

7.4.3.1 Usage as Numeric Values - The use of quoted strings as values
(in assignments and comparisons) illustrates the problem of differing
representations on differing architectures.
Describing the natural
translation of a string literal for each architecture will illustrate
the problem.
For example, consider the following code sequence:
OWN
CHAR Ii
CHAR 1

To hold a literal

= 'ONE';

A natural interpretation for BLISS-32 to use is that one longword
would be allocated and the three characters would be assigned to
increasing byte addresses within the longword.
In memory,
the value
of CHAR 1 would have the following representation:
CHAR 1: /

00 E N a

(32)

BLISS-16 would not allow this assignment because only two ASCII
characters are allowed per string-literal.
This restriction arises
from the fact that BLISS-16 works with a maximum of l6-bit values and
three 8-bit ASCII characters require 24 bits.

7-16

TRANSPORTABILITY GUIDELINES
On the 10/20 systems a word would be allocated and the characters
would be positioned starting at the high-order end of the word.
Thus
the string-literal would have the following representation in memory:
CHAR_I: / 0 N E 00 00 0 /

(36)

Even if the 10/20 string-literal had been right-justified in the word,
it still would not equal the VAX-II representation, numerically.
So,
in fac1:, the following would not be transportable:
WRITE_INTEGER(

'ABC '

);

since 'ABC ' is invalid syntax in BLISS-16, has the value
in BLISS-36, and the value 4276803 in BLISS-32.

-33543847936

Based on these problems with representation our first guideline is:
•

Do not use string-literals as numeric values.

In those cases where it is necessary to perform a numeric operation
(for example, a comparison) with a character as an argument, you must
use thte %C form of numeric literal. This literal takes one character
as its argument and returns as a value the integer index in the
collating sequence of the ASCII character set, so that:
%C'B'

= %X ' 42

The %C notation was introduced to standardize the interpretation of a
quoted
character
across all possible ASCII-based environments.
%C'quoted-character '
can be thought of as "right-adjusting" the
character in a bit string containing %BPVAL bits.

7.4.3.2 Usage as Character Strings - The necessity of using more than
one character in a
literal leads to the other situation in which
quoted strings are used:
as character strings.
To facilitate the allocation, comparison and manipulation of character
sequences,
a built-in character handling package has been constructed
as part of the BLISS language.
It has been implemented in BLISS-32,
BLISS-36, and BLISS-16.
These built-in functions provide a very complete and powerful
operations on characters.
The next guideline is:
•

set

Use the built-in character handling package when allocating
and operating upon character sequences.
This is the only way
one can guarantee the portability of strings and string
operations.

A more detailed description of these functions can be found in
Character Handling Functions chapter of the Bliss Language Guide.

7.4.4

the

PLITs and Initialization

This section is primarily concerned with PLITs and their uses.
First,
there is general discussion of PLITs and the contexts in which they
often appear. A presentation of how scalar PLIT items should be used
follows.
Next,
the problems involved in using string literals in
PLITs and suggested guidelines for their use are presented.
Finally,
the use of PLITs to initialize data segments will be illustrated by
the development of a transportable table of values.

7-17

TRANSPORTABILITY GUIDELINES
7.4.4.1 PLITs in General - Because BLISS values are a maximum of a
machine word in length, any literal that requires more than a word for
its value needs a separate mechanism, and that mechanism is the PLIT
(or UPLIT).
Hence,
PLITs are a means for defining references to
multi-word constants.
PLITs are often used to initialize data
segments
(for example,
tables) and are used to define the arguments
for routine calls.
PLITs themselves are
elements
and
their
transportable.

transportable; however,
machine
representation

their
are

constituent
not
always

A PLIT consists of one or more values (PLIT items).
PLIT items may be
strings,
numeric constants, address constants, or any combination of
them, provided the value of each is known prior to execution time.

7.4.4.2 Scalar PLIT Items - The first transportability problem that
might be encountered with the use of PLITs is in the specification of
scalar PLIT items.
As with any other declaration of scalar items
(pointers,
integers,
addresses,
etc.) it is possible to define them
with an allocation-unit attribute.
For example, in BLISS-32, machine
specific sizes as BYTE and LONG can be specified. Thus the following
example is nontransportable and, in fact, will not compile on BLISS-36
or BLISS-16:
BIND
Ql

= PLIT BYTE(l,

2, 3, LONG (-4));

This last example provides the first PLIT guideline:
•

Do not use allocation-units in the specification of a PLIT
PLIT item.

Thus, the BIND should have been coded as follows:
BIND
Ql = PLIT(l, 2, 3, -4);
This last guideline is necessary because of the differences in the
sizes of words on the three machines, a feature of the architectures.
A discussion of the role
of
machine
architectures
in
the
transportability of data can be found in the section on data.
Further
guidelines are presented in the section on initializing packed data.

7.4.4.3 String Literal PLIT Items - The next guideline is based on
the representation of PLITs in memory.
Specifically the problem is
encountered when scalar and string PLIT items appear in the same PLIT.
The difficulty arises primarily from the representation of characters
on the different machines. A more thorough discussion of character
representation can be found in the section on character sequences.
Care must be exercised when strings are to be used as items in PLITs.
For example,
it may be necessary to specify a PLIT that consists of
two elements:
a 5-character string and an address of a
routine.
If
it is specified as:
BIND
CONABC

PLIT('ABCDE ' , ABC ROUT);

7-18

TRANSPORTABILITY GUIDELINES
then the VAX-II representation is as follows:

D C B A /

(32)

E /

(32)

B A /

(16)

/ D C /

(16)

E /

(16)

/ ABC D E /

(36)

CONABC:

address

The representation on the 11 is:

CONABC:

/
~e

address

10/20 representation is:
CONABC:

address

The three PLITs are not equivalent.
Three longwords are required for
the BLISS-32 representation, four words are needed for BLISS-16, and
two words are needed for the BLISS-36 representation.
~ere
is a
problem if the second element of this PLIT is to be accessed by the
use of an address offset.
For example,
the second element
(the
address) is accessed by the expression:
CONABC + 1 ...
in the BLISS-36 version, but not in the BLISS-32 or BLISS-16 versions.
For the BLISS-32 version, the access expression is:
... CONABC + 8 ...
and for BLISS-16, it would have to be:
CONABC + 6 ...
Taking a data segment's base address and adding to it an offset (as in
this
case)
is
particularly sensitive to transportability.
A
discussion on the use of addresses can be found in the section on
addresses and address calculations.
This section on addresses suggests the use of the literal, %UPVAL,
to
ensure some degree of transportability.
Its value is the number of
addressable units per BLISS value or machine word.
As already
discussed,
in BLISS-32,
the literal equals 4; in BLISS-16, it is 2;
and in BLISS-36, its value is 1.
Multiplying an offset by this value can,
in some cases,
ensure an
address calculation that will be transportable.
So to access the
second element in the above PLIT, one would write:
CONABC + l*%UPVAL
But this will not work for the VAX-II representation.
An offset value
of 8 is needed because the string occupies two BLISS values.
The
situation is similar for the 11 version, where the string occupies 3
words and would need a offset value of 6 not 2.

7-19

TRANSPORTABILITY GUIDELINES
The problem with this particular example
(and,
in general, with
strings in PLITs)
is not in the use of a string literal but in its
position within the PLIT.
Because the number of characters that will
fit in a BLISS value differs on all three machines, the placement of a
string in a PLIT will very often result in different displacements for
the remaining PLIT items.
There is a relatively simple solution to this problem:
•

In a PLIT there can only be a maximum of one string
and that literal must be the last item in a PLIT.

literal,

Following this guideline, the example should have been coded:
BIND

= PLIT(ABC_ROUT,

CONABC

'ABCDE')i

and this expression:
CONABC + l*%UPVAL
would have resulted in the address of the second element in
(in this case the string).

the

PLIT

7.4.4.4 An Example of Initialization - As mentioned in the beginning
of this section, PLITs are often used to initialize data segments such
as tables. A data segment allocated by an OWN or GLOBAL declaration
can be initialized by using the INITIAL attribute.
The INITIAL
attribute specifies the initial values and consists of a list of PLIT
items.

A good example which shows how relatively easy it is to initialize
data in a transportable way is to illustrate the process one might use
to build a table of employee data.
Information on each employee will
consist of three elements:
an employee number, a cost center number
and the employee's name.
The employee's name will be a
fixed-length,
5-character field.
For example,
information:

345

201

line

the

table

would

contain

following

SMITH

converting this line into a list of PLIT items that
section's guidelines would result in the following:
(345, 201,

the

conform

this

'SMITH')

Notice that no allocation units were specified and that the character
string was specified last.
This line will now be used to initialize a
small table of only one line.
The table will have the built-in
BLOCKVECTOR structure attribute.
The table declaration would look
like:
OWN
TABLE:
BLOCKVECTOR[1,3]
INITIAL(
345,
201,
'SMITH'
) i

7-20

TRANSPORTABILITY GUIDELINES
However, a problem has developed.
This definition would work well in
BLISS-36.
That is, three words would have been allocated for TABLE.
The first word would have been initialized with the employee number;
the second word with the cost center; and the third with the name.
However, the declaration would be incorrect in BLISS-32 or BLISS-16,
simply because not enough storage would have been allocated for all
the initial values.
BLISS-32 would have required four longwords,
and
BLISS-16, five words.
The problem arises as a result of the way in which strings are
represented and allocated on the three machines.
The solution is
simple. We only need to determine the number of BLISS values that
will be needed for the character string on each machine.
There is a
function that will give this value.
It is named CH$ALLOCATION and it
is part of the character handling package.
It takes as an argument
the number of characters to be allocated and returns the number of
words needed to represent a string of this length.
We can use this value as an allocation actual in the table definition,
as follows:
OWN
TABLE:

BLOCKVECTOR[l,2 + CH$ALLOCATION(5)]
INITIAL(
345,
201,
'SMITH '
) ;

The declaration is now transportable.
By using the CH$ALLOCATION
function we can be assured that enough words will be allocated on each
machine. No recoding will be necessary.
We are free to add other lines to the table and not be concerned with
the representation or allocation of the data.
Here is a larger
example of the same kind of table.
We will not develop it step by
step, but point out and explain some of the highlights.
The example:

1+
1

Table Parameters

LITERAL
NO EMPLOYEES = 2,
EMP NAME SIZE = 25,
EMP-REC SIZE = 2 +
-CH$ALLOCATION(EMP_NAME SIZE);
1+

Employee Name padding Macro
1-

MACRO
NAME PAD (NAME) =
%EXACTSTRING (EMP_NAME_SIZE, A, NAME)%;
1+

Employee Information Table
Size: NO EMPLOYEES

* EMP REC SIZE

7-21

TRANSPORTABILITY GUIDELINES
OWN
EMP TABLE:
-BLOCKVECTOR[NO EMPLOYEES, EMP_REC_SIZE]
INITIAL(
345,

201,
NAME_PAD('SMITH PETER'),
207,
345,

NAME_PAD('JONES PENNY')
) ;

The literals serve to parameterize certain values that are subject to
change.
The literal EMP REC SIZE has as its value the number of words
needed for a
table entry.
The
character
sequence
function,
CH$ALLOCATION,
returns the number of words needed for EMP NAME SIZE
characters.
The macro will, based on the length of the employee name argument
(NAME),
generate zero-filled words to pad out the name field.
Thus,
we are assured of the same number of words being initialized for each
employee name,
no matter what its size might be.
This is important
because storage is allocated according to the fixed
length of a
character field
(employee name).
The actual string length may, of
course, be less than that value.
This last example was developed with the specification that the
employee name field was fixed in length (EMP NAME SIZE). What if,
however, we wished to have the table hold variable length names? That
is,
for certain reasons, we wished to allocate only enough storage to
hold the table data, not the maximum amount.
The table structure developed above will not work because it is
predicated upon the constant size of the name field.
If we were to
use variable length character strings, either too much or not enough
storage would be allocated.
And there would be no consistent way of
accessing the employee name (where would the next one start?).
We
could,
if we knew the length of every employee name, determine in
advance the number of words needed.
But this is not a very practical
solution.
One transportable solution is to remove the character string from the
table and replace it with a pointer to the string.
The character
package has a function, CH$PTR, which will construct a pointer to a
character sequence. As an added benefit, this pointer can be used as
an argument to the functions in the character package.
The cost of
this technique is the addition of an extra word (the character
sequence pointer) for each table entry.
The length of the name may
also be stored in the table.
Here is a typical example, again based on the employee table:

Table Parameters
!-

7-22

TRANSPORTABILITY GUIDELINES
LITERAL
NO EMPLOYEES
EMP REC SIZE
1+
1

2,
4:

Macro to construct a CS-pointer to employee name

1--

MACRO
NAME PTR(NAME) =
CH$PTR(UPLIT( NAME )), %CHARCOUNT (NAME) %:
1+
1

Employee Information Table

Size: NO EMPLOYEES * EMP REC SIZE

OWN
EMP TABLE:
-BLOCKVECTOR[NO EMPLOYEES, EMP_REC_SIZE]
INITIAL(
345,

201,
NAME PTR('SMITH PETER'),
207,
345,

NAME_PTR('JONES PENNY')
) i

7.4.4.5 Initializing Packed Data - In this section we will discuss
some transportability considerations involved in the initialization of
packed data.
By packed data, we mean that for data values vI,
v2,
... ,
vn with bit-positions pI, p2, ... , pn and bit-sizes of sl, s2,
... , sn, respectively, the value of the PLIT-item would be represented
by the following expression:

where
max(pl, p2,

... , pn)

%BPVAL

s1 + s2 + ••• + sn 5. %BPVAL
and for all i
-2**si

vi 5 2**(si - 1)

The OR operator could be replaced by the addition operator
(+), but
the result would be different if, by accident, there were overlapping
values. Notice that the packing of data in a transportable manner is
dependent on the value of %BPVAL.

7-23

TRANSPORTABILITY GUIDELINES
The following is an illustration of the initialization of packed data
obtained by modifying the employee table example that was developed
above. When we access a field within a block, it is a common practice
to associate each field reference
(that is, offset, position, and
size) with a field name. So, for example, the field names for the
original employee table would look like:
FIELD EMP =
SET
EMPID = [O,O,%BPVAL,O],
EMP-COST CEN
[l,O,%BPVAL,O],
EMP-NAME-PTR = [2,O,%BPVAL,O];
TES;
These field names can be used in developing an initialization macro,
by
using
parametric values.
This is another example of how
parameterization can be used as a key
technique
in
writing
transportable code.
If the number of bits needed to represent the values of EMP ID and
EMP COST CEN were each known not to exceed 16, we could pack these two
fields into one BLISS value in BLISS-32 and BLISS-36.
In BLISS-16 the
definition of the employee table, as it now stands, would allocate
only 16 bits for each field, since %BPVAL equals 16.
In BLISS-36,
an
18-bit size for these two fields would be chosen, since we know that
both DECsystem-lO and DECSYSTEM-20 hardware have instructions that
operate efficiently on half-words.
If the interest is only in transporting
field declaration would look like:

BLISS-36

and

BLISS-32,

the

FIELD EMP =
SET
EMP ID = [O,O,%BPVAL/2,O],
EMP-COST CEN
[O,%BPVAL/2,%BPVAL/2,O],
EMP-NAME PTR = [l,O,%BPVAL,O];
TES;
Based on these declarations, a macro can be designed that will take as
arguments the initial values and then do the proper packing:
MACRO
EMP INITIAL(ID,CC,NAME)[] =
-IDA%FIELDEXPAND(EMP ID,2) OR
CCA%FIELDEXPAND(EMP-COST CEN,2) ,
NAME PTR ( NAMEA%FIELDEXPAND(EMP_NAME PTR, 2)) %;
The lexical function %FIELDEXPAND simply extracts the
position
parameter of the field name.
The initialization macro, EMP INITIAL,
makes use of this shift value in packing the words.
The goal--here is
to require the user to specify as arguments only the information
needed to initialize the table, and not to specify information that is
part of its representation.
An example of using these macros to initialize packed data follows:
1+

Employee Field Reference macros
1-

7-24

TRANSPORTABILITY~GUIDELINES

FIELD EMP =
SET
EMP ID = [0,0,%BPVAL/2,0],
EMP-COST CEN
[0,%BPVAL/2,%BPVAL/2,0],
EMP-NAME-PTR = [l,O,%BPVAL,O]i
TES;
MACRO
1+
1 Macro to create the shift value from the

position parameter of a field reference macro
1-

SHIFT(X)

%FIELDEXPAND(X,2) %,

1+
1 Employee table initializing macro
1 Three values are required
1-

EMP_INITIAL(ID,CC,NAME)[]
IDASHIFT(EMP ID) OR
CCASHIFT(EMP=COST_CEN),

First value

NAMEASHIFT(EMP_NAME_PTR) %;

1 Second value

Employee table definition and initialization
1-

OWN
EMP TABLE:
-BLOCKVECTOR[NO EMPLOYEES, EMP_LINE_SIZE]
INITIAL( EMP INITIAL(
345,201,
'SMITH PETER',
207,
345,
'JONES PENNY'
) ) ;

What has been illustrated in
the
previous
example
is
the
parameterization
of
certain
values such as field sizes.
In
transporting this program, benefits can be
derived
from
the
localization of certain machine values as in the field definitions.
This code is transportable between BLISS-32 and BLISS-36. To compile
this program with the BLISS-16 compiler,
a change to the field
definitions is needed. The packing macros would no longer be needed,
though they could be used for consistency purposes.
In that case,
they would also need to be changed.
As a final example of initializing packed data, consider the DCB (data
control block) BLOCK structure.
(Details as to what DCB is and how it
accesses data are discussed under "FIELD Declarations
and
BLOCK
Structures"
in the Bliss Language Guide.
Here, we are concerned only
with initializing this type of structure.)
II

7-25

TRANSPORTABILITY GUIDELINES
The DCB BLOCK consists of five fields.
Four of the fields are packed
into one word, their total combined size being 32 bits, and the fifth
field which is 32 bits in length occupies another word.
In this case it is possible to transport the DCB initialization very
easily between BLISS-32 and BLISS-36.
The reason is that the total
number of bits required for each word does not exceed the value of
%BPVAL for each machine.
Hence, in this case at least, we do not have
to modify the design of the BLOCK in any way.
Typically, however, one
would design the structure for each target machine.
One method of
doing this is by placing its definition in a REQUIRE file.
We prefer,
however,
to again use the technique of parameterization. We will
again make use of the field reference macros as we did in the previous
example.
Here is the
initialized.
BLOCKVECTOR.

example describing a method in which
The structure has been extended by
The example:

DCB size parameters
1-

LITERAL

DCB NO BLOCKS = total number of blocks,
DCB SIZE = size of a block;

1+
1
1-

DCB Field Reference macros

FIELD DCB
SET
DCB A
DCB B
DCB C
DCB-D
DCB E
TES;
MACRO

[0,0,8,OJ,
[0,8,3,OJ,
[0,11,5,OJ,
[0,%BPVAL/2,%BPVAL/2,OJ,
[l,O,%BPVAL,OJ;

1+
1 Macro to create the shift value from the
1 position parameter of a
1-

SHIFT(X)

field reference macro

%FIELDEXPAND(X, 2) %,

1+
1 DCB initializing macro.

Five values are required.
1-

DCB INITIALIZE(A,B,C,D,E)[J
AASHIFT(DCB A) OR
BASHIFT(DCB-B) OR
CASHIFT(DCB-C) OR
DASHIFT(DCB-D)

first word
second word

DCB Blockvector definition and initialization
1-

7-26

it could be
making it a

TRANSPORTABILITY GUIDELINES
OWN
DCB AREA:
-BLOCKVECTOR[DCB NO BLOCKS, DCB_SIZE]
INITIAL(
DCB INITIALIZE (
l,2~3,4,
first word
5,
! second word
6,7,8,9,
10, 1 second word

1 first word

Note that this structure could be transported to BLISS-16 by making
suitable changes to the field definitions and the packing macro.
The
only consideration might be whether the last field, DCB_E, did require
a full 32 bits.

7.4.5

Structures and Field Selectors

Two BLISS constructs will be discussed in this section:
structures
and field selectors. While the use of one does not necessarily imply
the use of the other, we will see that for transportability reasons
field selector usage will be confined to structure declarations.
Hence, these two constructs need to be discussed together.
We will begin with a general discussion of structures,
in which it
will be shown that a certain machine specific feature of structures
can be used in a transportable manner.
The best way to illustrate the
process of writing transportable structures is to take the reader
through the intellectual considerations that contribute to its design,
so the development of a transportable structure - FLEX VECTOR - will
be presented. At this point field selectors will be discussed.
Finally, a more general structure, GEN_VECTOR, will be developed.

7.4.5.1 Structures - Structure
declarations
are
sensitive
to
transportability in that one may specify parameters corresponding to
characteristics of particular architectures. Also, in BLISS-32,
the
reserved words BYTE, WORD, LONG, SIGNED, and UNSIGNED have values of
1, 2, 4,
1,
and 0,
respectively,
when used as structure-actual
parameters.
The ability to specify architecture-dependent information can be an
advantage in developing transportable structure declarations.
Later
in this section, a structure will be developed which will use the UNIT
parameter to gain a degree of transportability.
The UNIT parameter
specifies the number of addressable allocation-units in one element of
a homogeneous structure.
This number will be used in determining the
amount of storage that is to be allocated for each element of the
structure.
As
mentioned
repeatedly
in
these
guidelines,
the
prime
transportability problem is differing machine architectures.
The key
to dealing with these differences is the parameterization by the size
of the machine word
(%BPVAL)
the number of bits needed to hold an
address (%BPADDR) and the number of bits occupied by the smallest
addressable unit (%BPUNIT).

7-27

TRANSPORTABILITY GUIDELINES
7.4.5.2 FLEX VECTOR - An application of this is illustrated
by
developing FLEX VECTOR, a structure that will by default, allocate and
access a vector-consisting of only the smallest addressable units.
If
the default value given in the structure declaration is not used, we
want to be able to specify the vector element size will be specified
in terms of the number of bits.
It should be noted that the existing
VECTOR mechanism will not do this.
An example of its use would be to crea-te a vector of 9-bit elements.
The first decision that has to be made in its design is whether or not
each element is to be exactly 9 bits, or at least 9 bits.
For this
example,
we choose the smallest na-tural unit whose size is greater
than or equal to 9 bits.
Since there are no 9-bit conveniently
addressable units on any of the machines, we have a choice of 8, 16,
32 or 36-bit units.
We can see that 9 bits will fit in the only addres3able unit on the
10/20 systems
the word.
On the 11 we will need two bytes or a
16-bit word and on the VAX-II we will again need two bytes.
How then can a structure be developed that will do this allocation and
will also be transportable and usable on the three systems? Clearly
the structure will need some knowledge of the machine architecture.
This is where the role of parameterization comes in.
The predeclared literals have all the information we
only
one set of values is needed:
bits per
(%BPUNIT).

need.
In fact
addressable-unit

The minimum necessary size of a vector element will be one of the
allocation formals (UNIT).
Other formals that will be needed are the
number of elements (N) the index parmeter (I) for accessing the vector
and an indication of whether or not the leftmost bit of an element is
to be interpreted as a sign bit (EXT).
The access and allocation formal list for FLEX VECTOR is:
STRUCTURE
FLEX_VECTOR[ I; N, UNIT

= %BPUNIT, EXT = 1 ] =

Notice that by setting UNIT equal to %BPUNIT the default (if
not specified) will be %BPUNIT.

UNIT

The next step is to develop the formula
for the structure-size
expression.
The expression will make use of the allocation formals
UNIT and N, and in addition, the value of %BPUNIT.
If UNIT were only allowed to assume values of integer multiples of
%BPUNIT
(that is, l*%BPUNIT, 2*%BPUNIT, etc.), only a structure-size
expression of the following form would be needed:
[ N * (UNIT) /

%BPUNIT ]

Dividing the element size (UNIT) by %BPUNIT would give the size of
each element in the vector in terms of an integer multiple.
This
value would then be multiplied by the number of elements to give the
total size of the data to be allocated.
Suppose the structure needs to be more flexible in that it should be
possible to specify any size element (within certain limits).
The
structure-size must be slightly more complex:
[ N * ((UNIT + %BPUNIT - 1»

%BPUNIT ]

7-28

TRANSPORTABILITY GUIDELINES
The structure-size expression now computes enough %BPUNIT's to hold
the entire vector.
The reader should try some values of UNIT for
differing %BPUNIT in order to see how this expression evaluates.
This subexpression:
(UNIT + %BPUNIT - 1) / %BPUNIT
which we will call NO OF UNITS is very important in effecting the
transportability and flexibility of this particular structure.
The
key to transporting this structure is the knowledge that it has of the
value
of a certain machine architectural parameter:
bits per
addressable-unit.
This particular expression makes use of this
knowledge, hence,
it can adapt to any machine.
This subexpression
will be used twice more in the structure-body expression.
The structure-body is an address-expression.
This expression will
consist of the name of the structure (the base address) plus an offset
based on the index I.
In addition, a field selector will be needed to
access the proper number of bits at the calculated address.
The offset is simply the expression NO OF UNITS multiplied by the
index I.
(Remember that indices start at 0). The size parameter of
the field selector is the expression NO OF UNITS multiplied by the
size of an addressable-unit, %BPUNIT.
The structure-body will look
like:
(FLEX VECTOR +
1-* ((UNIT + %BPUNIT - 1) / %BPUNIT»
<0, ((UNIT + %BPUNIT - l)/%BPUNIT)*%BPUNIT,EXT>;
The value of the position parameter in the field-selector
constant
since it always starts at an addressable boundary.

The following table shows the structure
different values of UNIT:

the

three

machines

a
for

VAX-II
UNIT

UNIT

1 to 8

UNIT

= 9 to 16

no storage
FLEX_VECTOR<O,O,l>
[[N * lJJ Bytes
(FLEX_VECTOR + 1)<0,8,1>
[[N * 2JJ Bytes
(FLEX_VECTOR + I *

2)<0,16,1>
UNIT

= 17 to 32

[[N * 4JJ Bytes
(FLEX_VECTOR + I *

4)<0,32,1>
11

° to 16

UNIT

same as VAX-II

10/20

UNIT

= 1 to 36

no storage
(FLEX_VECTOR) <0,0, 1>
[[ N JJ Words
(FLEX_VECTOR +

1)<0,36,1>
7-29

TRANSPORTABILITY GUIDELINES
The above table illustrates that if the default value for UNIT were
set to %BPVAL,
this structure would be equivalent to a VECTOR of
longwords on VAX-II, and a VECTOR of words on the 10/20 and 11
systems.
Elements in a data segment which have this particular structure
attribute are accessed very efficiently because they are always on
addressable boundaries.
Also, they are always some mUltiple of an
addressable unit in length.
If this structure were to access elements of exactly the size
specified,
then only change needed would be the size parameter of the
field selector.
This expression then becomes:
... FLEX VECTOR<O, UNIT>;
This is a less efficient means of accessing data (when UNIT is not a
multiple of %BPUNIT)
because the compiler needs to generate field
selecting instructions in the case of the VAX-II and 10/20 machines
and a series of masks and shifts for the 11.

7.4.5.3 Field Selectors - In the last structure declaration,
it was
necessary to make use of a field selector.
Now, the use of field
selectors in a more general context will be discussed.
The use of field selectors can be nontransportable because they make
use of the value of the machine word size.
The unrestricted usage of
field selectors may cause problems in a program when it is moved to
another machine.
These problems are best illustrated by the following
table of restrictions on position (p)
and size
(s)
for the three
machines:
Machine:
11

10/20

o ~ p

p + s
o ~ s

VAX-l 1

~
~

36
36

p + s
o ~ s

~
~

16
16

o ~ s

From the table we can see that:
•

The most restrictive is the 11.

•

The moderate restrictions are -those of the 10/20.

•

The least restrictive is VAX-ll.

In order to ensure the transportable use of field selectors, we would
have to abide by the set of restrictions imposed in BLISS-16.
These
are restrictions imposed by the values of p and s.
There is also a
contextual restriction on the use of field selectors.
The following
guideline should be followed:
•

Field selectors may appear
user-defined structures.

7-30

only

the

definition

TRANSPORTABILITY GUIDELINES
Restricting the domain of field selectors to structures isolates their
use.
Field selectors should be isolated so that:
•

Changes in data structure design are easier.

•

Machine dependencies may easily be placed in REQUIRE files.

•

Complex coding making heavy use of the predeclared literals is
limited to declarations.

Another transportable structure will be developed which
affected by the table of field selector value restrictions.

will

7.4.5.4 GEN VECTOR - The reader has probably noticed that FLEX VECTOR
does not attempt to pack data.
Using the example of 9-bit elements,
it is evident that there will be some wasting of bits - from 7 bits on
the 11 and VAX-II to 27 on the 10/20 systems.
A variation of FLEX VECTOR can be developed which will provide a
certain degree of packing.
For example, in the case of 9-bit elements
it would be possible to pack at least four of them into a 10/20 word
and three into a VAX-II longword.
This structure, which will be named GEN VECTOR,
will pack as many
elements as possible into a BLISS value and so will make use of the
machine specific literal %BPVAL.
But, since allocation is in terms of
%BPUNIT,
a
literal will be needed that has as a value the number of
allocation units in a BLISS value.
This literal has been predeclared
for transportability reasons and has the name %UPVAL, and is defined
as %BPVAL/%BPUNIT.
Elements will not cross word boundaries. This constraint is because
of the restrictions placed on the value of the position parameter of a
10/20 and 11 field selector.
For the same reason elements cannot be
longer
than %BPVAL,
as given in the table of field selector
restrictions above.
As in FLEX VECTOR, the allocation expression of GEN VECTOR will need
to calculate the number of allocation units needed by the entire
vector.
This will again be based on the number of elements
(N)
and
the size of each element
(S).
But because the elements will be
packed, the expression will be slightly more complicated.
The first value is the number of elements that will
value.
The expression:

fit

BLISS

(%BPVAL/S)
will compute this value. Given this, to obtain the number of BLISS
values or words needed for the entire vector, divide this value into
N:
(N/(%BPVAL/S))
This is the total number of values needed.
However,
data is not
allocated by words on both of the machines. Multiplying this value by
%UPVAL will result in the number of allocation units needed by the
vector:
«N/(%BPVAL/S))*%UPVAL)

7-31

TRANSPORTABILITY GUIDELINES
For clarity's sake and because this expression will be used again,
will be expressed as a macro with Nand S as parameters:
MACRO
WHOLE_VAL(N,S)

((N/(%BPVAL/S))*%UPVAL)%~

The name of the macro suggests that it calculates the number of whole
words needed.
If, in fact, N were an integral multiple of the number
of elements in a word then this macro would be sufficient for
allocation purposes.
since this is not known in advance, another expression to calculate
the number of allocation units needed for any remaining elements is
needed.
The number of elements left over is the remainder of the last
division in this expression:
(N/(%BPVAL/S))
The MOD function will calculate this value, as follows:
(N MOD (%BPVAL/S))
Multiplying this value by the size of each element
number of bits that remain to be allocated:

gives

the

total

(N MOD (%BPVAL/S)) * S
This value will always be strictly less than %BPVAL.
For the same
reasons outlined above this expression will be expressed as a macro
with Nand S as parameters:
MACRO
PART_VAL(N,S)

((N MOD (%BPVAL/S)) *

S)%~

PART VAL computes the number of bits allocated in the
word-:

last

(partial)

Taking this value, adding a
fudge factor
and then dividing by
%BPUNIT gives us the number of allocation units needed for the
remaining bits:
ll

(PART_VAL(N,S) + %BPUNIT -l)/%BPUNIT
The total number of allocation units
structure allocation expression is:

has

been

calculated

and

the

[WHOLE VAL(N,S) +
(PART_VAL(N,S) + %BPUNIT - l)/%BPUNIT]
As it works out, the structure-body expression for GEN VECTOR will be
simple to write because of the expressions that have already been
written.
The accessing of an element in GEN VECTOR requires that an address
offset be computed which is then added to the name of the structure.
This offset is some number of addressable units and is a function of

7-32

TRANSPORTABILITY GUIDELINES
the value of the index I.
The expression which will
number of addressable units is the macro WHOLE VAL.
part cf the accessing expression is:

calculate this
Thus, the first

Note that the macro was called with the index parameter I.
This expression will result in the structure being aligned on some
addressable boundary.
But since the element may not begin at this
point (that is, the element may be located somewhere within a unit
%BPVAL bits in length), one more value is needed.
That value is the
position parameter of a
field selector.
The macro PART VAL will
calculate this value based on the index I:
<PART_VAL(I,S),S,EXT>
The size parameter is the value S.
The position parameter
calculated at run time, based on the value of the index I.
This completes the definition of GEN VECTOR.
is:

The

entire

will

declaration

STRUCTURE
GEN_VECTOR[I;N,S,EXT=I]
[WHOLE VAL(N,S) +
(PART_VAL(N,S) + %BPUNIT - l)/%BPUNIT]
(GEN_VECTOR + WHOLE_VAL(I,S»
<PART_VAL(I,S),S,EXT>;
The reader should compile this structure
BLISS-16, BLISS-32 and BLISS-36.

and

see

how

works

7.4.5.5 Summary - No claim is made that either of
these
two
structures will solve all the problems associated with transporting
vectors.
Many such problems will have interesting and
unique
solutions.
BLOCKS or BLOCKVECTORS have not been discussed, but it is
hoped that the reader will get from the examples a
feeling for the
techniques involved in transporting structures.
There is no easy solution to transporting data structures. One should
consider,
when developing data structures,
the machines that the
program or system is targeted for and make full use of the predeclared
literals such as %BPUNIT.
This exercise in the development
illustrated two points:
.
•

Parameterization

•

Field selector usage

transportable

structures

has

By parameterizing certain machine-specific values and by taking full
advantage of the powerful STRUCTURE mechanism,
two transportable
structures have been developed.
The accessing of odd (not addressable) units of data is accomplished
by the use of field selectors.
The field selector should only be used
in structure declarations.

7-33

CHAPTER 8
COMPILER OVERVIEW AND OPTIMIZATION SWITCHES

This chapter provides an overview of the BLISS compiler organization
and processing.
The material presented here assumes that the reader
has a general understanding of compiler theory and practice.
It need
not be understood for normal use of the BLISS language and compiler.
Some of the switches described in
connection
with
"SWITCHES
declaration"
in the Bliss Language Guide provide specialized control
over the processing of the compile~specially in the area of
optimization.
This section provides the basis for a more detailed
understanding of these switches.
The switches that are described are:
CODE and NOCODE
OPTIMIZE and NOOPTIMIZE
OPTLEVEL
SAFE and NOSAFE
ZIP and NOZIP
Table 1-1 shows command qualifier relationships to these switches.

8.1

COMPILER PHASES

The compiler is organized conceptually into seven major phases:
LEXSYN
FLOW
DELAY
TNBIND
CODE
FINAL
OUTPUT

Lexical and syntactic analysis
Flow analysis
Heuristics
Temporary name binding (register allocation)
Code generation
Code stream optimization
Object file production

This division of the compiler into conceptual phases corresponds only
approximately to the actual compiler.
In some cases, a phase actually
consists of two or more subphases.
In other cases,
phases are
combined in the implementation.
This level of detail is not important
in the following discussion of the phases.
Simply note that the term
"phase" should not be taken literally.

8.1.1

Lexical and Syntactic Analysis

The lexical and syntactic
following functions:

analysis

phase,

LEXSYN,

•

Reads the input files .

•

Divides the source character text into lexemes.

8-1

performs

the

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES
and

performs

lexical-functions

and

macro

•

Identifies
expansions.

•

Parses the resulting input lexeme sequence and
creates
appropriate symbol table entries for declarations and tree
representations for expressions.

The BLISS compiler reads the source text once and uses it to create an
internal representation of the module.
In this sense, the BLISS
compiler is a I-pass compiler.
On the other hand, at the end of each
(ordinary or global) routine definition, the remaining phases of the
compiler are performed in turn to analyze and completely produce and
output code
for that entire routine.
In this sense, the BLISS
compiler is a multi-pass compiler.
If the NOCODE switch is specified,
the compiler operates
in a
"syntax-only" mode,
in which the LEXSYN phase does not produce the
tree representations for expressions and the
later phases are not
performed:
moreover,
if an error (as contrasted with a warning) is
detected and reported by the compiler,
the compiler automatically
enters syntax-only mode as if NOCODE had been specified.
Syntax-only mode is useful for initial-checking of a
newly created
module.
There is an important limitation in this mode, however, in
that some errors cannot be detected. This is due to the fact
that
some errors are only detected and reported by later phases of the
compiler and these phases are not performed.
The difference between an error and a warning diagnostic is based on
the seriousness of the effect of the error upon the internal
representation of the program used by the compiler.
(It is not a
value judgment upon the nature of the programmer's mistake.)
In most cases, the compiler can recover and proceed with normal
compilation.
This permits further errors, if any, to be detected and,
in some cases, may permit the resulting object module to be used for
execution time debugging before the source module is corrected and
recompiled.
Errors from which the compiler can continue normally are
reported as warning diagnostics.
In some cases, the effect of a user error is to make the compiler's
internal representation of the module inconsistent or otherwise
unreliable for continued use.
Such errors are reported as error
diagnostics.
Depending on the circumstances, the same apparent user error
(same
diagnostic information) may be reported as a warning in one case but
as an error in another.

8.1.2

Flow Analysis

The flow analysis phase,
FLOW,
examines
the
internal
tree
representation of a
complete routine and performs the following
functions:
•

Identifies expressions that appear more than once in the
source,
but
that will produce the same value
{common
subexpressions}.
Such expressions need be evaluated only once
during execution and the result used several times, thereby
saving execution time and code space.

8-2

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES
•

Identifies expressions contained in loops whose values will be
the same on each iteration of the loop.
Such expressions may
be evaluated once before starting the loop and the result used
during each iteration, thereby saving execution time.

•

Identifies expressions that occur on all alternatives of the
IF,
CASE, and SELECTONE expressions.
Such expressions may be
evaluated once before or after the multiple alternatives,
thereby saving code space.

More generally, the FLOW phase identifies possible alternative ways of
evaluating a routine, which might be more efficient in time or space
or bO~l. Note that the next phase determines which alternative is
actually used; the FLOW phase only identifies the possible choices.
If OPTLEVEL is specified with a value of 0 or 1,
the flow analysis
phase is totally skipped. A consequence of skipping flow analysis is
that the OPTIMIZE and SAFE switches have no effect,
because OPTIMIZE
and SAFE control aspects of how flow analysis is done.
However, if
OPTLEVEL is specified with a value of 2 (the default) or 3,
the flow
analysis phase is performed and the OPTIMIZE and SAFE switches have
the effects described below.
To understand the effects of the OPTIMIZE and
first necessary to understand more about
performed.

SAFE switches,
it
how flow analysis

is
is

the
8.1.2.1 Knowing When a Value Changes - One operator in BLISS,
assignment operator,
can change the contents of a data segment.
However, routine calls can also change the contents of data segments
because they can contain assignments.
For each assignment, the compiler examines the left operand expression
and attempts to determine the name of the data segment whose contents
will be changed by the assignment.
(The case where no name can be
determined is considered below.) The same analysis is performed for
each actual parameter that appears in a routine call.
In effect,
the
compiler treats each actual parameter as though it did appear as the
left operand of an assignment.
In addition to this, for each routine
call the compiler determines the names of all OWN and GLOBAL data
segments that the called routine might change and assumes that all of
them are changed.
Machine specific functions are treated as normal routine calls, except
that the compiler has more detailed information about which parameters
can cause changes and which cannot.
Several aspects of this analysis process are illustrated using
examples.
In these examples the following declarations are assumed:
OWN
X: VECTOR[lO],
Y,
Z;
EXTERNAL ROUTINE
F;
First, consider the following sequence of assignments:
I

= 3;

Y =

X[7]

.X[.I];

= .X[.Y];

Z = .X[.I]+l;

8-3

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES
In the third line, the assignment to X[7] is assumed to change all of
the data segment identified by X. As a consequence, the possible
common subexpression .X[.I] is not recognized by the compiler.
(However, note that the common sUbexpression X[.I], which computes the
address of the i'th element of X, is recognized since the assignment
to X cannot affect this value.)
In the above example, it may seem apparent exactly what part of X is
changed,
but in most cases it is difficult or impossible for the
compiler to determine what part of a named data segment changes and
what part does not change.
Another aspect is illustrated with this example:

= 11:
= .z:

X[ll]

In the first line, the assignment to X[ll] actually modifies the
contents of Z.
(Recall that X was declared as a vector of 10 elements
numbered 0 through 9). The compiler analysis does not determine that
storage other than the storage for X is being changed because the
analysis is based completely on the names that occur in
the
expression.
As a consequence, the compiler may inappropriately use
the previous contents of Z in the assignment to Y.
This would happen,
for example,
if the expression.Z were a common sUbexpression used
frequently enough to result in the contents of Z being copied into a
register for more efficient access.
Both of these examples emphasize the importance of the
reference storage in the analysis performed by FLOW.

name

used

Now consider the case where a
name cannot be identified for the
storage being changed.
This is the case in the following example:
Z

= F():
= 3:

In the second line, no name of a data segment can be determined.
In
such a case, the compiler assumes (by default) that no named storage
has changed.
This assumption is justified because ir- is virtually
always the case that such indirect assignments are used to change the
contents of the following:
•

Dynamically created data structures that do not have names

•

Data segments passed as parameters of routine calls and that
cannot be referenced in the called routine by the name used to
allocate the storage

The NOSAFE switch may be used to override the default assumption
described above.
(SAFE is the default).
If NOSAFE is specified, the
compiler assumes that indirect assignments do change some named data
segment.
Because it is nearly always impossible to identify the data
segment that is changed, this assumption is guaranteed by making the
even stronger assumption that all named data segments are changed.

8.1.2.2 Accounting for Changes - The BLISS
language
definition
intentionally leaves unspecified the order of operand evaluation in
operator expressions in order to permit maximum optimization by the
BLISS compiler.
For example, the expression
F(X) + .X

8-4

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES
may be evaluated first,
by calling F with the address X as a
parameter~
second, by fetching the contents of X~ and finally, by
performing the addition.
It might also be evaluated first,
by
fetching the contents of X:
second, by calling F: and so on. The
compiler uses information about the entire routine in which the
expression is contained to choose alternatives.
Since the routine
call F'(X) may change the contents of X, the question becomes:
When
does the compiler take the (potential) change into effect?
It does
not make sense to take this into account within the expression without
also specifying precisely the order of evaluation.
It makes sense to
account for changes only at points in the language where the order of
evaluation is specified.
Points at which changes are taken into
account are called mark points.
Mark points in BLISS are summarized
in the following diagram, where 11111 is used to point to the mark point
within the language syntax on the subsequent line.
Mark Points
BEGIN exp

I·· . END

IF exp THEN exp ELSE exp
WHILE exp DO exp
DO exp WHILE exp
INCR name FROM exp TO exp BY exp DO exp
CASE exp FROM ctce TO ctce OF SET [

...

J: exp

SELECT exp OF SET [ exp TO exp " .. J: exp

I·· . TES

The most common mark point in most programs is the semicolon,
which
separates expressions in a block or compound expression.
For example,
consider the following:
BEGIN
Y
.X+2 ~
Z = .X+2+F(X);
W = .X+2
END
In the second line, the content of Y is changed.
This change is taken
into account by the compiler when the semicolon is encountered.
In
the third line, .X+2 computes the same value as
.X+2 in the second
line;
thus,
.X+2 is a cornmon sUbexpression of the second and third
lines. Also in the third line, the content of Z is changed and the
call F(X)
is considered to change the content of X.
As discussed
above, these changes are not taken into account until the semicolon is
encountered.
In the fourth line, .X+2 must be recomputed because of
the change of the content of X in the third line; it is not a
common
sUbexpression with the previous occurrences.

8-5

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES
The effect of the OPTIMIZE switch is now easily stated.
If OPTIMIZE
is specified
(the default)
full flow analysis is performed.
If
NOOPTIMIZE is specified, at every mark point all data segments are
assumed to change.
As a consequence, common sUbexpression values
computed by one expression are not reused in later expressions
the
value is computed again.
Expressions that have a constant value
within a loop are not computed once before the loop is started;
the
value is recomputed during each iteration of the loop. And similarly,
other kinds of "code motion" optimizations are not performed.
However, specifying NOOPTIMIZE is not equivalent to specifying that no
flow analysis is performed,
since common sUbexpressions that occur
between markpoints are still detected.
For example, in the expression
Y = (.X*2)+F( .X*2)
the sUbexpression .X*2 is computed once and the resulting
twice, even when NOOPTIMIZE is specified.

8.1.3

value

used

Heuristics

The heuristic phase, DELAY, further analyzes the routine to obtain
general information about the routine.
Some of this information is
used by DELAY itself to make optimization decisions, and some is made
available for use by later phases.
DELAY performs the following
functions:
•

Evaluates the effectiveness of the alternatives identified by
FLOW
and
chooses the best alternative.
This analysis
considers, for example, the number of occurrences of a
common
sUbexpression
and
the
potential for using specialized
operations available in the address parts of instructions (for
example, indirection and indexing).

•

Identifies sets of subexpressions that occur only once
(that
is,
are not common sUbexpressions) that should be computed in
the same temporary location (whether a
register or memory),
thereby maximizing the use of 2-operand (as contrasted with
3-operand) instructions.

None of the switches affect the operation of the DELAY phase.

8.1.4

Temporary Name Binding

The temporary name binding phase, TNBIND, determines where each value
computed during the execution of a routine should be allocated. This
phase corresponds to what is sometimes called register allocation in
other compilers.
It is somewhat more general in that it considers and
allocates user declared local variables together with compiler-needed
temporary locations in an integrated way.
TNBIND performs the
following:
•

Determines the lifetime (that is, the first and last uses)
each temporary value in the routine.

•

Estimates the difference in compiled code cost of allocating
each temporary value in a register versus in memory (on the
stack) .

8-6

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES
•

Uses cost information to rank temporary values to determine
the most important ones to be allocated in a register.

•

Proceeding from most important to least important,
allocates
the temporary values.
More than one temporary value may be
allocated in the same location, provided their lifetimes do
not overlap.
(Thus,
it is possible for a less important
temporary to be allocated in a register even though a more
important one is not: its shorter lifetime could permit it to
II fi t . II )

The measure of importance used (normally) by TNBIND is
based
completely on minimizing the overall size of the code generated for
the entire routine.
The ZIP switch modifies the importance measure.
If ZIP is specified,
temporary values used within loops are given increased importance.
The greater the degree of loop nesting, the greater the importance.
Thus, temporary values used in loops become more likely to be
allocated in registers. As a consequence, code within loops tends to
execute faster, even though the overall size of the routine may become
larger.

Code Generation

8.1.5

The code generation phase, CODE, processes the tree and generates
instructions.
Since the allocation for each operand of a node and the
result location of each node have already been determined by TNBIND,
CODE selects the locally best code sequence consistent with those
requirements.
The /DEBUG qualifier modifies code generation as follows:
•

A frame pointer (FP) is materialized and the
saved on the stack.

caller's

•

Routine parameters are popped from the stack after the routine
call.

•

Routine entries and exits are marked with a DEBUG UUO.

Code Stream Optimization

8.1.6

The code stream optimization phase, FINAL, processes the code stream
produced by CODE and makes further optimizations at the machine code
level. The optimizations performed include:
•

Peephole optimization:
One sequence of instructions
replaced with an equivalent shorter sequence.

•

Cross-jumping:
Identical sequences of code that flow
common instruction are merged into a single sequence.

into

The OPTLEVEL switch may be used to eliminate some
of
these
optimizations.
The result is code that more clearly follows the
organization of the source program.
This may be helpful during
debugging or when the generated code must be understood in detail.

8-7

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES
8.1.7

Output File Production

The output file production phase, OUTPUT, transforms the code stream
It also
into object module format and outputs it to the object file.
formats and outputs the listing file information.
If the DEBUG switch is specified, symbol table information for use by
the DEBUG system utility is included in the object module.
If NODEBUG
is specified (the default), no symbol table information is produced.

8.2

SUMMARY OF SWITCH EFFECTS

The previous sections have described the phases of the compiler and
the
switches that affect each of those phases.
This section
summarizes the effects of each switch throughout the compiler.
Switch Name

Phase

Effect

CODE

LEXSYN

NOCODE specifies syntax-only processing~
the other phases are not invoked.

OPTIMIZE

FLOW

If
flow
analysis
NOOPTIMIZE specifies
across mark points.

OPTLEVEL

FLOW
FINAL

is
performed,
do not optimize

° and 1, flow analysis is not
At levels ° and 1,
cross-jumping and
branch chaining are not performed. At
At levels
performed.

level
0,
non-adjacent
peephole
substitutions are not performed.
SAFE

FLOW

If flow analysis is performed,
NOSAFE
specifies
that indirect changes are
assumed to change all storage.

ZIP

TNBIND

ZIP specifies that data segments used in
loops
are
to
be
given increased
importance
in
determining
register
allocation.

The OPTLEVEL switch is a composite switch that includes appropriate
settings of the other switches in an ordered way.
It can be specified
in either the command line or module head or both. The rule applied
to determine which switch setting has effect is that the most recent
switch setting specified has effect allowing the other switches (SAFE,
OPTIMIZE,
etc.)
to override OPTLEVEL at any time.
In a multi-module
compilation, each module begins with the setting defined in the
command line and OPTLEVEL=2 if OPTLEVEL has not been specified in the
command line.

8-8

COMPILER OVERVIEW AND OPTIMIZATION SWITCHES

Optimizations performed at each setting of the OPTLEVEL switch are:
Optimization

OPTLEVEL

* 1.
* 2.
3.

4.
5.
6.

* 7.
* 8.
* 9.

Common subexpression detection
Code motion out of loops, etc.
Targetting/preferencing to
temporaries
Cross-jumping
Multiple POPJs (instead of only one
return point)
Peepholes
"SAFE" optimizations
"OPTIMIZE" over mark points (for example,
"ZIP" speed/space tradeoff
(faster but possibly larger)

;)

X
X

X
X
X

X
X
X
X

Key

* - Another switch can control this optimization separately
X - Allowable optimization
+ - Allowed
with increased freedom
- - Allowed -- with certain restrictions

8-9

CHAPTER 9
TOOLS, LIBRARIES, AND SYSTEM INTERFACES

A number of programming tools, libraries, and system interfaces are
distributed with the BLISS-36 compiler for use by BLISS programmers.
This chapter briefly describes what is available with BLISS-36 V3.
Note that the BLISS tools (utility programs) and system interfaces
described here are not supported products at the time of writing.

9.1

TRANSPORTABLE PROGRAMMING TOOLS (XPORT)

XPORT is a collection of transportable source-level programming tools
for use with the BLISS language. XPORT tools may be commonly applied
across all BLISS target systems to provide such things as:
extensive
input/output facilities;
a uniform interface for obtaining operating
system services (such as dynamic memory); and aids to data structuring
and string handling.
The XPORT package consists of five components:
XPORT
XPORT
XPORT
XPORT
XPORT

Data Structures
Input/Output Facilities
Dynamic Memory Management
Host System Services
String Handling Facilities

Each component provides tools which ease the task of interfacing a
BLISS program with the operating system under which it will run.
Therefore, the primary purpose of the XPORT package is to provide
tools and interfaces which behave exactly alike in all system
environments,
and thus provide
transportable
operating
system
interfaces.
Programs written in Common BLISS (which use XPORT services
in the
manner prescribed) can be developed and debugged on one system and run
on any other BLISS-supported system without change.
An additional benefit of using the XPORT package for BLISS programs,
even if they do not require transportability, is the advantage in
using the simplified XPORT interface as opposed to more powerful and
complicated host system interfaces.
A description of each XPORT component follows;
however,
for a more
detailed explanation of XPORT and its services refer to the XPORT
Programmer's Guide.

9-1

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
9.1.1

XPORT Data Structures

The XPORT structure-definition facility is a collection of macros that
allow a programmer to define efficient BLOCK structures in a manner
that is both convenient and primarily system-independent.
The
facility primarily consists of a replacement for the standard BLISS
FIELD declaration, using the keyword $FIELD.
The structure-definition facility allows a programmer to name the kind
of field required for each block component, instead of specifying its
position and size. A field-type
(such as,
SHORT INTEGER, ADDRESS,
BYTE) implies not only the size but also the alignment and required
sign extension mode.
The XPORT data structure facility also provides the following
features:

support

FIELD SET SIZE

Calculates the size of a block defined by $FIELD.

ALIGN

Forces a specified
subsequent field.

OVERLAY

Allows for overlayed field definitions.

CONTINUE

Terminates field overlaying.

LITERAL/DISTINCT

Creates a set of distinct integer literals.

SHOW

Controls the display of XPORT generated
definitions, values, and messages.

SUB FIELD

Provides a means of referencing a field
substructure of a block.

9.1.2

mode

alignment

for

field

within

XPORT Input/Output

XPORT input/output is a general-purpose,
system-independent service
that supports sequential I/O operations in record, character stream,
and binary mode, and provides basic file functions.
This facility
actually consists of several separate I/O packages, each being written
for a specific operating system and file system. However, the program
interface to each package is identical. Thus, a transportable I/O
interface is provided for programs written in common BLISS or any
other transportable language.
The XPORT I/O facility
manipulation functions:
OPEN

performs

the

following

and

I/O

Prepares a file for reading (input) or writing
output file may be optionally created.

file

(output).

Terminates the processing of an input or
including the flushing of any I/O buffers.

DELETE

Deletes an existing file.

RENAME

Changes the name of an existing file.

9-2

output

file,

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
BACKUP

Provides a mechanism for preserving a copy of an input
file when a program creates a new version of that file.
This capability is typically
used
by
editor-type
applications.

PARSE

Parses a host system
component parts.

GET

Returns the length and address of the next sequential
logical
record
read from an input file.
Logical
concatenation of several input files can be automatically
performed when an intermediate end-of-file is reached.

PUT

Writes a single logical
file.

9.1.3

file

specification

record

into

opened

its

output

XPORT Dynamic Memory Management

The XPORT dynamic memory management facility
functi.ons:

provides

the

GET MEM

Allocates a specified amount of dynamic memory.

FREE MEM

Releases an allocated element of dynamic memory

9.1.4

following

XPORT Host System Services

The XPORT host system services are a set of routines that perform
commonly needed host system functions in a transportable manner. The
functions provided are as follows:
PUT MSG

Routes a message sequence to the standard output
error devices, based on a message severity code.

and/or

TERMINATE

Terminates program execution after
termination message.

user

9.1.5

sending

the

XPORT String Handling Facilities

The XPORT string handling facility provides a programmer with the
ability to transportably manipulate character strings. Small control
structures (modeled after the VAX/VMS descriptor convention) are used
to facilitate the exchange of character data between procedures.
The following descriptor classes are provided:
FIXED

Describes
location.

string

BOUNDED

Describes a buffer that contains a variable length
string.

DYNAMIC

Describes a moveable string, the length
is subject to variance.

DYNAMIC BOUNDED

Describes a moveable buffer
variable length string.

9-3

with

fixed

that

length

and

which

contains

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
The following functions are used to manipulate a
associated string:

descriptor

and

its

DESCRIPTOR

Creates and initializes a descriptor in
OWN
storage, or creates a descriptor in LOCAL storage.

DESC INIT

Dynamically initializes a
LOCAL storage.

COpy

Copies a source string to a target
appropriate truncation and padding.

APPEND

Appends a source string to a target string.

EQL,NEQ,LSS,
LEQ,GEQ,GTR

Compares the values of two strings
to the ASCII collating sequence.

SCAN

Locates a specific sequence of characters
(FIND
mode), matches a stream of characters (SPAN mode),
or searches for one character of a set
(STOP
mode) .

CONCAT

Concatenates two
logical string.

FORMAT

Centers,
left justifies,
right
converts a string to upper case.

ASCII

Produces an ASCII
binary field value.

BINARY

Converts an ASCII string value to a binary value.

descriptor

strings

string

OWN

with

string

according

single

justifies,

representation

or
of

The XPORT string handling facility also extends the descriptor concept
to include binary data; whereby, the four descriptor classes (FIXED,
BOUNDED, DYNAMIC, and DYNAMIC BOUNDED) are used to describe a data
item instead of a string,-while two of the descriptor manipulation
functions (DESCRIPTOR, DESC INIT) are used to create and intitialize
the binary data descriptors~

9.2

BCREF - BLISS MASTER CROSS REFERENCE PROGRAM

The BCREF program is a global cross-reference utility that is used to
merge cross-reference files (.CRF), for an entire system of modules,
and create a master cross-reference listing file (.LIS).

9.2.1

Command-Line Format

BCREF command lines use the following syntax:
=>10
.R BCREF
*{output-spec}=input-spec, ... {switch ... }
=>20
@BCREF
BCREF>input-spec, ... {/OUTPUT:output-spec){switch ... )

9-4

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
The default file extensions are:
input-spec:
output-spec:

.CRF
.LIS

Note t~hat the input-list option is a comma list
input-file-specs (filename.CRF) to be merged.

cross-referenced

Note that by default the output-file-name (filename.LIS) will be the
same as that of the first input-file-name (filename.CRF) on the list.

9.2.2

Command Semantics

The master cross-reference output file (.LIS) provides a merge-module
listing that is similar to the module-specific listing produced by the
compiler (see Section 3.2.5). The differences are:
The compiler listing header does
• module-specific
header does.

not

module name in which a symbol is
• The
the symbol name.
•

9.2.3

however,

appear:
declared

The size of the module name field
reflects
possible module name in the merged system.

the

appears

after

the

longest

Building a Master Cross Reference

A master cross reference is an alphabetic listing of all user
identifiers contained in a group of modules.
For each identifier, the
listing contains the names of modules and the line number within each
module when that identifier occurs.
You produce the listing by
creating cross-reference files (.CRF) for each module and merging the
files to produce a single output file (.LIS).
The following command sequences
cross-reference file FILES. LIS.

can

used

create

master

==> 10

.R BCREF
*FILES=FILEA,FILEB

* .. C

==>20

@BCREF
BCREF>FILEA,FILEB=FILES

9.2.4

Command Switches

The bcref-switches indicate what can be included or excluded from
master cross-reference listing (* = default).

the

/MULTIPLE
/NOMULTIPLE*

Include all similar-type multiple references
symbols occurring on the same source line.

/HEADER*
/NOHEADER

Include
page
header
cross-reference listing.

9-5

for

the

master

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
/LOG*
/NOLOG

Provide informational messages
BCREF data file merge process.

/OUTPUT:file-spec

Specifies output file for TOPS-20.

9.3

relating

the

CVTI0 - BLISS-I0 TO BLISS-36 CONVERSION PROGRAM

CVTIO is a tool for converting BLISS-IO source text into BLISS-36.
CVTIO is designed to do a large percentage of the syntax conversions
and some smaller set of other conversions.
Since CVTIO is not a
compiler,
it is limited in -the completeness of translation as well as
in the number of ways certain legal constructs can be written and
still get transformed.
CVTIO assumes that the input compiles correctly with the BLISS-IO
compiler.
CVTIO is written in the SITBOL version of SNOBOL. This
section describes the internal design of the CVTIO program to help fix
a bug or add a transformation that will aid a conversion process.

9.3.1

CVTI0 Command-Line Syntax

CVTIO prompts for both
execution by typing:

input

files

and

outputs.

CVTIO

commences

INPUT FILE NAMES SEPARATED BY SPACES
If no file-spec is
At this point the user can enter input-file-specs.
specified,
input is taken from the terminal.
If more than one
file-spec is specified, multiple translations occur.
CVTIO next prompts:
OUTPUT FILE NAMES
The user should now enter exactly as many output-file-specs as there
were input-file-specs. The first input-file is translated and becomes
the first output-file; the second input-file is translated and becomes
the second output-file: and so on.
If no file-spec is specified, the
output goes to the terminal, in which case, input can come from either
the terminal or a single input-file.
The file-specs have the following format:
{device:} filename.extension {[project,programmer-number]}
An example of a CVTIO command-line sequence follows.
RUN CVTIO
INPUT FILE NAMES SEPARATED BY SPACES
MAIN.BIO SUBR.BIO
OUTPUT FILE NAMES
MAIN.B36 SUBR.B36
INPUT FILE NAMES SEPARATED BY SPACES
~C

9-6

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
9.3.2

BLISS-IO Translations

CVTIO attempts to translate most constructs found in
BLISS-IO
programs.
However,
no conversion is attempted for some features of
the BLISS-IO language.
It is important to realize that CVTIO is
sensitive to both the format and complexity of the source. Table 9-1
lists the language features of BLISS-IO in three categories, according
to what degree CVTIO attempts conversion.
If CVTIO detects syntax that it cannot properly correct,
it usually
prints a warning to that effect.
However, it is important to check
over the translation for constructs that may cause problems.
Table 9-1: BLISS-IO Language Features
Conversion Attempted

! and % comments
quo1:ed string
BIND
EXTERNAL
FORWARD
GLOBAL
GLOBAL BIND
GLOBAL ROUTINE
ROUTINE
LOCAL
MACRO
MAP
MODULE
OWN
REGISTER
REQUIRE
STACKLOCAL
octal constants

No Conversion Needed

No Conversion
Attempted

DO WHILE/UNTIL
INCR/DECR
LABEL
LEAVE

LINKAGE
SIGNAL/ENABLE
PSECT/CSECT
NOVALUE
SCANx
REPLACEx
COPY
INCP
FIRSTONE
OFFSET
EXIT
GLOBALLY
INDEXES
NAMES

string type keywords
[(JASCII, ASCIZ, RADIX50,
SIXBIT[
quoted strings
[(J'AB?M?J ->
%STRING[(J ' AB ' ,%CHAR(13),)
%CHAR(lO)[
CASE
SELECT

)

When encountered, four special comments cause CVTIO
action:

]

take

special

!CVTCOM

Make all input lines that follow into comments.
This is
used to save the original BLISS-IO code as a comment when
different code has been added.

!MOCTVC

Turn off the effect of !CVTCOM.

9-7

Process source normally.

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
lCVTEXT

Treat all input that follows as if it was BLISS-36 code
that had been conunented out.
Remove the conunent character
(1) and output each line without further change.

1TXETVC

Turn off the effect of lCVTEXT.

Process source normally.

The following sections describe the restrictions associated
various language feature conversions.

with

the

9.3.2.1 Normal
Declarations - The
following
declarations
are
translated:
EXTERNAL,
FORWARD,
GLOBAL,
ROUTINE,
GLOBAL ROUTINE,
LOCAL, MAP, OWN, REGISTER, AND STACKLOCAL. Several identifiers may be
declared in the same declaration. A declaration can span multiple
lines.
However, each identifier must have i,ts whole declaration on a
single line, or the translation will be done incorrectly.
A heuristic trick used when the end cannot be found is to check to see
if there was an attempt to initialize the symbol.
If so, 'INITIAL' is
put out before the next line is processed.
Here is an example of the heuristic:
BLISS-IO Input

BLISS-36 Translation

OWN X[5],Y,Z[3]= (2,

OWN
X: VECTOR[5],
Y,
Z: VECTOR[3] INITIAL (2,

1,
6) ;

9.3.2.2 REQUIRE Declarations - The file specifications must be on the
same line as the 'REQUIRE' reserved word.

9.3.2.3 SWITCHES Declarations - The entire line on which any SWITCHES
declaration occurs is removed from the program. Thus, to avoid error,
the SWITCHES declaration must be completely contained on a single
line.
No other code can occur on the same line as a SWITCHES
declaration.

9.3.2.4 BIND Declarations - BINDs to other than PLITS or UPLITS
be completely defined on a single line.
Thus:

must

BIND DVSTRC Z = FRNAM;
translates properly, but the following does not:
BIND DVSTRC Z =
FRNAM;
BINDs to PLITs and UPLITs can span many lines, but they must be the
last definition in the BIND declaration.
This means you can have only
one PLIT binding in each BIND declaration.

9-8

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
9.3.2.5 ROUTINE Declarations - If a ROUTINE
(or GLOBAL ROUTINE)
declaration contains a linkage attribute, the following must be all on
one line:
•

ROUTINE (or GLOBAL ROUTINE) keyword(s)

•

Linkage attribute

•

Routine parameter list

•

Equals sign

As an example, in BLISS-IO
ROUTINE FORTRAN START (A,B,C)=
would be translated into BLISS-36 as:
ROUTINE START (A,B,C) : FORTRAN
but the following is invalid:
ROUTINE FORTRAN START
(A,B,C)

9.3.2.6 SELECT Expressions - CVTIO does not
parse
the
SELECT
expression.
It simply makes note of what is going by on a line by
line basis.
After the NSET is encountered, each colon signals that
the characters that precede it on that line constitute the SELECT
labels. Nothing can precede _a SELECT label on its line.
The SELECT
label must be on the same line as the colon that follows it.
Examples
lBLISS-lO

BLISS-36

SELECT .X OF
NSET
3:

Faa ( • K+I ) :

#26:

• K:

• V:

• Z*.K

TESN:

SELECT .X OF
SET
Faa ( . K+I) :
[3J:
[%0'26'J: • K:

[. vJ:

• Z*.K

TES:

9.3.2.7 CASE Expressions - The CASE expression should be formatted so
that no more than one CASE label is required for each line.

9.3.2.8 MACROs - The closing $ in a macro is converted to %.
An
attempt is made to transform all occurrences of $ and % characters in
a BLISS-IO macro.
If a language construct is completely contained
within a macro, it is normally transformed properly, as in:
MACRO A = OWN X[2J $:
However, macros that contain only portions of
an
expression,
declaration, or statement are transformed incorrectly, as in:
MACRO B = OWN [ $:

9-9

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
9.4

TUTIO - TUTORIAL TERMINAL INPUT/OUTPUT PACKAGE

TUTIO.R36 is a BLISS REQUIRE file that contains some simple 'terminal
I/O primitives.
It is normally used in conjuction with the BLISS self
paced study course as outlined in the BLISS Primer, but can be useful
in writing quick and dirty programs, also. To gain access to the
elements of this package, insert the following line in your BLISS
program:
REQUIRE

'TUTIO'~

A list of these primitives and their functions appears
following conventions are used in the descriptions:
char
len
addr
value
radix

9.5

below.

The

a character
a length (in characters)
a memory address
an integer
an integer

•

TTY PUT_CHAR(char}~ -- Writes a character to the terminal.

•

char=TTY_GET_CHAR(}~

•

TTY PUT QUO('quoted
the-terminal.

•

TTY_PUT_CRLF(}~

•

TTY PUT ASCIZ(addr}~ -- Writes an ASCIZ string to the
terminal.

•

TTY PUT MSG(addr,len}~ -- Writes a string of ASCII characters
to the terminal.

•

TTY PUT INTEGER(value,radix,len}~ -- Writes an integer to the
terminal.

•

n = TTY GET LINE(addr,len}~ -- Reads a line from the terminal
into a buffer and returns the number of characters read.

-- Reads a character from the terminal.
string'}~

-- Writes a quoted string to

-- Writes a carriage return/line feed
sequence to the terminal.

SYSTEM INTERFACES

9.5.1

Precompiled Declaration Libraries

Precompiled BLISS declaration libraries are provided to facili,tate the
use of the TOPS-IO and TOPS-20 monitor calls in BLISS-36 programs.
These libraries are derived from the MACRO-IO UNIVERSAL files:
•

MACTEN.UNV

•

MACSYM.UNV

•

UUOSYM.UNV

•

MONSYM.UNV

9-10

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
which are used in writing MACRO programs.
provided are:
Monitor

independent

The

libraries

•

TENDEF.L36 MACSYM

symbols

from

•

UUOSYM.L36 - TOPS-IO monitor calls from UUOSYM

•

MONSYM.L36 - TOPS-20 monitor calls from MONSYM

which

are

MACTEN

and

Generally speaking, BLISS declaration libraries contain definitions of
the same symbols which the MACRO universal files contain, and are used
in much the same way as the universal files.
More detail about how
the translation occurs is found in later sections.
The symbol names are the same except that the period is translated to
dollar sign, and the percent sign is translated to underline, e.g.,
PC%USR
.CHLFD

becomes
becomes

PC USR
$CHLFD

This rule permits the programmer to use the published UUOSYM and
MONSYM files as a guide to the use of the BLISS libraries, while the
special character translation avoids
the
use
of
the
%NAME
lexical-function.

9.5.2

TENDEF.L36 Library

The TENDEF library contains a number of MACRO and LITERAL declarations
which are not monitor dependent. These provide definitions of PDP-IO
hardware data structures, and definitions needed to utilize the mask
defini~:ions contained in the UUOSYM and the MONSYM libraries.
Ordinarily both TENDEF and either UUOSYM or MONSYM will be needed:
LIBRARY 'TENDEF';
LIBRARY 'MONSYM';

9.5.2.1 POINTR Macro - Subfields of a machine word are defined in the
libraries in terms of bit masks just as they are defined in the
corresponding MACRO universal files.
These masks are a contiguous
string of one-bits arbitrarily located in a 36-bit word.
The POINTR
macro is used to construct a field-reference from these masks.
Call:
POINTR ( address , mask )
Expansion:
address < position , size >
Example:
POINTR(X, %0'60') expands to X<4,2>

9-11

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
9.5.2.2 FLD Macro - The FLD macro is used to position a
subfield specified by a bit mask.

value

Call:
FLD

value, mask )

Expansion:
( ( value ) position )
Example:
FLD(2, %0 160 1 ) expands to ((2) 4)

9.5.2.3 MONWORD and MONBLOCK Structures - Since subfields of
a
machine word are defined in MONSYM and UUOSYM as bit masks, the
MONWORD and MONBLOCK structures are defined to accept a mask value to
determine position and size.
For example:
OWN
X:MONWORD;

X[PC OVFJ= 0;

!PC OVF is defined as IA35

is equivalent to:
X<35,1>= 0;
The MONBLOCK structure defines a BLOCK of
accessed as a MONWORD:

words,

each

which

LOCAL
V:MONBLOCK[8J;

INCR I FROM 0 TO %ALLOCATION(V)-l DO
V[.I,%01777777 J= 0;
I

The latter would deposit zeros into:
(V+.I)<0,18>= 0

9.5.2.4 Other Symbols - The TENDEF library contains
groups of symbols extracted from the MACSYM file:
Program counter bits PC xxx
Version number subfields VI xxx
Control character definitions $CHxxx

9-12

several

other

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
9.5.3

UUOSYM.L36 Library

The following specifies the translat.ion of each type of symbol defined
by the UUOSYM file into BLISS:
defined by equates, which include offsets,
field
• Symbols
are converted to LITERAL
values,
and subfield bit masks,
declarations with the same value.
•

Symbols defined by OPDEF, which include the UUO instructions,
are converted to MACRO declarations.
One of four styles of
macro is chosen depending upon the form of the OPDEF.
In each
case,
the
macro
ultimately
expands
after
parameter
substitution to a list of three values separated by commas,
which represent the operation code, the accumulator field, and
the effective address of the instruction.
This macro would
ordinarily be called to supply the parameters of a MACHOP or
MACHSKIP function.
MACRO name= %O'xxx', %O'xx', %O'xxxxxx' %;
This form is used when the accumulator field and the effective
address of the OPDEF are both nonzero.
MACRO name{a)= %O'xxx', a, %O'xxxxxx' %;
This form is used when the accumulator field of the OPDEF is
zero and the effective address is nonzero, or when the opcode
is CALLI.
MACRO name{e)= %O'xxx', %O'xx', e %;
This form is used when the accumulator field of the OPDEF is
nonzero and the effective address is zero, or when the opcode
is TTCALL or MTAPE.
MACRO name{a,e)= %O'xxx', a, e %;
This form is used when the accumulator field and the effective
address of the OPDEF are both zero {and the opcode is not one
of the special casesf.

9.5.4

MONSYM.L36 Library

The following specifies the translation of each type of symbol defined
by the MONSYM file into BLISS:
•

Symbols defined by equates, which include offsets,
field
values,
JSYS error codes,
and subfield bit masks,
are
converted to LITERAL declarations with the same value.

•

Symbols defined by OPDEF, which include the JSYS instructions,
are converted to LITERAL declarations with the JSYS number as
value.
The symbol "JSYS" itself is omitted.

9-13

TOOLS, LIBRARIES, AND SYSTEM INTERFACES

9.5.5

Generation Procedure

The following is the procedure for library generation.
the generation are:
UUOSYM.MAC
MONSYM.MAC
TENDEF.R36
FLDBB.R36

The inputs

Monitor independent symbols
FLDDB$ macro

.R MACRO
MACRO 52 or later
*,UUOSYM=UUOSYM
1 Make UUOSYM.LST
* ,MONSYM=MONSYM
1 Make MONSYM. LST
. RUN MONINT
1 Convert .LST to .R36
*UUOSYM
1 Make UUOSYM.R36
* MONSYM
1 Make MONSYM.R36
.R BLISS
1 Create libraries
*TENDEF=TENDEF/LIBRARY
1 Make TENDEF.L36 from TENDEF.R36
*UUOSYM=UUOSYM/LIBRARY
1 Make UUOSYM.L36 from UUOSYM.R36
*MONSYM=MONSYM,FLDDB/LIBRARY 1 Make MONSYM.L36 from MONSYM.R36
! and FLDDB.R36
.DELETE UUOSYM.LST,MONSYM.LST,UUOSYM.UNV,MONSYM.UNV
The following files should now be installed in a public directory:
TENDEF.R36
UUOSYM.R36
MONSYM.R36
FLDDB.R36

9.5.6

TENDEF.L36
UUOSYM.L36
MONSYM.L36

TOPS-IO System Interface Example

MODULE tuglO( %TITLE'Bliss-36 TOPS-IO Interface Example'VERSION='l(l) , ,
MAIN=show_time, ENVIRONMENT(TOPSIO»=
BEGIN
1++
1

FUNCTION
Simple example showing interfacing techniques for Bliss-36
and TOPS-IO V7.01.
1--

FORWARD ROUTINE
show time
gettTme
outdec

NOVALUE,
NOVALUE,
NOVALUE;

Loads buffer with ASCIZ time string.
Decimal conversion routine

LIBRARY 'BLI:TENDEF';
LIBRARY 'BLI:UUOSYM';
LITERAL
LHALF
RHALF

-1"18,
%0'777777';

MACRO
GETLCH UUO(arglist)
GETTAB-UUO(argadr)
OUTSTR=UUO(stradr)

Masks suitable for use with
MONWORD structure.
UUO(O, GETLCH(arglist»
%,
UUO(l, GETTAB(argadr»
%,
UUO(O, OUTST~(stradr»
%;

9-14

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
BUILTIN
UUO~

MACRO
MSGL[] = MSG( %REMAINING, %CHAR($CHCRT, $CHLFD) ) %,
MSG[] = UPLIT( %ASCIZ %STRING( %REMAINING ) ) %~
ROUTINE show time : NOVALUE=
1+

1 FUNCTION
Simple program which gets current date-time info (via GETTAB)
and displays a text string on the user's TTY:
1-

BEGIN
LOCAL
timebuffer

VECTOR[CH$ALLOCATION(80)],

line status

Initial value for job's
controlling terminal

INITIAL(-l)~

MONWORD

Find out what kind of terminal the controlling job has
and print some BELs unless it's a PTY:
GETLCH_UUO( line_status

IF .line status[LHALF] EQL 0
THEN
RETURN OUTSTR_UUO( MSGL('GETLCH failed')

IF NOT .line status[GL$ITY]
1 PTYs don't get "BELLS"
THEN
OUTSTR_UUO( MSG( %CHAR($CHBEL, $CHBEL, $CHBEL) ) )~
gettime( CH$PTR(timebuffer)

OUTSTR UUO( MSG('%SHOW TIME:: '))~
OU'rSTR-UUO ( CH$PTR( timebuffer) ) ~
OUTSTR-UUO( MSG(%CHAR($CHCRT, $CHLFD))
END~
ROUTINE gettime( bufptr ) :NOVALUE

FUNCTION
Get the current date-time from the monitor, convert to ASCIZ
of the form
dd-mmm-yyyy

hh:mm:ss

INPUT
bufptr

- CH$PTR to output buffer

OUTPUTS
None
1-

BEGIN
REGISTER
argval

Needed for doing GETTABs

MONWORD~

BIND
tabvals = PLIT(
monstr

CNDAY, CNMON, _CNYER,
:- VECTOR-;

UPLI'r ( '-Jan-',
, -May-',
-SepI

'-Feb-',
'-Jun-',
-OctI

9-15

CNHOR, _CNMIN,

'-Mar-',
-Jul-NovI

'-Apr-',
-Aug'-DecI

CNSEC

VECTOR~

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
LOCAL
timvals

VECTOR[6]~

1 Holds results of GETTABs

INCR i FROM 0 TO .tabvals[-l] - 1 DO
BEGIN
argval[LHALF]
.tabvals[.i]~
$GTCNF~
argval[RHALF]

Item from System Config Table

IF NOT GETTAB_UUO( argval
THEN
The UUO failedl
RETURN OUTSTR_UUO( MSGL('?GETTAB failed') );
Copy into safe place

timvals[.i] = .argval
END~

Now write time values as needed.
OUTDEC(

.timvals[O], bufptr

bufptr = CH$MOVE( 5, CH$PTR(monstr[.timvals[l]J), .bufptr
OUTDEC(

.timvals[2], bufptr

CH$WCHAR_A( %C'

bufptr

OUTDEC( .timvals[3], bufptr
CH$WCHAR_A( %C':', bufptr)~

OUTDEC( .timvals[4], bufptr )~
CH$WCHAR_A( %C':', bufptr )~
OUTDEC(.timvals[5], bufptr
CH$WCHAR_A( 0, bufptr )~

1 HH:

MM:
SS
The trailing NUL for ASCIZ strings

END~

ROUTINE OUTDEC( value, bufaddr adr ): NOVALUE=
!+

FUNCTION
Convert a number from binary to ascii decimal representation
INPUTS
value - numeric value to convert
bufaddr adr - address of CH$PTR to use.
OUTPUTS
none
NOTES
Only positive numbers are handled.
BEGIN
IF .value LEO 9
THEN
CH$WCHAR A( .value+%C'O', .bufaddr adr
ELSE
BEGIN
OUTDEC( .value/10, .bufaddr adr )~
OUTDEC( .value MOD 10, bufaddr adr
END
END:
END ELUDOM

9-16

(Incremented as we go)

TOOLS, LIBRARIES, AND SYSTEM INTERFACES

9.5.7

TOPS-20 System Interface Example

MODULE tug (MAIN=showtime, version='l(l)' %TITLE'BLISS-36 User' 's Guide')=
BEGIN
1++

Simple program to demonstrate using JSYS in Bliss-36

1
1
1-·-

FORWARD ROUTINE
readaline,
show time
: NOVALUE,
cmdmsg
: NOVALUE;

Read one line from the terminal
Print full date and time
Print a message on the terminal

LIBRARY 'SYS:TENDEF';
UNDECLARE
$CHCRT,
$CHLFD;

These are declared in both libraries ...

LIBRARY 'SYS:MONSYM';
MACRO
! Given JSYS numbers from MONSYM,

create linkages and BIND ROUTINE
declarations to define a more esthetic interface to TOPS-20 JSYS.

MJSYS(name,skipcnt,inreg,outreg)=
%ASSIGN(jsysno,name)
UNDECLARE name;
LINKAGE %NAME('l ',name) = JSYS (
%IF NOT %NULL(inreg) %THEN RPLIST( %REMOVE(inreg) ) %FI
%IF NOT %NULL(outreg) %THEN ; RPLIST( %REMOVE(outreg) ) %FI)
: SKIP(skipcnt);
BIND ROUTINE name = jsysno : %NAME('l_' ,name); %,
RPLIST(a)[]
COMPILETIME
jsysno

%(
%(

Skip

In-Regs

------MJSYS(
MJSYS(
MJSYS(
MJSYS(

DVCHR,
PSOUT,
ODTIM,
RDTTY,

0,
0,
0,
1,

(1 ) ,
(1 )
(1,2,3)
(1,2,3) ,

Out-Regs )%
-------- )%
(1,2,3)
(2 )

) ;
);
);
);

BIND
CRLF = CH$PTR( UPLIT( %ASCIZ %CHAR($CHCRT, $CHLFD) ) ) ;
: NOVALUE=

GLOBAL ROUTINE cmdmsg( amsg )
1++
1 FUNCTION

Print out a string on the primary output device.

9-17

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
INPUTS
amsg - CH$PTR to an ASCIZ string
OUTPUTS
None
1--

BEGIN
LOCAL
characteristics : MONWORD;
Get device characteristics to see if we should give a CRLF
DVCHR( $PRIOU ; , characteristics );
Real TTY or
PTY: get a CRLF

IF .characteristics[DV TYP] EQL $DVTTY OR
.characteristics[DV-TYP] EQL $DVPTY
THEN
PSOUT ( CRLF );
PSOUT ( . amsg );
PSOUT( CRLF )
END;
ROUTINE show time

Write the message text
and a CRLF afterwards
NOVALUE=

1++
1 FUNCTION

Print the current time-of-day in the format
hh::mm: : ssAM-EDT
INPUTS
None
OUTPUTS
None
1--

BEGIN
LITERAL
buflen
LOCAL
buffer

133;

VECTOR[ CH$ALLOCATION(buflen) ];

ODTIM( CH$PTR(buffer), -1, OT NDA+OT 12H+OT SCL );
cmdmsg( CH$PTR(buffer}

);

IF readaline( CH$PTR(buffer), buflen, CH$PTR(UPLIT(%ASCIZ'GOOD?')
THEN
1 Successful
!

cmdmsg( CH$PTR( UPLIT( %ASCIZ'BYE'

) ) )

ELSE
cmdmsg( CH$PTR( UPLIT( %ASCIZ'FAILED'
END;
ROUTINE readaline

! show time

bufadr, len, prompt

FUNCTION
Accept a line from the terminal

9-18

) )

TOOLS, LIBRARIES, AND SYSTEM INTERFACES
INPUTS
bufadr
len
prompt
OUTPUTS
1
1

- CH$PTR to buffer where terminal response should be placed
- length of buffer
- CH$PTR to ASCIZ string to prompt the user with.
We got a line of input
It flopped.

1 --

BEGIN
PSOUT(

.prompt );

1 RDTTY skip-return is converted to TRUE or FALSE
RDTTY(
END;

.bufadr, RD TOP+.len,

.prompt )

END ELUDOM

9-19

CHAPTER 10
BLISS-36 CODING EXAMPLES

This chapter provides useful examples of BLISS-36 coding techniques.
The coding used to devise these examples demonstrates the use of many
BLISS language features.

10.1

EXAMPLE 1:

THE PSINT PROGRAM

The coding of the PSINT program primarily demonstrates the use of the
PSI INTERRUPT linkage.
The program allows you to display a specified
file in 132 columns on the terminal.
A Control-C is used to both exit
the program and return the terminal width to its original setting.
The PSINT program requires the following system interface files:
•

MONSYM - TOPS-20 monitor interface symbols

•

TENDEF - Monitor independent MACRO and LITERAL declarations

•

MJSYS -

Interface to TOPS-20 JSYS calls

The following steps are used to run the PSINT program:
1.

Compile the PSINT program:
@BLISS
BLISS>PSINT
File:
PS:<JONES>PSINT.B36.1
Size:
328 code + 2123 data words
Run Time:
00:05.2
Elapsed Time:
00:16.7
Lines/CPU Min:
4450
Lexemes/CPU-Min:
74859
Memory Used:
39 pages
i Compilation Complete
BLISS>"C
@

Link the PSINT program and use /GO to terminate:
@LINK
* PSINT
* /GO
EXIT

Save the executable image:
@SAVE PSINT
PSINT.EXE.l Saved

10-1

BLISS-36 CODING EXAMPLES
4.

Run the PSINT program:
@RUN PSINT
(terminal is set to 132 columns)
FILE:ALPHA.TXT
(ALPHA. TXT is displayed in 132 columns)
FILE : . . C
@(terminal is reset to original width)

The following sections contain
module:

10.1.1

the

annotated

coding

the

PSINT

Module PSINT

MODULE PSINT( %TITLE'Bliss-36 PS INTERRUPT Example
VERSION= 1 ( 1 )
MAIN=REPLAY )=
BEGIN
I

!++
!

FUNCTION
Example showing the use of the PS INTERRUPT linkage
declaration in Bliss-36.
This example types a specified file to the TTY
In 132 columns. Control-C must be typed in order
to exit, causing the terminal width to be reset
to its original setting. If a Control-Y is typed
the program will prompt for another file.
!--

LINKAGE PSI = PS_INTERRUPT;
FORWARD ROUTINE
REPLAY
DISPLAY
ENAPSI
CTRCLC

NOVALUE,
NOVALUE,
NOVALUE,
PSI NOVALUE,

CTRLY

PSI NOVALUE,

TTYSET
FILIO
TTYRES
DISPSI
DSPHDL,

NOVALUE,
NOVALUE,
NOVALUE,
NOVALUE,

PSIHDL;

Sets up and enables the PSI
The Control-C software interrupt
handler
The Control-Y software interrupt
handler
Sets up terminal characteristics
Performs file I/O
Resets terminal characteristics
Disables the PSI
Condition Handler for the DISPLAY
routine
Condition Handler for interrupt
routine

LIBRARY 'BLI:TENDEF';
UNDECLARE
$CHCRT,
$CHLFD;

Declared in both libraries

LIBRARY

BLI : MONSYM

REQUIRE

MJSYS

;

Define needed JSYS calls
10-2

BLISS-36 CODING EXAMPLES
LITERAL
true = I,
false = 0,
ss$cntrl y
I,
intchl -I,
intch2
2,
bufsiz
132,
typwid
132;

Control-Y flag
Interrupt channel 1
Interrupt channel 2
Size of the file I/O buffer
Terminal output width

MACRO
ERROR

ERSTR($PRIOU, ($FHSLF"'lB) OR %0'777777',0);
HALTF ( ); ) %,

XPDPlO_BITS[BITS]
PDPlO_BITS[]

(1)

= 1"'(35-BITS)%,

= (0 OR XPDPlO_BITS(%REMAINING»%;

(2)

OWN
pclevl,
levtab: VECTOR[3]
INITIAL(pclevl, REP 2 OF (0»,

(3 )

(4)

chntab: VECTOR[36]
INITIAL(O,(l"'lB OR CTRLC),
(1 "'lB OR CTRLY),
REP 33 OF (0»,
filbuf :
VECTOR[CH$ALLOCATION(bufsiz)],
filjfn:
VOLATILE,
ttyjfn :
VOLATILE INITIAL(-l),
width
VOLATILE;

(5)

(6)
(7)
(B)
(9)

The ERROR macro outputs the most recent error message to
primary output device and halts the process.

The PDPlO BITS macro returns a
PDP-10 bits set.

PCLEVl is the address used to save the PC during interrupts.

LEVTAB is the priority level table used by PSI.

CHNTAB is the channel table.

literal

with

the

specified

Note that Channell
(priority level 1) serves the CTRLC
routine,
while Channel 2 (priority level 1) serves the CTRLY
routine; no other channels are assigned.
6.

FILBUF is the input file buffer.

FILJFN is the JFN for the file.

TTYJFN is the JFN for the terminal.

9..

WIDTH is the original setting of the terminal.

10-3

BLISS-36 CODING EXAMPLES
10.1.2

Routine REPLAY

ROUTINE REPLAY

NOVALUE

1+
1 FUNCTION
1
1
This is the main routine which causes the program

to continually loop until a Control-C is typed or
an error occurs.
1-

BEGIN
WHILE true DO DISPLAY():
END;

10.1.3

Routine DISPLAY

ROUTINE DISPLAY

NOVALUE

!+
1 FUNCTION

This routine enables a condition handler
and calls all the routines which perform
the file and terminal I/O.
1-

BEGIN
ENABLE DSPHDLi
ENAPSI();

(1 )

TTYSET()i

(2 )

FILIO ( ) ;

(3 )

TTYRES():

(4)

DISPSI();

(5 )

END;

Enable the PSI to trap on Control-C and Control-Yo

Set the terminal width to 132.

Get the file and display it on the terminal.

Set the terminal width back to the original setting.

Disable the PSI.

10.1.4

Routine ENAPSI

ROUTINE ENAPSI

NOVALUE

1+
1

FUNCTION

10-4

BLISS-36 CODING EXAMPLES
1
1
1

Enables the software interrupt system and sets up
the program to trap on Control-C and Control-Yo

1-,

BEGIN
A

SIR($FHSLF, «levtab 18) OR chntab»;
EIR($FHSLF);
AIC($FHSLF, PDPIO BITS(intchl,intch2»;
ATI($TICCC 18 OR Intchl);
ATI($TICCy 18 OR intch2);
END;
A

Specify the PSI table.

Enable the PSI.

Activate the interrupt channel.

Trap on Control-C.

Trap on Control-Yo

10.1.5

(1)
(2)
(3)
(4)
(5)

Routine TTYSET

ROUTINE TTYSET : NOVALUE
1+
1 FUNCTION
1

Opens the terminal in Image mode and sets
the width to 132, saving the original
setting.
1-

BEGIN
IF NOT GTJFN(GJ SHT, CH$PTR(UPLIT(%ASCIZ'TTY: I»;
ttyjfn)
THEN
ERROR;
IF NOT OPENF(.ttyjfn,
FLD(7,OF BSZ) OR FLD(%O'lO',
OF_MOD) OR OF WR »THEN
ERROR;
MTOPR(.ttyjfn, $MORLW;"width);

(3)

IF .width NEQ typwid
THEN
BEGIN
MTOPR( .ttyjfn, $MOSLW, typwid);

(4)

SOUT(.ttyjfn, CH$PTR(UPLIT
(%ASCII %STRING(%CHAR
(%CHESC) , [?31 ' ) ) ), 5, 0);
END

(5)

END;

10-5

(1)

(2)

BLISS-36 CODING EXAMPLES
1.

Associate a Job File Number with the terminal.

Open the terminal in image mode with a byte size of seven.

Get the terminal page width.

Set the software page width to 132.

The <ESC>[?3h' string is a special escape sequence that tells
the VT100 to set the page width to 132.

10.1.6

Routine FILIO

ROUTINE FILIO

NOVALUE

1+
1 FUNCTION

This routine prompts the user for a file name, opens
the specified file, and outputs it to the terminal.
1-

BEGIN
LITERAL
219;
max spec
LOCAL
count,
cond : MONWORD,
ttybuf
VECTOR[ CH$ALLOCATION(max_spec) ];
BEGIN
PSOUT( CH$PTR(UPLIT(%ASCIZ'FILE:'»

);

IF NOT RDTTY(CH$PTR(ttybuf), max_spec, 0)
THEN
ERROR;
IF NOT GTJFN«GJ OLD OR GJ_SHT),CH$PTR(ttybuf);
filjfn)
THEN
ERROR;
IF NOT OPENF(.filjfn,
THEN
ERROR;
END;

(FLD(7,OF_BSZ) OR OF_RD»

(1 )

(2)

(3)

WHILE true DO
BEGIN
IF NOT SIN(.filjfn,
(4)
CH$PTR(filbuf),-bufsiz,O;"count)
THEN
BEGIN
(5 )
GETER($FHSLF;cond);
(6 )
IF .cond[IOX4]
THEN
BEGIN
(7 )
IF .COUNT NEQ
THEN
SOUT ( . ttyj fn,
CH$PTR(fi1buf),(bufsiz-.count),0);
EXITLOOP;

10-6

BLISS-36 CODING EXAMPLES
END;
ERROR
END;
SOUT ( . ttyj fn,
CH$PTR(filbuf),(bufsiz-.count),O);
END;

(8)
(9 )

END;

Read the file name from the terminal.

Associate a Job File Number with the file.

Open the file in 7-bit mode for reading.

Read from the input file.

Determine the cause of the error.

Stop reading when end-of-file is reached.

Clear the buffer.

Report any unexpected error condition.

Output the string to the terminal.

10.1.7

Routine TTYRES

ROUTINE TTYRES

NOVALUE

1+
1 FUNCTION

Resets the terminal width back to the original
setting and closes and releases the JFN.
1-

BEGIN
IF (.width NEQ -1) AND
(.width NEQ typwid)
THEN
BEGIN

(1)

MTOPR(.ttyjfn,
$MOSLW, . width) ;

(2)

SOUT(.ttyjfn, CH$PTR(UPLIT
(3)
(%ASCII %STRING(%CHAR
(%CHESC),'[?31'»), 5, 0);
width = 0;
END;
IF .ttyjfn GEQ 0
THEN
BEGIN
CLOSF( .ttyjfn);
ttyjfn = 0;
END;
END;

10-7

BLISS-36 CODING EXAMPLES
1.

Check for altered terminal width.

Reset the terminal page width to its original setting.

Set the VT100 to the same width.

10.1.8

Routine DISPSI

ROUTINE DISPSI

NOVALUE

1+
1 FUNCTION
1

Disables the software interrupt system.
1-

BEGIN
DTI($TICCY);
DTI($TICCC);
DIC($FHSLF, PDPIO BITS(intchl,intch2));
DIR($FHSLF);
END;

Disable trapping on Control-Yo

Disable trapping on Control-C.

Deactivate the interrupt channels.

Disable the PSI.

10.1.9

(1)
(2)
(3)
(4)

Routine CTRLC

ROUTINE CTRLC

PSI NOVALUE

FUNCTION
This is the Control-C interrupt handler. The handler
calls the routine to reset the width of the terminal
and then exits.
If CONTINUE is typed by the user, the terminal is
reset to 132 columns and the program continues from
the point where the trap occurred.
1-

BEGIN
TTYRES();
HALTF ( ) ;
TTYSET();
END;

10-8

BLISS-36 CODING EXAMPLES
10.1.10

Routine CTRLY

ROUTINE CTRLY

PSI NOVALUE

1+
1 FUNCTION

This is the Control-Y interrupt handler. This
routine signals the PSI condition handler.
1 --

BEGIN
ENABLE PSIHDLi

(1)

SIGNAL(ss$cntrl_y)i

(2)

END:

I..

Enable the PSI-handler.

Generate the Control-Y signal.
Note that for a PSI-handler in which an UNWIND can
condition handler must be established.

10.1.11

occur,

Routine DSPHDL

ROUTINE DSPHDL(sig: REF VECTOR, mech
VECTOR)

REF VECTOR, enab

REF

FUNCTION
Condition handler for the routine Display. This
routine terminates all I/O and does an Unwind for
the Control-Y signal.
1-

BEGIN
IF .sig[l] NEQ ss$cntrl_y
THEN
RETURN falsei

Resignal for conditions
other than Control-Yo

TTYRES():
CLOSF(-I)i
DISPSI();
SETUNWIND();
true
END:

10.1.12

Routine PSIHDL

ROUTINE PSIHDL(sig: REF VECTOR, mech
VECTOR)

10-9

REF VECTOR, enab

REF

BLISS-36 CODING EXAMPLES
1+
1 FUNCTION

Condition handler for Control-Yo This routine
simply resignals.
1-

BEGIN
RETURN false
END;
END
ELUDOM

10.2

EXAMPLE 2:

THE TRANS PROGRAM

The coding of the TRANS program primarily demonstrates the use of the
COMND JSYS function; however, the program also demonstrates BLISS-36
character-handling techniques. The program allows you to substitute
or delete selected characters in an input file and produce an output
file containing the changes.
The command line syntax is as follows:
in-spec {/OUTPUT: out-spec J (FROM) "characters" (TO) "characters"
The TRANS program requires the following system interface files:
•

MONSYM - TOPS-20 monitor interface symbols

•

TENDEF - Monitor independent MACRO and LITERAL declarations

•

MJSYS - Interface to TOPS-20 JSYS calls

The following steps are used to run the TRANS program:
1.

Compile the TRANS program:
@BLISS
BLISS>TRANS
File:
PS:<JONES>TRANS.B36.1
Size:
415 code + 2444 data words
Run Time:
00:11.8
Elapsed Time:
00:28.9
Lines/CPU Min:
4771
Lexemes/CPU-Min:
103118
Memory Used:
54 pages
; Compilation Complete
BLISS> . . C
@

Link the TRANS program and use /GO to terminate:
@LINK
*TRANS
*/GO
EXIT

10-10

BLISS-36 CODING EXAMPLES
3.

Save the executable image:
@SAVE TRANS
TRANS.EXE.l Saved

Run the TRANS program:
@RUN TRANS
TR> TRIN. TXT !OUTPUT: TOUT. TXT. 1 <ESC>
@

INew fi Ie 1 (FROM)

"CD" < ESC> (TO)

Using the /OUTPUT:
switch option,
the program reads input file
TRIN.TXT and creates output file TOUT.TXT in which all uppercase Cs
and Ds are respectively changed to 3s and 4s.
Note that if the
/OUTPUT:
switch is not used, an output file is created that is the
next generation of the input file spec.
The following sections contain
module.

10.2.1

the

annotated

coding

the

TRANS

Module TRANS

MODULE TRANS (MAIN

) =

transmain

BEGIN
1++
1 FUNCTION

This program copies an input file to an output file
with substitution or deletion of selected characters.
Each character in the argument (FROM) is translated to
the corresponding character in the argument (TO); all
other characters are copied as is.
Both (FROM) and (TO) may contain substrings of the form
al-a2, as shorthand for all the characters in the range
al .. a2. If the (TO) argument contains no characters,
then all characters in the (FROM) argument are deleted.
If (FROM) is shorter than (TO), all characters in (FROM)
that would map to or beyond the last character in (TO)
are mapped to the last character in (TO).
1--

LIBRARY'BLI:TENDEF';
UNDECLARE
$chcrt,
$chlfd;

These are declared in both libraries.

LIBRARY'BLI:MONSYM';
REQUIRE 'MJSYS';

Define needed JSYS calls

(1 )
MACRO
jsys_detected error =
( erstr($priou, ($fhslf 18) OR %0'777777', 0);
haltf(); )%,
A

10-11

"34"

BLISS-36 CODING EXAMPLES
quote error =
(2)
T psout( CH$PTR(UPLIT(%ASCIZ1Invalid quoted stringl)));
haltf(); )%;
BIND
switch

UPLIT (%ASCIZ10UTPUT: I);

LITERAL
true = 1,
false = 0,
alpha = 1,
alpha lower case = 2,
numerIc = 3-;not alpha numeric = 4,
buffer_length = 132:
OWN
injfn,
Input JFN
outjfn,
Output JFN
state,
Command state indicator
reparse,
Flag indicating a reparse
eoc seen,
End of command flag
(3 )
cmdgjb : VECTOR [%0116 J,
(4 )
swblk : VECTOR [2J
INITIAL (lA lB OR 1, switchAlB),
(5 )
command buffer :
VECTOR [CH$ALLOCATION (buffer_length)J,
(6)
atom buffer :
VECTOR [CH$ALLOCATION (buffer_length)J,
(7 )
file spec :
VECTOR [CH$ALLOCATION (buffer_length)J,
(B)
from count,
from-buffer:
(9 )
VECTOR [CH$ALLOCATION (buffer_length)J,
to count,
(10)
to-buffer :
(11)
VECTOR [CH$ALLOCATION (buffer_length)J;
I

The JSYS DETECTED ERROR outputs the most recent error message
to the primary output device and halts the process.

The QUOTE ERROR outputs the IIInvalid quoted string II
to the prImary output device and halts the process.

CMDGJB is the argument block used by the COMND JSYS.

SWBLK is used by the COMND
switch

COMMAND BUFFER is the text buffer used by the COMND JSYS.

ATOM BUFFER is the atom buffer used by COMND JSYS.

FILE SPEC is the buffer for the default output file.

FROM COUNT indicates
FROM-BUFFER.

FROM BUFFER is the character buffer for the (FROM) reques·t.

10.

TO COUNT indicates the number of characters in the TO BUFFER.

11.

TO BUFFER is the character buffer for the (TO) request.

the

10-12

JSYS

number

for

parsing

the

characters

message

/OUTPUT:

the

BLISS-36 CODING EXAMPLES
The following chart depicts the command state table used by this
example.
Note that you initialize the BLOCKVECTOR state table to
reflect the entries to the table.
The NEXT field contains the next
state number, while the ACT field is used in a CASE statement to
indicate what action is performed.
The following abbreviations define the actions performed:
s i

save input info
save-from part
save-out Jfn
save-in Jfn
save=to_part

s=f=p
s 0
s i

j
j

s_t_p

Table 10-1: Depiction of the Command State Table
--------------------------------------------------- -

STATE

.CHINI

.CHSWI

.CHIFI

.CHOFI

.CMQST

.CHCFM

.CMNOI

(INIT)

(jOUTP)

(INPUT)

(OUTPUT)

(QUOTES)

(EOC)

(FROM)

(TO)

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

o
o

Next=l
Act=nu11

x
x

1
1

x
x

Next=3
Act=nu11

Next=2
Act=s_f_p

x
x

2
2

x
x

Next=4
Act=nu11

x
x

Next=8
Act=s_f_p

x
x

3
3

x
x

Next=5
Act=s 0

x
x

4
4

x
x

Next=6
Act=s 0

x
x

5
5

x
x

6
6

x
x

Next=7
Act=nu11

x
x

7
7

x
x

Next=8
Act=s f _p

x
x

8
8

x
x

Next=9
Act=null

9
9

x
x

Next=lO
Act=s _ t _p

x
x

10
10

x
x

Next=O
Act=eoc

x
x

Next=6
Act=s i

10-13

BLISS-36 CODING EXAMPLES

LITERAL
(1 )

0,
sO
1,
sl
2,
s2
3,
s3
4,
s4
5,
s5
6,
s6
7,
s7
8,
s8
9,
s9
slO = 10,
Init
Switch
Input file-spec
Output file-spec
Quoted string
Confirm (crlf)
Guide word (FROM)
Guide word (TO)

0,
cmini
cmswi
1,
cmifi
2,
3,
cmofi
4,
cmqst
5,
cmcfm
cmnoi - from = 6,
cmnoi to = 7,
null = 0,
save input info = 1,
save-in jfn = 2,
save-out jfn = 3,
save-from part = 4,
save-to part
5,
eoc ;; 6~
num of functs

num of states
fdb-size
6,

11,

csb size
user = 5;

10,

(2)

(3)

Number of functions parsed
in this example
Number of command states
Function data block size
plus one
Command state block size
User defined word in fdb

FIELD state fields =
SET
next = [18,18,OJ,
action = [0,18,OJ
TES;
OWN
state table

BLOCKVECTOR[num of states, num of functsJ
FIELD(state fIelds) PRESET( -

[sO,cmini,nextJ
sl,
[sO,cmini,actionJ
null,
[sl,cmswi,nextJ
s3,
[sl,cmswi,actionJ
null,
[sl,cmifi,nextJ
s2,
[sl,cmifi,actionJ
save input info,
[s2,cmswi,nextJ
s4,
[s2,crnswi,actionJ
null~
[s2,cmqst,nextJ
s8,
[s2,cmqst,actionJ
save from part,
[s3,cmofi,nextJ
s5,
[s3,cmofi,actionJ
save-out ]fn,
[s4,cmofi,nextJ
s6,
[s4,cmofi,actionJ
save=out-jfn,
[s5,cmifi,nextJ
s6,
[s5,cmifi,actionJ
save in jfn,
[s6,cmnoi from,nextJ=s7,[s6,crnnoi from,actionJ =-nuIl,
[s7,cmqst~nextJ = s8,
[s7,cmqst~actionJ = save from part,
[s8,cmnoi to,nextJ=s9,
[s8,crnnoi to,actionJ = null, [s9,cmqst~nextJ = slO,
[s9,cmqst~actionJ = save to part,
[slO,cmcfm,nextJ = sO,
[slO,cmcfm,actionJ = eocT: -

10-14

BLISS-36 CODING EXAMPLES
LITERAL
fw = -1;

(4)

OWN

(S)

fdb ini : monblock[fdb size] PRESET
-[$cmfnp,cm fnc] = $cmini,
[user,fw] ~ cmini
),

fdb eol : monblock[fdb size] PRESET
-[$cmfnp,cm fnc] = $cmcfm,
[user,fw] ~ cmcfm
),

fdb switch : monblock[fdb size] PRESET (
-[$cmfnp,cm fnc] = $cmswi,
[$cmdat,fwJ = swblk,
[user,fw] = cmswi
),

fdb ifi : monblock[fdb size] PRESET
-[$cmfnp,cm fnc] = $cmifi,
[user,fw] ~ cmifi
),

fdb ofi : mqnblock[fdb size] PRESET
-[$cmfnp,cm fnc] = $cmofi,
[user,fw] ~ cmofi
),

fdb from : monblock[fdb size] PRESET (
-[$cmfnp,cm fnc] = $cmnoi,
[$cmdat,fwJ = CH$PTR(UPLIT(%ASCIZ'FROM ' »,
[user,fw] = cmnoi from
),
fdb to : monblock[fdb size] PRESET (
-[$cmfnp,cm fnc] =-$cmnoi,
[$cmdat,fwJ = CH$PTR(UPLIT(%ASCIZ'TO ' »,
[user,fw] = cmnoi to
),
fdb quostr : monblock[fdb size] PRESET (
-[$cmfnp,cm fnc] = $cmqst,
[user,fw] ~ cmqst
);

BIND
stateO
PLIT (fdb ini),
PLIT (fdb-ifi, fdb switch),
statel
PLIT (fdb-switch, fdb quostr),
state2
PLIT (fdb=ofi),
state3
state4
state3,
stateS
PLIT (fdb ifi),
PLIT (fdb-from) ,
state6
PLIT (fdb-quostr),
state7
state8
PLIT (fdb=to) ,
state9
state7,
statelO = PLIT (fdb_eol);
OWN
state address : VECTOR [nurn of states] INITIAL (stateO,
statel,
state2, state3, state4, stateS, state6,
state7,state8,state9,statelO);

10-lS

BLISS-36 CODING EXAMPLES
OWN
csl : monblock[csb size] PRESET (
[$cmioj,fw]
$priin
18 OR $priou,
[$cmrty,fw]
CH$PTR(UPLIT(%ASCIZ'TR>'»,
[$cmbfp,fw] ~ CH$PTR(command buffer),
[$cmptr,fw]
CH$PTR(command-buffer),
[$cmcnt,fw]
buffer length,[$cmabp,fw]
CH$PTRTatom buffer),
[$cmabc,fw]
buffer length,
[$cmgjb,fw]
cmdgjbA

);

MACRO chars(num)[]
(6)
%COUNT
%IF %COUNT LSS num %THEN , chars(num) %FI %;
BIND
transtbl

= UPLIT

(%CHAR (chars(127»

);

FORWARD ROUTINE
CMDINIT : NOVALUE,
LEXGET,
OPENFILES : NOVALUE,
BUILDTBL : NOVALUE,

Initialization routine
Command line parsing
Open input and output files
Generate the character
translation table
Translate dashes into
characters (a-z)
Character check (numeric,
alphabetic ... )
Reads and writes bytes from
and to a file

EXPTBL,
CHRVAL,
FILIO : NOVALUE;

SO to SlO are the symbolic names for the states used
command state table.

the

CMINI to CMNOI are the function codes used as indexes to
command state table.

the

NULL to EOC are symbolic names given to the actions performed
during command parsing.

FW contains a fullword mask.

FDB INI to FDB QUOSTR are function descriptor blocks used by
the COMND JSYS to parse the command line.
The user field was
added to more easily access the state table entries.

Generate a table that contains the set of ASCII characters.

10.2.2

Routine TRANSMAIN

ROUTINE TRANSMAIN : NOVALUE
1+

FUNCTIONAL DESCRIPTION:
This is the main routine which controls the
flow of the program.
1-

10-16

BLISS-36 CODING EXAMPLES
BEGIN
DO

(1 )

BEGIN
CMDINIT ()i

(2 )

WHILE true DO

(3 )

IF NOT LEXGET() THEN EXITLOOPi
END
UNTIL .eoc seeni
OPENFILES ()i
BUILDTBL ()i
FILIO ()i

(4)
(5 )
(6 )

ENDi

Read until the end of the command line.

Initialize necessary flags.

Read lexemes until either an error or the end of the
occurs.

Open the input and output files.

Complete the building of the translation table.

Perform the file copy and close the files.

10.2.3

Routine CMDINIT

ROUTINE CMDINIT : NOVALUE
1+
1 FUNCTIONAL DESCRIPTION:

Initialize the flags for command parsing
and initialize the current process state.
1-

BEGIN
eoc seen = falsei
out']fn = -1;
IF .reparse
THEN
BEGIN
reparse = false;
state = sl;
END
ELSE
state

SOi

reset ()i
ENDi

10-17

command

BLISS-36 CODING EXAMPLES
10.2.4

Routine LEXGET

ROUTINE LEXGET

1+
1 FUNCTIONAL DESCRIPTION:
1
1
This routine does the command line parsing

using the state table in Section 10.2.1.
FORMAL PARAMETERS:
None
IMPLICIT INPUTS:
The routine assumes that STATE has been set up
with the appropriate number.
IMPLICIT OUTPUTS:
The following locations may be modified:
STATE, INJFN, OUTJFN, EOC SEEN, REPARSE,
TO_BUFFER, FROM_BUFFER, FILE SPEC
ROUTINE VALUE:
True - if a valid field is parsed
False - if an error, reparse, or an end of
command is seen
1-

BEGIN
LOCAL
oldstate,
fdb : REF monblock[fdb sizeJ,
first fdb : REF monblock[fdb sizeJ,
prev fdb : REF monblock[fdb sizeJ,
flgs-:
MONWORD,
fld data,
fdj-

(1 )
(2 )
(3 )

BIND
valid token

.state address [.stateJ

VECTORj

INCR i FROM 0 TO .valid token [-lJ - 1 DO
BEGIN

(4)

first fdb = OJ

IF .first fdb EQL 0
THEN
first fdb = .valid token [.iJ
ELSE
prev_fdb [$cmfnp,cm IstJ
.valid_token [.iJj
prev_fdb

.valid token [.iJj

ENDj

prev fdb [$cmfnp,cm IstJ = OJ
comnd (csl, .first fdbj fIgs, fld data, fd)j

10-18

(5)

BLISS-36 CODING EXAMPLES
IF .flgs[cm nop]
THEN
BEGIN
erstr ($priou,
RETURN false
END;

(6)
A

($fhslf 18) OR .fld_data, 0);

IF .flgs[cm rpt]
THEN
BEGIN
reparse = true;
RETURN false
END;

(7)

FDB is the function descriptor block.

FIRST_FOB is the first function descriptor block.

PREV_FOB is the previous function descriptor block.

Set up a linked list of valid function
according to the state being processed.

Parse a field in the command.

Return an error if an unexpected field is detected.

Check for reparsing.
fdb

descriptor

= .fd<O, 18>;

blocks

(1 )

oldstate = .state;
state = .state_table[.oldstate,.fdb[user,fw],next];
CASE .state table[.oldstate,.fdb[user,fw],action]
FROM 0 TO eoc OF
SET
[null]
BEGIN
RETURN true
END;
[save input info]
BEGIN injfn

= .fld_data;

(2)

JFNS(CH$PTR(file spec), .injfn,
FLD($JSAOF,JS NAM)+FLD($JSAOF,JS_TYP)
+J S _ PAF , 0 T;
fdb_ofi[$cmdef,fw]

= CH$PTR(file_spec);

fdb ofi[$cmfnp,cm dpp]
RETURN true
END;

10-19

= true;

(3)

(4)
(5)

BLISS-36 CODING EXAMPLES
[save in jfn]
BEGIN
injfn = .fld data:
RETURN trtle
END:

(6)

[save out jfn]
BEG INoutjfn = .fld_data:
RETURN true
END:

(7 )

[save from part] :
BEGIN -

(8)

CH$MOVE (buffer length, CH$PTR (atom_buffer),
CH$PTR Tfrom_buffer»:
RETURN true
END;
[save_to_part] :
BEGIN

(9 )

CH$MOVE (buffer length, CH$PTR (atom_buffer),
CH$PTR Tto_buffer»:
RETURN true
END:

(10)

eeoc] :
BEGIN
eoc seen = true;
RETURN false
END;

(11)

[OUTRANGE]
BEGIN
jsys detected error;
RETURN false END:
TES
END:

Compute the new state and perform appropriate actions based
on the current state and the input token parsed by the COMND
JSYS.
Note that FBD now equals the function descriptor
was used.

Save the input JFN.

Save the filename and the file type.

Default the output file spec to FDB_OFI.

Flag the COMND JSYS to
found.

indicate

10-20

that

default

block

that

has

been

BIIISS-36 CODING EXAMPLES
6.

Save the input JFN.

Save the output JFN.

Save the (FROM) quoted string.

Save the (TO) quoted string.

10.

Set the end of the command flag.

11.

We should never get to an OUTRANGE.

10.2.5

Routine OPENFILES

ROUTINE OPENFILES : NOVALUE
1+

FUNCTIONAL DESCRIPTION:
Opens the input and output files. If an output
file was not specified, we get a JFN for a new
generation of the input file spec.
FORMAL PARAMETERS:
None
IMPLICIT INPUTS:
The INJFN must contain input file JFN.
The OUTJFN contains output file JFN or -1.
IMPLICIT OUTPUTS:
The OUTFJN may be modified
ROUTINE VALUE:
None
1-

BEGIN
IF NOT openf(. injfn,
(fld (7, of bsz) OR of_rd))
THEN
jsys detected_error;

(1)

IF .outjfn LSS 0
(2)
THEN
IF NOT gtjfn ((gj sht OR gj fou),
CH$PTR (file-spec); outjfn)
THEN
IF NOT openf (.outjfn,
THEN

(fld (7, of_bsz) OR of_wr))

END;
1.

Open the input file in 7-bit mode.

Check if an output file was specified.
10-21

BLISS-36 CODING .EXAMPLES
10.2.6

Routine BUILDTBL

ROUTINE BUILDTBL : NOVALUE
1+
1

FUNCTIONAL DESCRIPTION:
This routine deals with the (FROM) and (TO) quoted
strings. The routine calls EXPTBL to replace the
abbreviated form of lal-a2" with all the characters
between and checks their validity.
If the routine finds that the (TO) argument is empty
it fills the buffer with zeros to indicate that the
(FROM) characters are to be deleted.
If the number of characters in the (FROM) part exceeds
the number of characters in the (TO) part then the last
character in the (TO) part is replicated until the (TO)
string is as long as the (FROM) string.
Finally, the translation table used for file I/O will be
updated to reflect the specified character translations.

FORMAL PARAMETERS:
None
IMPLICIT INPUTS:

IMPLICIT OUTPUTS:
The following locations are modified:
FROM_COUNT, TO_COUNT, FROM BUFFER,TO BUFFER, TRANSTBL
ROUTINE VALUE:
None
1-

BEGIN
LOCAL
chr_ptr;
from count
exptbl (from buffer);
to_count = exptbl (to_buffer);

(I )

IF (.from count LSS .to_count) OR (.from_count EQL 0)
THEN
quote error;
IF .to_count EQL 0
(2)
THEN
CH$FILL {O, .from count, CH$PTR (to_buffer»
ELSE
IF .to count NEQ .from count
THEN
BEGIN

10-22

BLISS-36 CODING EXAMPLES

CH$FILL (CH$RCHAR A (chr ptr),
.from count - .to count,
.chr_ptr);
END;
chr_ptr = CH$PTR (from_buffer);

(3 )

INCR i FROM 0 TO .from count - 1 DO
BEGIN
LOCAL
char;
char = CH$RCHAR A (chr ptr);
CH$WCHAR (CH$RCHAR (CH$PTR (to buffer,
CH$PTR (transtbl, .char»;
END

.i»,

END;

Expand the buffers to include all
save the number of characters.

A (TO) count of zero indicates characters are to be deleted.

A (TO) count that is less than a (FROM) count indicates
the last (TO) character will be replicated.

The translation table is modified so that each
be translated is replaced by the translation.

10.2.7

lal-a2"

characters,

character

Routine EXTBL

ROUTINE

EXPTBL (buffer)

FUNCTIONAL DESCRIPTION:
Reads the characters from the given buffer
and, if the 'al-a21 form is used, fills in
in appropriate characters.
FORMAL PARAMETERS:
buffer - address of characters to be examined
IMPLICIT INPUTS:
None
IMPLICIT OUTPUTS:
Modifies BUFFER, ATOM_BUFFER
ROUTINE VALUE:
Number of characters in the buffer
1-

10-23

and

that
to

BLISS-36 CODING EXAMPLES
BEGIN
LOCAL
char,
prey char,
dst ptr,
chr-ptr,
chr-cnt,
temp_buffer

VECTOR[CH$ALLOCATION(buffer_length)]i

chr cnt
prey char = Oi
dst=ptr
CH$PTR (temp buffer)i
chr ptr
CH$PTR (. buffer) i
char = CH$RCHAR_A (chr_ptr);
WHILE .char NEQ 0 DO
BEGIN
IF .char EQL %C
THEN
BEGIN

(l)
(2)

(3 )

IF .prev_char EQL 0 THEN quote_error;
char

(4)

= CH$RCHAR_A (chr_ptr);

IF (.char LEQ .prev char)
(5)
OR (chrval (.prev_char) NEQ chrval (.char»
THEN
quote_error;
INCR i FROM .prev_char + 1 TO .char DO

(6)

BEGIN
chr cnt
IF .chr_cnt GTR buffer_length
THEN
quote_error;
CH$WCHAR_A (.i, dst_ptr);
END;
prey char
END -

ELSE
BEGIN
IF chrval (.char) EQL not_alpha_numeric
THEN
quote error:
IF (chr_cnt = .chr_cnt + 1) GTR buffer_length
THEN
quote_error;
CH$WCHAR A (.char, dst_ptr);
prey char = .char;
END;char
END;

= CH$RCHAR A (chr_ptr);
-

CH$MOVE {.chr cnt, CH$PTR (temp_buffer), CH$PTR (.buffer»;
RETURN .chr cnt
END;
10-24

BLISS-36 CODING EXAMPLES
1.

Read the first character.

Read all characters.

Check for the form 'al-a2'.

Check the validity of the range.

Include in the buffer all characters that are within range.

10.2.8

Routine CHRVAL

ROUTINE CHRVAL (chr)
1+
1 FUNCTIONAL DESCRIPTION:

This routine checks whether a given character is a
number, an upper_case letter, or a lower case letter.
FORMAL PARAMETERS:
chr - Character to check
IMPLICIT INPUTS:
None
IMPLICIT OUTPUTS:
None
ROUTINE VALUE:
numeric - Character is a number
alpha - Character is an upper case letter
alpha lower case - Character 1s a lower case letter
not_alpha_numeric - Character is not a letter or a digit

1
1-

BEGIN
SELECTONE .chr OF
SET
[%C'O' TO %C'9'] :
RETURN numeric;
[%C'A' TO %C'Z'] :
RETURN alpha;
[%C'a' TO %C'z'] :
RETURN alpha_lower_case;
[OTHERWISE] :
RETURN not alpha_numeric;
TES;
END;

10-25

BLISS-36 CODING EXAMPLES
10.2.9

Routine FILIO

ROUTINE FILIO : NOVALUE
1+

FUNCTIONAL DESCRIPTION:
This routine reads each character of the input file to
the output file, along with the corresponding translated
character. A zero in the translation table indicates that
the character is to be omitted from the output file. The
routine then closes both -the input and output file.
FORMAL PARAMETERS:
None
IMPLICIT INPUTS:
OUTJFN, INJFN, TRANSTBL all set up
IMPLICIT OUTPUTS:
None
ROUTINE VALUE:
None
BEGIN
LOCAL
char,
cond
eof;

monword,

WHILE NOT .eof DO
BEGIN
IF NOT bin(.injfn; char)
THEN
BEGIN
GTSTS( .injfn;cond);
IF .cond[GS EOF]
THEN
eof=true
ELSE
jsys_detected_error
END;
IF .char NEQ 0
THEN
BEGIN

(1)
(2)
(3)
(4)
(5)

char = CH$RCHAR (CH$PTR (transtbl,
IF .char NEQ 0 THEN bout (.outjfn,
END
ELSE
bo u t

(. ou t j f n ,

. ch a r ) ;

END;

10-26

.char» ;
.char);

BLISS-36 CODING EXAMPLES
closf (.injfn);
closf (.outjfn);
END;

END
ELUDOM

Read a character from the input file.

Check the error conditions.

End of file is found.

Report any other type of error.

If the input character is not a null, and will not translate
to a null character, the character is written to the output
file.

10-27

APPENDIX A
SUMMARY OF COMMAND SYNTAX

This appendix summarizes the command syntax and
TOPS-20 and TOPS-10.

A.I

switch

defaults

for

TOPS-20 COMMAND SUMMARY
bliss-compilation

BLISS>bliss-command-line

bliss-commandline

{ switch

input-spec

file-spec+ ...

space

blank

switch

space
switch ...

input-spec
J

output-switch
general-switch
check-switch
terminal-switch
optimization-switch
l i sting-swi tch
reference-switch
environment-switch
( /OBJECT {: fi le-spec J

outputswitch

J /LISTING {:file-specJ
} /LIBRARY {: fi le-spec J
(/MASTER-CROSS-REFERENCE {:file-specJ
( /DEBUG

general-switch

J /CODE

I
I

/NODEBUG
/NOCODE

) /VARIANT {: n J
(/ERROR-LIMIT {:nJ

check-switch
check-value

cheek-value
}
/CHECK: { (check-value, •.. )
( FIELD
, INITIAL
} OPTIMIZE
(REDECLARE

I NOFIELD
}
I NOINITIAL
I NOOPTIMIZE
I NOREDECLARE

A-I

/NOOBJECT
)
/NOLISTING
(
/NOLIBRARY
,
/NOMASTER-CROSS-REFERENCE J

SUMMARY OF COMMAND SYNTAX

/ERRS
{ /STATISTICS

terminal-switch

=-r

optimization-switch.

/NOERRS
}
/NOSTATISTICS

~~:~i~i~i II { /Nbo~TiMiz~
TJ
/NOSAFE

/SAFE
/ZIP
/QUICK

I
I

/NOZIP
/NOQUICK

----~------------------------~----------------------------

{ /PAGSIZ:

/HEADER
/UNAMES

listing-switch

/FORMAT

{ option

}

: (option, ... )

ASSEMBLY
BINARY
COMMENTARY
EXPAND
LIBRARY
OBJECT
REQUIRE
SOURCE
SYMBOLIC
TRACE

option

referenceswitch

20 I 21 I 22 I ...
/NOHEADER
I /NOUNAMES

I
I
I
I
I
I
I
I
I
I

NOASSEMBLY
NOBINARY
NOCOMMENTARY
NOEXPAND
NOLIBRARY
NOOBJECT
NOREQUIRE
NOSOURCE
NOSYMBOLIC
NOT RACE

{reference-value
/CROSS-REFERENCE { :{ (reference-value, ... )
{ /MASTER-CROSS-REFERENCE { : fi Le-spec J
.-------

referencevalue

{ MULTIPLE I NOMULTIPLE J

environmentswitch

A.2

/KA10 I /KI10 I /KL10 I /KS10
/TOPS10 I /TOPS20
/EXTENDED I /NOEXTENDED
/EXTENDED : SECTION-INDEPENDENT

TOPS-20 SWITCH DEFAULTS

The following are the switch defaults for the TOPS-20:
/OBJECT:input-file-name.REL
/NOLISTING
/NOLIBRARY
/NODEBUG
/CHECK:(FIELD,INITIAL,OPTIMIZE,NOREDECLARE)
/CODE
/NOCROSS-REFERENCE or /CROSS-REFERENCE(NOMULTIPLE)

A-2

SUMMARY OF COMMAND SYNTAX
/VARIANT:O
/ERRS
/ERROR-LIMIT:30
/NOMASTER-CROSS-REFERENCE
/NOSTATISTICS
/OPTLEVEL:2
/OPTIMIZE
/SAFE
/NOZIP
/NOQUICK
/PAGSIZ:52
/HEADER
/NOUNAMES
/FORMAT:(NOASSEMBLY, BINARY, COMMENTARY, NOEXPAND, NOLIBRARY,
OBJECT, NOREQUIRE, SOURCE, SYMBOLIC, NOTRACE)
/KLlO
/TOPS20
/NOEXTENDED

A.3

TOPS-IO COMMAND SUMMARY
bliss-command-line

{output-file-list J
source-file-list {switch ... J

source-file-list

source-file-spec, ...

output-file-list

obj ect- fi le- spec ,...
}
{ ,listing-file-spec , ...
,master-cref-spec

object-file-spec
listing-file-spec
source-file-spec
master-cref-spec

)
( file-spec
(
,

file-spec

device:

file-name { .file-type

device

any logical or physical device name

file-name

I to 6 alphanumeric characters

file-type

o to 3 alphanumeric characters

ppn

project-number ,programmer-number

A-3

J { [ppnJ

SUMMARY OF COMMAND SYNTAX

switch

library-switch
general-switch
check-switch
terminal-switch
optimization-switch
source-list-switch
reference-switch
environment-switch

library-switch

{ /LIBRARY

/DEBUGI /NODEBUG}
/CODEI /NOCODE
/VARIANT {: n J
{
/ERRLIM {: n J

general-switch

cheek-value
}
/CHECK: { (check-value " " )

check-switch

FIELD
INITIAL
OPTIMIZE
{
REDECLARE

check-value

I NOFIELD
}
I NOINITIAL
I NOOPTIMIZE
I NOREDECLARE

/ERRS
{ /STATISTICS

terminal-switch

optimization-switch

source-list-switch

reference-switch
reference-value
environmentswitch

/NOERRS
}
/NOSTATISTICS

/OPTLEVEL : { 0 I 1 I 2 I 3
/SAFE
I /NOSAFE
I /NOZIP
{ /ZIP
/QUICK
I /NOQUICK
/PAGSIZ:
/HEADER
/UNAMES
{ /LIST

option

/NOLIBRARY

ASSEMBLY
BINARY
COMMENTARY
EXPAND
LIBRARY
OBJECT
REQUIRE
SOURCE
SYMBOLIC
TRACE

20 I 21 I 22
/NOHEADER
/NOUNAMES
option
{ (option I • • •

I ...

}
)

NOASSEMBLY
NOBINARY
NOCOMMENTARY
NOEXPAND
NOLIBRARY
NOOBJECT
NOREQUIRE
NOSOURCE
NOSYMBOLIC
NOT RACE

{reference-value
{ :{ (reference-value " " )

/CREF

MULTIPLE I NOMULTIPLE

/KA10 I /KI10 I /KL10 I /KS10}
{ /TOPS10 I /TOPS20

A-4

}

SUMMARY OF COMMAND SYNTAX
A.4

TOPS-IO SWITCH DEFAULTS

The following are the switch defaults for the TOPS-IO:
/NOLIBRARY
/NODEBUG
ICHECK:{FIELD,INITIAL,OPTIMIZE,NOREDECLARE)
ICODE

/NOCREF or ICREF{NOMULTIPLE)
IVARIANT:O
/ERRS
/ERRLIM:30
/NOSTATISTICS
/OPTLEVEL:2
ISAFE

/NOZIP
/NOQUICK
/PAGSIZ:52
/HEADER
/NOUNAMES
/LIST:(NOASSEMBLY, BINARY, COMMENTARY, NOEXPAND, NOLIBRARY,
OBJECT, NOREQUIRE, SOURCE, SYMBOLIC, NOTRACE)
/KAIO
/TOPSIO

A-5

APPENDIX B
SUMMARY OF FORMATTING RULES

The ba.sic rule of indentation is that a block is indented one logical
tab deeper than the current indentation level (one logical tab equals
four spaces;
two logical tabs equal one physical
tab).
The
declarations and expressions of a block are indented to the same level
as the BEGIN-END delimiters.
The format for a declaration is:
declaration-keyword
declaration-item,

1comment

declaration-item;

1comment

where the declaration-keyword starts at the current indentation
and ea.ch declaration-item is further indented one logical tab.

level

Expressions generally have two formats:
one for expressions that
fit
on one line and one for expressIons that are longer.
If the
expression does not fit on one line, then keywords appear on separate
lines from subparts and subparts are indented one tab.
For example,
IF expressions are written in either of two formats:
IF test THEN consequence ELSE alternative:
or
IF test
THEN
consequence
ELSE
alternative;
The examples used in Chapter 3 are indented correctly,
comments have been omitted in order to save space.

B-1

although

all

APPENDIX C
MODULE TEMPLATE

This appendix contains a listing of the file MODULE.BLI, which is the
standard template for BLISS modules and routines. A module has four
parts: a preface, a declarative part,
an executable part,
and a
closing part.
The module's preface (Section C.l) appears first.
It provides
documentation explaining the module's function, use, and history.
The module's declarative part appears next
(Section C.2).
This
section provides a table of contents for the module (FORWARD ROUTINE
declarations)
and declarations of macros,
equated symbols,
OWN
storage, externals, and so on.
The module's executable part (Section C.3), consisting of zero or more
routines,
comes next; the template for a routine is in this section.
A routine has three parts: a preface, a declarative part, and code.
Finally,
every module has a closing
completes the syntax of a module.

part

(Section

C.4),

which

The module template may be used either as a checklist for module
organization and content or as the starting point in creating a new
module.
The file MODULE.BLI is supplied as' part of the BLISS support package,
on logical device SYS$LIBRARY with VAX/VMS, and on BLI: with TOPS-IO
and TOPS-20.

C.l

MODULE PREFACE
MODULE TEMPLATE (

IDENT
)

BEGIN
COPYRIGHT (C) 1982 BY
DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.
'rHIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE
INCLUSION OF THE ABOVE COPYRIGHT NOTICE.
THIS SOFTWARE OR ANY OTHER
COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY
TRANSFERRED.

C-l

MODULE TEMPLATE
THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT
CORPORATION.
DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
1++

1 FACILITY:
1

1 ABSTRACT:
1
1

ENVIRONMENT:
AUTHOR:

, CREATION DATE:

MODIFIED BY:
VERSION
1 01
1--

C.2

DECLARATIVE PART OF MODULE

TABLE OF CONTENTS:
FORWARD ROUTINE

INCLUDE FILES:

MACROS:

EQUATED SYMBOLS:

OWN STORAGE:

EXTERNAL REFERENCES:
EXTERNAL ROUTINE

C-2

ITS

MODULE TEMPLATE
C.3

EXECUTABLE PART OF MODULE
ROUTINE TEMP_EXAMPLE ()

:NOVALUE

1++
1 FUNCTIONAL DESCRIPTION:

FORMAL PARAMETERS:
NONE
IMPLICIT INPUTS:
NONE
IMPLICIT OUTPUTS:
NONE
ROUTINE VALUE:
COMPLETION CODES:
NONE
SIDE EFFECTS:
NONE
!--

BEGIN
LOCAL
!END OF TEMP EXAMPLE

END~

C.4

CLOSING FORMAT
!END OF MODULE

END
ELUDOM

C-3

APPENDIX D
IMPLEMENTATION LIMITS

Each BLISS-36 compiler implementation has limitations on the use of
certain language constructs or system interfaces.
These values are
subject to change if experience indicates they are unsuitable.

D.l

D.2

BLISS-36 LANGUAGE
The maximum number of

•

Characters in a quoted-string

1000

•

Actual parameters in a routine call

•

Structure formal parameters

•

Field components

•

Parameters of a FIELD attribute

128

•

Words initialized by a single PLIT
(that is, the maximum word count of a single PLIT)

262,143

SYSTEM INTERFACES
The maximum number of

•

Characters in an input source line

131

•

Simultaneously active (depth of nested)
REQUIRE files

D-l

APPENDIX E
ERROR MESSAGES

Whether an error is fatal to the creation of an object module (ERR) or
a warning (WARN) is context-dependent.
Informational messages (INFO)
have no effect on compilation.
BLISS-32 creates an object module for
a program that has warnings but no errors.
However, such a program
may fail to link or may fail to execute in the intended manner.
In
some
of
these error messages,
the compiler provides variable
information that points to the possible source of error.
(See the
example in Section 2.1 for an illustration.) In this appendix any
information enclosed in angle brackets « »
describes the type of
such variable information given.
Fatal error messages appear at the
end of the appendix.
000

001

002

Undeclared name:
Explanation:

The name shown has not previously been declared.

User Action:

Declare the name.

Declaration following an expression in a block
Explanation:
block.

Declarations

User Action:
block.

Reinsert the declaration properly or create

must

precede

expressions

within

new

Explanation: An excess or unnecessary left-operand precedes
operator named.

the

Superfluous operand preceding "<operator-name>"

User Action:
003

<name>

Remove the extra or unnecessary left-operand.

BEGIN paired with right parenthesis
Explanation: A close parenthesis has been encountered
compiler expected an END.
User Action:
END keyword.

when

the

Provide the appropriate pairing or insert a missing

E-l

ERROR MESSAGES
004

Missing operand preceding u<operator-name>u
Explanation: Required
infix-operator named.
User Action:

005

006

Control expression must be parenthesized
Explanation:

Parenthesis is required to achieve intended result.

User Action:

Insert missing parenthesis.

Superfluous operand following u<operator-name>"

User Action:

008

009

010

011

012

from

missing

Insert missing left-operand.

Explanation: An extra or unecessary
operator named.

007

left-operand

right-operand

follows

the

Remove the excess or unecessary right-operand.

Missing operand following u<operator-name>u
Explanation:
named.

Required right-operand

missing

User Action:

Insert missing right-operand.

from

operator

Missing THEN following IF
Explanation:

Conditional-expression is incomplete.

User Action:

Insert required keyword THEN.

Missing DO following WHILE or UNTIL
Explanation:

Pre-tested-loop-expression is incomplete.

User Action:

Insert required keyword DO.

Missing WHILE or UNTIL following DO
Explanation:

Post-tested-loop-expression is incomplete.

User Action:

Insert required keyword WHILE or UNTIL.

Name longer than 31 characters
Explanation:

Maximum name length has been exceeded.

User Action:

Reduce name length to 31 characters or less.

Missing DO following INCR or DECR
Explanation:

Indexed-loop-expression is incomplete.

User Action:

Insert required keyword DO.

E-2

ERROR MESSAGES
013

M.issing comma or right parenthesis in
list

routine

actual

parameter

Explanation: Each actual-parameter in a list must be separated
by a comma and the list must be ended by a close parenthesis.
User Action:
parenthesis.
014

015

016

017

018

019

Insert

comma(s),

necessary,

Missing FROM following CASE
Explanation:

Case-expression is incomplete.

User Action:

Insert required keyword FROM.

Missing TO following FROM in CASE expression
ExplaJlation:

Case-expression is incomplete.

User Action:

Insert required keyword TO.

Missing OF following TO in CASE expression
Explanation:

Case-expression is incomplete.

User Action:

Insert required keyword OF.

Missing OF following SELECT
Explanation:

Select-expression is incomplete.

User Action:

Insert required keyword OF.

Missing SET following OF in SELECT expression
Explanation:

Select-expression is incomplete.

User Action:

Insert required keyword SET.

Missing colon following right bracket in SELECT expression
Explanation:

Select-line of select-expression is incomplete.

User Action:
Insert colon between select-label
close bracket and select-action expression.
020

and/or

expression's

Missing semicolon or TES following a SELECT action
Explanation:

Select-line of select-expression is incomplete.

User Action:
Insert required semi-colon or keyword TES following
select-action expression.

E-3

ERROR MESSAGES
021

Address arithmetic involving REGISTER variable <variable-name>
Explanation: An attempt has been made to
register name in an expression.
User Action:

022

use

the

assignment

Evaluate and validate the expression.

Missing comma or right angle bracket in a field selector
Explanation:

Field selector is incomplete.

User Action:

Insert missing comma{s) or close bracket.

Value in field selector outside permitted range
Explanation: The value has exceeded
machine-word boundaries of the dialect.

the

size

sign

legal

range

field

User Action: Correct the address,
position,
size,
expression value according to dialect restrictions.
025

Value of attribute outside permitted range
Explanation: The value used is
permits, such as UNSIGNED(37).
User Action:

026

Field reference used as an expression has no value

User Action:

024

Correct the expression.

Explanation: The reference is invalid as a fetch
expression and cannot produce a value.

023

value

larger

than

the

Correct the attribute value.

ALIGN request negative or exceeds that of PSECT (or stack)
Explanation: The alignment-attribute boundary must be a positive
integer that does not exceed the psect-alignment-boundary.
User Action:

027

Correct the boundary value.

Illegal character in source text
Explanation: One of the 30 illegal non-printing ASCII characters
has been used (as other than data) in a BLISS module.
User Action: Only four non-printing characters
vertical-tab, and form-feed) may be used in COding.

028

Illegal
parameter
in
<lexical-function-name>
Explanation:
invalid.

call

lexical

(blank,

tab,

function

A parameter used with the named lexical-function is

User Action: Check and correct parameter usage according to
definition of the function.

E-4

the

ERROR MESSAGES
029

Attribute illegal in this declaration
Explanation: Attributes
declarations.
User Action:

030

are

restricted

use

certain

Remove the illegal attribute from the declaration.

Access formals must not appear in structure size-expression
Explanation: An access-formal provides variable
access
to
elements of a structure and should not be included with the
expression defining structure size.
User Action:
expression.

031

032

Remove the access-formal

from

the

structure-size

Conflicting or multiple specified attributes
Explanation:
used.

Contradictory or superfluous attributes

User Action:
definitions.

Check

attribute

usage

regard

have

been

specific

Two consecutive field selectors
Explanation: Irrational
field-reference.

use

field-selector

portion

User Action: Remove extra field-selector or insert parenthesis
to create a complete field-reference, such as:
.( .x<0,16»<0,8>.
033

034

Syntax error in attribute
Explanation:

n error has occurred in the coding of an attribute.

User Action:

Correct the error using the appropriate syntax.

INITIAL value <integer> too large for field
Explanation: The integer
designated field.
User Action:

035

value

shown

too

large

for

the

Decrease the value or increase the allocation-unit.

The <attribute-name> attribute contradicts corresponding
declaration

FORWARD

Explanation: The attributes of a name in an own- or global- or
routine-declaration must be identical to those used in the
associated forward-declaration.
User Action:

Correct the syntax of the attribute named.

E-5

ERROR MESSAGES
036

Literal value cannot be represented in
bits

number

Explanation: The literal-value of a
literal-declaration
larger than the field specified by the storage attribute.

User Action:
037

declared

Check sign or bit-count of range-attribute.

Lower bound of a range exceeds upper bound
Explanation: The
value
case-expression must not
range.
User Action:

038

the

of
the
low-bound
range
of
a
exceed the value of the high-bound

Correct the low-bound value.

Number of routine actual parameters exceeds implementation
of 64

for

value

has

Explanation: The number of
input-actual-parameters
routine-declaration must not exceed 64.
User Action:
039

Decrease the number of parameters to 64.

Name used in an expression has no value:

<name>

Explanation: A name that cannot denote an arithmetic
been used in an expression.
User Action:
040

041

limit

Correct the expression.

LEAVE not within the block labelled by <label-name>
Explanation:
label named.

The leave-expression is not within the block of the

User Action:

Insert the expression in the appropriate block.

Missing comma or right parenthesis in parameter list
function <lexical-function-name>

lexical

Explanation: Each lexical-actual-parameter in a
list must be
separated by a comma and the list must be ended by a close
parenthesis.
User Action:
042

Insert the missing comma(s) or close parenthesis.

Missing label name following LEAVE
Explanation:

The leave-expression is incomplete.

User Action:
Insert the appropriate
keyword LEAVE.

E-6

label

name

following

the

ERROR MESSAGES
043

Label <label-name> already labels another block
E:xplanation: The label name shown has been declared for
labeled-block.
User Action:

044

Change the name of one block or the other.

EXITLOOP not within a loop
Explanation:

An exitloop-expression has been incorrectly used.

User Action:
Insert the expression within the
t.O be exited.
045

046

(innermost)

loop

Missing structure name following REF
Explanation:
i.ncomplete.

The

structure-attribute

User Action:
keyword.

Insert the

missing

using

REF

following

the

shown

not

missing

open

keyword

structure-name

047

another

number

Specify another register.

Module prematurely ended by extra close bracket or
bracket

Explanation: The number of close brackets in a module must equal
t.he number of open brackets.
User Action: Remove the extra right bracket(s) ( END,
II>
or add the missing left bracket ( s) (BEGIN, 11(11, 11[11, 11<11).
II )

II ,

II ]

II ,

II)

048

Syntax error in module head
Explanation:

The module-head is incorrectly coded.

User Action: Correct
module-switch list.
049

050

the

module-name

the

syntax

the

Explanation:
t~he dialect.

An invalid switches-declaration has been used

with

User Action:

Correct the use of the switches-declaration.

Invalid switch specified

Name already declared in this block:

<name>

Explanation: The name shown has been declared more than once
t~he same block.

User Action:
block.

the

Remove all but one of the declarations

E-7

within

ERROR MESSAGES
051

Syntax error in switch specification
Explanation: An error has occurred in
module-switches or switches-declaration.
User Action:

052

the

coding

the

Correct the coding of the switches.

Expression must be a compile-time constant
Explanation: The
'compiler
requires
a
compile-time-constant-expression and the expression used does not
meet the criteria.
User Action:

053

Evaluate and correct the expression.

Invalid attribute in declaration
Explanation:
declaration.

illegal

attribute

has

User Action: Check the legality of the
the declaration.
054

Name in attribute list not declared as
<name>
name:

been

attribute(s)

the

used

with

used

structure

linkage

Explanation: The name shown has not been used as a structure- or
linkage-name in a structure- or linkage-declaration.
User Action:
055

Correct or declare the name appropriately.

Missing equal sign in BIND or LITERAL declaration
Explanation: The name and value of a
literal-, bind-data-,
bind-routine-item must be separated by an equal sign.
User Action:

056

Insert the missing equal sign.

Missing comma or semicolon following a declaration
Explanation: Each declaration in a list must be separated
comma and the last must be followed by a semicolon.
User Action:

057

Insert the missing comma(s) or semicolon.

Value of structure size-expression for REGISTER must not exceed 4
Explanation:
value.

Structure-size expression exceeds

User Action:
expression.

Correct the value of

E-8

the

maximum

allowed

structure-size

ERROR MESSAGES
058

Left parenthesis paired with END
Explanation:
-END pair.

A pair of parenthesis must be used to replace a "("

User Action:
Provide the appropriate pairing or insert a missing
BEGIN keyword.
059

Register <register-number> cannot be specifically declared
Explanation:
Register number shown is beyond the allowable range
of the dialect or is illegally declared, such as REGISTER R = 50.
User Action:

060

061

062

063

Insert a valid register-number.

Missing SET following OF in CASE expression
Explanation:

Case-expression is incomplete.

User Action:

Insert required keyword SET.

Missing left bracket preceding a CASE- or SELECT-label
Explanation:

Case- or select-expression is incomplete.

User Action:

Insert missing open bracket.

MODULE declaration inside module body
Explanation:

A module-body cannot contain a module-declaration.

User Action:

Correct the declaration coding.

More than one CASE-label matching the same CASE-index
Explanation: Only
case-index value.
User Action:

064

065

one

case-label

value

can

match

given

Correct either the label or index value.

Value in CASE-label outside the range given by FROM and TO
Explanation:
specified.

Value

case-label

not

within

User Action:

Correct the case-label or range values.

the

range

Missing equal sign in ROUTINE declaration
Explanation: An equal sign must precede the
routine-declaration.
User Action:

Insert the missing equal sign.

E-9

routine-body

ERROR MESSAGES
066

Two consecutive operands with no intervening operator
Explanation:

Operator-expression is incomplete or illegal.

User Action: The compiler will
operator and continue.
067

usually

insert

User Action:

069

appropriate

Missing comma or right bracket following a CASE- or SELECT-label
Explanation: Each label
in
a
list,
select-expression, must be separated by
ended with a close bracket.

068

for
a
caseor
a comma and the list

Insert missing comma(s) or close bracket.

Name to be declared is a reserved word:

<name>

Explanation:

Reserved words cannot be declared by the user.

User Action:

Select another name for the declaration.

Size-expression required in STRUCTURE declaration when storage is
to be allocated
Explanation: When a structure is associated with a name in a
data-declaration an expression must be used to specify the amount
of storage allocated.
User Action:

070

071

Insert structure-size expression.

Number of structure
limit of 31

formal

parameters

exceeds

implementation

Explanation:
allowed.

Number of access-formal parameters exceeds

User Action:

Reduce the number of parameters.

Missing comma or closing bracket in
<routine-or-macro-name>

formal

parameter

Explanation: Each formal parameter in a list must be
by a comma and the list ended with a right bracket.
User Action:
072

073

maximum

list

for

separated

Insert missing comma(s) or right bracket.

Missing control variable name in INCR or DECR expression
Explanation:

Indexed-loop-expression is incomplete.

User Action:

Insert missing loop-index name.

Missing equal sign in STRUCTURE or MACRO declaration
Explanation: An equal sign mus1: precede the
expression or structure-body or the macro-body.
User Action:

Insert the missing equal sign.

E-lO

structure-size

ERROR MESSAGES
074

Missing actual parameter list for macro <macro-name>
Explanation: The actual-parameters
are
macro-call associated with the macro named.

missing

from

the

with

the

User Action:
Insert actual-parameters to correspond
formal-name parameters from the declaration.
075

Missing closing bracket or unbalanced
parameter list for macro <macro-name>

brackets

Explanation: There must be a right bracket
bracket used in the actual-parameter list.
User Action:
076

078

every

left

Correct the pairing of the open and close brackets.

Extra actual parameters for
segment <name>

referencing

data

Explanation: Superfluous
access-actual
parameters
structure-reference for structure and data-segment named.

User Action:
077

for

actual

structure

<name>

Correct coding of structure-reference.

Missing colon following right bracket in CASE expression
Explanation:

Case-expression is incomplete.

User Action:

Insert colon following close bracket.

Name to be mapped is undeclared or not mappable:

<name>

Explanation: Name shown is undeclared or does not lie within the
scope of a data- or data-bind-declaration of the same name.
User Action:
Declare
appropriate manner.
079

name

correct

declaration

Missing comma or right bracket in structure actual parameter list
Explanation: A comma must separate each access-actual parameter
in a list and the list must be ended with a close bracket.
User Action:

080

Insert missing comma(s) or close bracket.

Illegal
characters
in
<lexical-function-name>

quoted

string

parameter

Explanation: The only valid ASCII characters for a quoted string
are:
blanks, tabs,
paired single quotes, and any printing
character except an apostrophe.
User Action: Remove illegal characters, or use %STRING
characters with %CHAR inserted before illegal ones.

E-Il

for

all

ERROR MESSAGES
081

Quoted string not terminated before end of line
Explanation:
line.

A quoted-string character sequence extends

over

User Action: Using %STRING and open parenthesis, quote first
character sequence and before end-of-line conclude with a comma;
do the same with subsequent sequences and then conclude the last
line with a close parenthesis.
082

INITIAL

Missing comma or right parenthesis following a PLIT,
PRESET item

Explanation: Each item in the list must be separated by a
and the list must be ended with close parenthesis.
User Action:
083

comma

Insert missing comma(s) or close parenthesis.

Actual parameter list
before end of program

for

macro

<macro-name>

not

terminated

Explanation: The actual-parameter list in the call for the macro
named must be ended by a close parenthesis or close bracket
(right square or right angle) even if the list is empty.
User Action:
084

Insert the missing close parenthesis or bracket.

Expression must be a link-time constant
Explanation: The
compiler
link-time-constant-expression and the
meet the criteria.
User Action:

085

086

087

requires
a
expression used does not

Evaluate and correct the expression.

String literal too long for use outside a PLIT
Explanation: The numeric value of a string-literal
word length for the dialect.

exceeds

User Action: Reduce
plit-declaration.

the

length

the

string

use

the
a

<name>

Name declared FORWARD is not defined:
Explanation:
be declared
block.

A name declared in a forward-declaration must also
by an own- or global-declaration within the same

User Action:

Make the proper declarations.

Size of initial value
«integer-value»

«integer-value»

exceeds

declared

Explanation: The initial value shown is greater than the
space reserved for it.
User Action: Decrease the
declared size value.

initial

E-12

value

and/or

size
memory

increase

the

ERROR MESSAGES
088

Missing quoted string following <lexical-function-name>
Explanation: The
quoted-string.
User Action:

089

090

requires

shown

lexical-function

Insert the required quoted-string.

Syntax error in PSECT declaration
Explanation:

The psect-declaration is improperly coded.

User Action:

Check and correct the coding of the declaration.

Missing semicolon or TES following a CASE action
Explanation:
Each case-action expression in a
list must be
followed by a semicolon and the list must be concluded by TES.
User Action:

091

Insert the missing semicolon(s) or the keyword TES.

No CASE-label matches the CASE-index
Explanation:
Based on its evaluations of the low- to high-bound
and case-label values, the compiler has determined that for the
values of the case-index no selector element will be matched.
User Action: Evaluate the case-index and its bounds relative to
the values of the case-labels, or include INRANGE and OUTRANGE
labels.

092

Some values in the range given by FROM and TO
CASE-label

have

Explanation: The compiler cannot match all of the
high-bound values with the case-label values given.

matching
low-

User Action: Evaluate the case-label values relative to those of
the low- to high-bound values.
093

No structure attribute for variable <name> in structure reference
Explanation: The variable name shown has been declared
structure-attribute is missing.

but

the

User Action:
Insert
the
appropriate
structure-attribute
for the declaration of
(structure-name and allocation-actuals)
the data-segment named.
094

Routine specified as MAIN is not defined
Explanation: The routine-name specified in the MAIN switch also
must be defined by a routine- or global-routine-declaration in
the same module.
User Action:
declaration.

Define

the

routine

E-13

with

the

appropriate

ERROR MESSAGES
095

096

%REF built-in function must be used
parameter

only

routine

Explanation:

Builtin function has been used improperly.

User Action:

Correct the use of the function.

Module body contains
constant declaration

executable

expression

actual

non-link-time

Explanation: An executable expression (such as .x) or a non-ltce
declaration should not appear within the outer most level of the
module-body.
User Action: Correct the use of expressions and
within the outer most level of the module-body.
097

Length of quoted string parameter of <lexical-function> must
exceed <integer-value>

not

Explanation: The quoted-string of the function
contain more characters than the value shown.

not

User Action:
098

099

101

102

shown

must

Correct the length of the parameter.

Cannot satisfy REGISTER declarations
Explanation: Too many registers (in linkage, globals,
or predeclared functions) simultaneously active.

built-in

User Action:
Redistribute explicit
overlaps as regards time.

prevent

Simultaneously
<integer-value>

quantities

Explanation: Two conflicting data segments have
at the same time for the register shown.

been

allocated

User Action:
100

declarations

allocated

two

usage

Correct the data segment allocations.

Division by zero
Explanation:

An illegal arithmetic operation has been performed.

User Action:

Correct the operation.

Name to be declared is missing
Explanation:

A name has not been specified in the declaration.

User Action:

Specify a name in the declaration.

Null structure actual parameter <name> has no default value
Explanation: A null
reference
has
been
made
with
access-actual expression for which no default value exists.
User Action:

Specify a value in the access-actual expression.

E-14

ERROR MESSAGES
103

Illegal up-level reference to <name>
Explanation: Reference has been illegally made from a nested
routine-declaration
to
a
name in a higher level block.
References are not permitted to LOCAL,
REGISTER, or STACKLOCAL
storage that is declared in a routine-declaration which contains
the routine-declaration currently being compiled.
User Action: Delete and relocate the reference or the name to an
appropriate block.

104

105

106

Missing ELUDOM following module
Explanation:

The end module keyword is missing.

User Action:

Insert the ELUDOM keyword at the end of the module.

Language
feature
not
<feature-keyword-name>

yet

implemented

<language>:

Explanation:
dialect.

Language feature shown is not yet supported in this

User Action:

Remove the language feature named from the program.

REQUIRE file nesting depth exceeds implementation limit of 9
Explanation: Require declarations or lexical functions have been
nested beyond allowable limit.
User Action:

107

Reconfigure nesting within allowable limits.

Structure and allocation-unit or extension are mutually exclusive
Explanation: An
allocation-unit
attribute
or
an
extension-attribute cannot appear with a structure-attribute in
an allocation declaration.
User Action:

108

Remove the contradictory attribute(s).

Allocation-unit must not follow INITIAL attribute
Explanation: The allocation-unit attribute
initial-attribute in a declaration.
User Action:

109

must

precede

the

require-

Rearrange the order of the attributes.

Missing quoted string following REQUIRE or LIBRARY
Explanation: Quoted
library-declaration.
User Action:

file-name

not

found

Insert and/or quote file name in declaration.

E-15

ERROR MESSAGES
110

Open failure for REQUIRE or LIBRARY file
Explanation: The
file
specified
in
a
requirelibrary-declaration cannot be accessed by the compiler.
User Action:
to compiler.

III

Check validity of file name or make file

available

Comment not terminated before end of <source-file-name>
Explanation: An imbedded comment must end
with
a
close
parenthesis and a percent sign; and the comment must end in the
same source file in which it began.
User Action:

112

Correct the insertion of the imbedded comment.

Definition of macro <macro-name> not
program

terminated

before

end

Explanation: A macro-declaration must be terminated by a percent
sign followed by a semicolon.
User Action:
113

Terminate the macro-name shown.

Missing semicolon,
right
subexpression of a block

parenthesis

following

END

by
a
be
concluded
Explanation: Each sUbexpression must
close
semi-colon
and the block must be concluded with a
parenthesis or an END.
User Action:
114

Insert the appropriate terminator(s).

Invalid REQUIRE or LIBRARY file specification
Explanation: The specified require file must be a valid name to
the compiler and the system,
and the library file must be a
binary file produced by the correct compiler dialect.
User Action:

115

Check and correct the validity of the file.

Expression identified by a label must be a block
Explanation: A labelled expression must be
BEGIN-END or parenthesis pair.
User Action:

116

Value of
constant

contained

Enclose the expression(s) within a block.

structure

size-expression

must

Explanation: The size-expression must meet the
compile-time-constant expression.
User Action:

within

compile-time

criteria

Evaluate and correct the size-expression.

E-16

for

ERROR MESSAGES
117

Value of structure size-expression must not be negative
Explanation: A structure size-expression
negative value.
User Action:

118

not

must

initial-attribute

Insert the missing open parenthesis.

ALWAYS illegal in a SELECTONE expression
Explanation: The select-label ALWAYS cannot be
SELECTONE, SELECTONU, or SELECTONEA expression.
User Action:

used

with

Correct the select-expression.

Case range spanned by FROM and TO exceeds implementation limit of
512
Explanation: Range of
high-bound limit of 512.
User Action:

121

Missing left parenthesis in PLIT or INITIAL attribute

User Action:

120

indicate

Evaluate and correct the size-expression value.

Explanation: A plit-item
enclosed in parenthesis.

119

must

case-expression

exceed

cannot

the

Evaluate and correct the range values.

Percent sign outside macro declaration
Explanation: An improperly quoted (%QUOTE) percent sign is
contained in a nested macro-declaration, or an extra percent sign
has been found in the source file.
User Action: Evaluate and correct the use of
for the macro-declaration.

122

percent

sign

Recursive invocation of non-recursive macro <macro-name>
Explanation: Only a conditional-macro
formal-names can be used recursively.
User Action:

123

the

with

directly

one

Correct the definition of the macro named.

Recursive invocation of structure <structure-name>
Explanation:
indirectly.

structure

cannot

User Action:

Correct the declaration of the structure named.

E-17

invoke

itself

ERROR MESSAGES
124

Expression nesting or size
limit of 300

block

Explanation: More expressions have
contains more lines than are allowed.

exceeds

been

User Action: Decrease the number of nested
number of lines in the block.
125

User Action:

the

expressions

block
or

not

the

access-actual-parameter

Evaluate and correct the operand.

Value of PLIT replicator must not be negative
Explanation: The
REP
replicator
compile-time-constant-expression
that
negative value.
User Action:

127

nested

Operand preceding left bracket in structure reference
variable name
Explanation: The operand preceding
must be a variable-name.

126

implementation

does

must
not

be
indicate

a
a

Evaluate and correct the replicator value.

RETURN not within a routine
Explanation: To properly return control to the caller,
the
return-expression must be enclosed within the BEGIN-END pair of
the called routine.
User Action: Correct the placement of the return-expression
within the outer most level of the routine, or check for the
exclusion of the END keyword from the routine.

128

BIND or LITERAL name <name> used in its own definition
Explanation: The data-name-value for a bind-declaration or the
literal-value for a literal-declaration must not contain a name
already declared bind or literal.
User Action:

129

Evaluate name shown and correct coding.

Missing comma or right parenthesis in actual parameter
<routine-or-macro-name>

list

for

Explanation: Each actual-parameter in a call list must be
separated by a comma and the list must be ended by a close
parenthesis.
User Action:
Insert the missing comma(s) or close parenthesis in
the call to the routine or macro named.

E-18

ERROR MESSAGES
130

Omitted actual parameter in call to <keyword-macro-name>
default value

has

Explan~tion:
In reference call to keyword-macro named,
default value exists for the omitted actual-parameter.

User Action: Provide
actual-parameter.
131

appropriate

value

for

the

omitted

Extra actual parameters in call to <builtin-function-name>
Explanation: The number of actual-parameters used in call to a
builtin-function must not exceed the number of formal-parameters
used in the builtin-routine.

132

133

134

call

must

Explanation: The translation-items do not meet the criteria
compile-time-constant-expressions.

for

User Action:
call.

the

table

are

User Action: Correct
actual-parameter
builtin-function named.

usage

Translation table entries
compile-time constants

CH$TRANSTABLE

call

Evaluate and correct the translation-items

Allocation unit (other than BYTE) in call to CH$TRANSTABLE
Explanation: Character-positions in
restricted to the length of a byte.

User Action:
If an allocation-unit
insert the keyword BYTE.

attribute

Length of table produced by CH$TRANSTABLE
an even number between 0 and 256

translation

necessary,

«integer-value»

Explanation: The number of translation-items used
must be even.

the

not
call

User Action: Reduce or increase the length of the table by an
even number that is closest to the number of character positions
desired.
135

Length of destination shorter
CH$COPY

than

Explanation: The
sum
of
(snl+sn2+ ... )
must not be
destination-parameter (dn).

the
source-length
parameters
greater than the value of the

User Action:

sum

source

lengths

Increase the value of the destination-parameter.

E-19

ERROR MESSAGES
136

Character-size parameter
equal to 8

<character-function-name>

must

Explanation: The
character-function
named
has
illegally
specified a character-size other than eight bits in length; only
BLISS-36 supports character sizes other then eight.
User Action:
137

Insert a character-size value of eight.

Built-in routine has no value
Explanation: A machine-specific-function that cannot produce
value has been used in a context where a value is required.
User Action:
Evaluate the required use of
and correct the coding.

138

builtin-function

Missing equal sign in GLOBAL REGISTER declaration
Explanation:

The global-register-declaration is incomplete.

User Action:
Insert
register-name.
139

the

missing

equal

sign

Illegal use of %REF built-in function
<integer-value> of call to <routine-name>

following

actual

the

parameter

Explanation:
The value of a %REF function is the address of a
temporary data segment which stores a copy of the value of the
actual-parameter; thus its use is often incompatible with the
storage requirements of a builtin-function.
User Action:
Delete %REF and provide a call to the routine named
that will provide permanent storage for the value returned.
140

Illegal use of register name as actual parameter <number> of call
to routine <routine-name>
Explanation: An undotted register name has
actual-parameter for the routine-call shown
User Action:

141

142

been

used

Provide a legal register-name.

Routine <routine-name> has no value
Explanation:

The mechanism for returning a value is suppressed.

User Action:
named.

Remove

the

novalue-attribute

from

the

routine

Missing quoted string following CODECOMMENT
Explanation:

A quoted string is required for each comrnen't.

User Action:

Enclose the affected comment(s)

E-20

in quotes.

ERROR MESSAGES
143

Missing comma or colon following CODECOMMENT
Explanation: Each quoted-string in the list must be separated by
a comma and the list must be ended with a colon.
User Action:

144

Insert the missing comma(s) and/or the colon.

Expression following CODECOMMENT must be a block
Explanation: The expression following the colon must be enclosed
with a parenthesis or BEGIN-END pair.
User Action:

145

Enclose the expression appropriately.

Illegal OPTLEVEL value <value>
Explanation: The only valid optimization-level values are:
through three.
User Action:
value.

146

Replace the switch value shown with an

User Action:

reside

the

outer

Correct the placement of the enable-declaration.

More than one ENABLE declaration in a routine
Explanation: An establisher routine must not
one handler routine.
User Action:

148

appropriate

ENABLE declaration must be in outermost block of a routine
Explanation: The enable-declaration must
most level of the establisher routine.

147

zero

enable

than

Remove all but one of the enable-declarations.

Handler specified by ENABLE must be a routine name
Explanation: The name specified by an enable-declaration must be
the name of a routine.
User Action:
declaration.

149

Provide

appropriate

routine-name

fur

the

Illegal actual parameter in ENABLE declaration
Explanation: Actual-parameters
for
enable-declarations
are
restricted in use to names declared as own-, global-, forward-,
or local-names.
User Action: Provide an
actual-parameter.

appropriately

E-21

declared

name

for

the

ERROR MESSAGES
150

<name>

Name used as ENABLE actual parameter must be VOLATILE:

Explanation: A volatile-attribute must be used to warn the
compiler
that the declared actual-parameter is subject to
unexpected change.
User Action:
Provide
actual-parameter named.
151

for

volatile-attribute

Missing comma or right parenthesis
list

ENABLE

actual

the

parameter

Explanation: Each actual-parameter in a list must be separated
by a comma and the list must be ended with a close parenthesis.
User Action:
parenthesis.
152

Insert

the

cornrna{s)

missing

LANGUAGE switch specification excludes <language-name>
Explanation: The language-name shown
language-list in a switch-declaration.
User Action:

153

154

missing

from

the

expression

keyword

following

the

call

Insert the missing language-name.

Explanation:
incomplete.

The replicator

User Action:
replicator.

Insert

the

construct

missing

Incorrect number of parameters
<lexical-function-name>

for

A lexical-function must conform

User Action:
Evaluate
lexical-function named.

156

Missing OF following REP

Explanation:
definition.

155

and/or

and

correct

lexical

function

syntactic

its

parameter

usage

for

Number of parameters of ENTRY switch exceeds implementation limit
of 128
Explanation:

The module-switch has been illegally coded.

User Action:
switch.

Reduce the number of parameters used in

Unknown name in BUILTIN declaration:
Explanation:
builtin.

the

ENTRY

<name>

Only a name predefined for BLISS can be declared as

User Action: Correct the name shown or delete it or use
form of declaration for it.

E-22

another

ERROR MESSAGES
157

<name>

Conditional out of sequence:

Explanation: The keyword named is improperly
lexical-conditional.
User Action: Evaluate and correct the
keywords are coded in the expression.
158

<%PRINT,
%INFORM,
<advisory-text>

%WARN,

sequenced

order

%ERROR,

the

which

the

%ERRORMACRO>:

Explanation: This is the form of the message number and text
that appears when one of the lexical-functions shown is used.
User Action:
function'
159

Example:

Conditional
not
source-file-name>

INFO

l58,%INFORM:'user text specified by

terminated

before

end

Explanation: Lexical-conditional is not properly
the file named.
User Action:
160

<macro

terminated

Insert the missing termination keyword %FI.

Missing formal parameter or equal sign in call to
<macro-name>

keyword

macro

Explanation: Each macro-actual-parameter in a keyword-macro-call
must be connected by an equal sign to a keyword-formal-name
previously declared in a keyword-macro.
User Action:
sign.
161

Insert the missing formal-name or the missing equal

Formal parameter <parameter-name> multiply specified in
keyword macro <macro-name>

call

Explanation:
In a keyword-macro-call to the macro named the
multiplication
of
the
keyword-formal-name shown has been
illegally specified.
User Action:
162

163

Evaluate and correct the coding of the call.

Missing %THEN following %IF
Explanation:

The coding of a lexical-conditional is incomplete.

User Action:

Insert the missing required keyword %THEN.

Actual
parameter
<parameter-name>
<routine-name> is illegal

call

routine

Explanation: An invalid actual-parameter has been used in a call
to the routine named.
User Action: Evaluate and correct the
named in the call.

E-23

use

actual-parameter

ERROR MESSAGES
164

Language feature to be removed:

Explanation:
Compiler reports that the use of feature
discontinued.

named

Explanation: The compiler reports that the feature named is
available to the dialect named.

not

User Action:
Remove the feature from the module-switch
dialect named.

for

the

Explanation:
declared.

The name used as a stack data-segment has not

been

User Action:

Correct or define name with stacklocal-declaration.

User Action:
165

166

167

Evaluate and correct module.

Language feature not present in <language>:

Name declared STACK is not properly defined

Name declared ENTRY is not globally defined:

<name>

Explanation:
In BLISS-36, name shown has been designated for
entry in global-object-module-record and has not been declared as
global.
User Action:
168

169

Define name shown with global-declaration.

Illegal value <value> in LINKAGE declaration
Explanation:

A literal value exceeds the permitted range.

User Action:

Typically skips (N) value, where N is -1 to 2.

Fetch or store applied to field of zero size
Explanation: Attempted fetchinvalid data-segment.
User Action:
Correct
structure-declaration.

170

assignment-expression

range-attribute

for

data-

an
or

Missing equal sign in FIELD declaration
Explanation: An
equal
sign
must
appear
between
the
field-set-name and the keyword SET and between each field-name
and the left-bracket of the field-component.
User Action:

171

Insert missing equal sign(s).

Missing comma on right bracket in FIELD declaration
Explanation:
Comma must appear after right-bracket
field-definition (except the last) in list.
User Action:

Insert missing comma(s}.

E-24

each

ERROR MESSAGES
172

Missing left bracket in FIELD declaration
Explanation: A left bracket must appear before
field-components in a list of field-definitions.
User Action:

173

each

list

Insert missing left bracket(s) .

Missing comma or TES in FIELD declaration
Explanation: A comma must appear between each field-component in
a list and the list must be ended with a TES.
User Action:

174

Insert missing comma(s) or keyword TES.

Missing left bracket or SET in FIELD declaration
Explanation: The equal sign following the fie1d-set-name must be
followed by a SET and each equal sign following a field-name must
be followed by a left bracket.
User Action:

175

Insert keyword SET or left bracket(s).

Number of field components exceeds implementation limit of 32
Explanation: The number of components in
exceeds the limits allowed for a structure.
User Action:
Decrease
separate structures.

176

the

Field name <name> invalid
<variable-name>

number

field-definition

components

create

structure

reference

variable

Explanation: The field-name shown as an access-actua1-parameter
does
not
agree
with
the
variable-name
shown
as
a
field-declaration.
User Action:
177

178

Evaluate and correct the uses of name.

Parameter of FIELD attribute must be a field or field-set name
Explanation:
Invalid
parameter
has
been
used
for
field-attribute;
the
name
used must be identified by
field-declaration as a fie1d- or fie1d-set-name.

a
a

User Action:
Replace
field-set-name.

parameter

Number of parameters of FIELD
limit of 128

with

attribute

declared

exceeds

fie1d-

implementation

Explanation: Excessive number of field-names have been specified
in field-attribute.
User Action:
Decrease the number of
field-set for the number in excess.

E-25

field-names

declare

ERROR MESSAGES
179

Missing equal sign in LINKAGE declaration
Explanation: An equal sign must appear
and a linkage-type.
User Action:

180

181

182

linkage-name

the

dialect

Insert the missing equal sign.

Explanation:
illegal.

The

User Action:

Evaluate and correct the linkage-type word.

linkage-type

specified

for

Illegal register number <integer> in LINKAGE declaration
Explanation:

The register number shown is invalid.

User Action:

Evaluate and correct the register number.

Multiple specification of register <register-number>
declaration

Explanation:
The register shown has
once in the declaration.

been

specified

LINKAGE
than

Evaluate and correct register specifications.

Invalid parameter location specified
Explanation:

The parameter-location specified is illegal.

User Action:
Check the legal
correct the specifications.
184

Invalid linkage type specified

User Action:
183

between

uses

parameter-locations

and

Missing comma or right parenthesis in LINKAGE declaration
Explanation:
Each parameter-location in a list must be separated
by a comma and the list must be ended by a close parenthesis.
User Action:
parenthesis.

185

Insert

the

missing

comma(s)

the

Invalid linkage attribute in LINKAGE declaration
Explanation: A
linkage-option
has
linkage-declaration that is invalid.
User Action:

185

and/or

been

used

Use a valid modifier in the linkage-declaration.

Invalid linkage modifier in LINKAGE declaration
Explanation:
An
linkage-option.

illegal

modifier

User Action:
Check and correct
modifiers for the dialect.

E-26

the

has

been

used

use

linkage-option

ERROR MESSAGES
186

Missing left parenthesis in LINKAGE declaration
Explanation: A parameter-location list must be
open parenthesis.
User Action:

187

preceded

and

the

Missing global register name in LINKAGE declaration

User Action:

used

Insert the missing global-register-name.

No match in linkage <name> for EXTERNAL REGISTER variable <name>
Explanation: The register named in the global
must be the same as the register named in
external-register-declaration.

189

Insert the missing open parenthesis.

Explanation: A global linkage-option has been
global-register-name has not been specified.

188

linkage-option
the associated

User Action: Use the same register name in both the routine
its linkage-declaration.

and

Global register <name> specified by
declared at call

not

linkage

<linkage-name>

Explanation: The register named in the global linkage-option has
not been declared in a call to the routine.

190

User Action:
Declare the register-name within
routine via an external-register-declaration.

the

WORD or Radix-50 item number
boundary

Explanation:

allocated

Multiple GLOBAL declaration of name:

byte

User Action:
Delete
global-declaration.

all

the

RAD50 11

<name>

Explanation: The global name shown has been declared
once in the same module.

192

odd

Data structure is improperly allocated.

User Action~
Correct data allocation to place WORD
value shown at a word boundary.
191

calling

extra

than

the

appearances

Multiple declaration of name in assembly source:

<name>

Explanation: The name shown has been declared more than once in
a module hat was compiled with the assembleable-listing option.
User Action:
If the intent is to run the listing through an
assembler, delete all extra appearances of the declared name~ or,
use the switch-item UNAMES in a switches-declaration to obtain
unique names.

E-27

ERROR MESSAGES
193

194

195

<declaration-name>
declaration
OBJECT(ABSOLUTE) in effect
Explanation:
expansion.

This

message

User Action:

No action is required.

not

reserved

available

when

BLISS-16

future

for

Library source module must contain only declarations
Explanation:
source file.

Executable expressions must not appear in a library

User Action:
source file.

Remove all but declaration coding from the

LIBRARY file has invalid format
Explanation:

The internal formatting of the file is incorrect.

User Action:
The specified file is probably not
library file; change the file-spec and recompile.
persists submit an SPR.
196

User Action:
Use the latest
regenerate the library file.

198

a precompiled
If the problem

LIBRARY file must be regenerated using current compiler release
Explanation: A library source file must
using the latest version of the compiler.

197

library

version

be
of

precompiled
the

compiler

LIBRARY file must be generated using <language>
Explanation: The library file must be precompiled
compiler associated with the dialect named.

User Action: Generate the library
associated with the dialect named.

the

compiler

that

has

file

with

the

LIBRARY file contains internal consistency error
Explanation:
A library file has been referenced
precompiled with errors.

User Action:
Recompile the library source file with a
qualifier, and if the problem persists submit an SPR.
199

again

Warnings issued during LIBRARY precompilation:

Explanation: The number shown is the number of
during the precompilation of the file.

warnings

User Action:

been

!LIBRARY

issued

Evaluate and correct all warnings and recompile.

E-28

ERROR MESSAGES
200

Illegal declaration type in library source module
Explanation: Only certain types of declarations may be used in a
library source file.
User Action: Remove the invalid declaration(s) from the
source file and regenerate the file.

201

library

Illegal occurrence of bound name <name> in library source module
Explanation:
file.

Bound names cannot be inserted

library

source

User Action:
Remove the declaration for the name shown from
file and regenerate the file.
202

Number of parameters of ARGTYPE
exceeds implementation limit of 128

linkage

Explanation: Excessive number of parameters
linkage-function ARGTYPE.
User Action:
203

attribute

modifier

used

builtin

<name> linkage modifier not available with this linkage type

User Action:

205

with

Reduce the parameters to an acceptable number.

Explanation: The linkage-option named cannot be
linkage-type specified.

204

the

used

with

the

Evaluate and use an appropriate linkage-option.

Length of SYSLOCAL specification not in range 1 to 15
Explanation:

This message reflects a future enhancement.

User Action:

No action· is required.

BUILTIN declaration of <name> invalid in this context
Explanation: Each name used in a builtin-declaration must be
predefined (but not predeclared); however, if a register-name or
linkage-function is used it must also be contained in
a
routine-declaration.
User Action:

206

Evaluate and correct the use of the name shown.

BUILTIN operation needs a register declared as NOTUSED
Explanation: A register required by a builtin-function
unavailable for use due to a NOTUSED linkage modifier.
User Action: Delete or change the modifier in the
linkage-declaration to allow the register to be used.

E-29

associated

ERROR MESSAGES
207

NOTUSED linkage modifier of caller is not a
called routine

subset

that

Explanation: The linkage-type and linkage-option of the
routine is incompatible with that of the called routine.
User Action:
208

caller

Evaluate and correct the linkage-declarations.

Called routine does not preserve
caller

declared

NOTUSED

Explanation: To preserve all the necessary registers, all of the
locally usable registers of the called routine must be declared
as locally usable registers in the caller routine.
User Action:
209

Evaluate and correct the linkage-declarations.

Illegal character or field too large in VERSION
Explanation: The quoted-string in the VERSION switch
must
conform to the TOPS-IO/20 version-number format, which is:
oooa(oooooo)-o; where "0" is an octal digit and "a"
is an
alphabetic.
User Action:
format.

210

Correct the string in regard to the

version-number

Stack pointers in different registers
Explanation: The number of the stack pointer register
is
assigned by default and depends on the dialect used; however, the
default number of the register can be altered by a change in the
declared linkage-type (such as FlO) while neglecting to specify
the LINKAGE_REGS option.
User Action:
Specify the desired stack pointer register number
by using a LINKAGE REGS modifier for the altered linkage-type.

211

Use of uninitialized data-segment <name>
Explanation: An attempt has been made to
named without first initializing it.
User Action:
declaration,
from it.

212

use

the

data-segment

Insert an initial-attribute in the data-segment
or assign a value to the segment before fetching

Null expression appears in value-required context
Explanation:
required.

A null expression has been used where

User Action:

Evaluate and provide a value for the expression.

E-30

value

ERROR MESSAGES
213

Expression(s) eliminated following RETURN, LEAVE or EXITLOOP
Explanation: These expressions end
the
evaluation
of
a
routine-body (return),
a block (leave), or an innermost loop
(exitloop)i therefore, they must be the last expressions inserted
before the affected block is ENDed,
if not all subsequent
expressions will not be compiled.
User Action: Evaluate and correct the insertion of
or exit-expression.

214

the

return-

Language feature not transportable
Explanation: The feature specified for the dialect(s) defined by
the language-switch is not transportable.
User Action:

215

Evaluate the feature and take appropriate action.

Language feature not transportable:

<name>

Explanation: The feature specified by the name shown is not
transportable to the dialect(s) defined by the language switch.
User Action:
action.
216

Evaluate the feature

named

and

take

appropriate

Language feature not transportable:
Explanation: The feature specified by the keyword shown is not
transportable to the dialect(s) defined by the language switch.
User Action:
action.

217

Evaluate the feature

shown

and

take

GLOBAL or EXTERNAL name not unique in 6 characters:
Explanation:
In BLISS-16 and BLISS-36, at least
in a global- or external-name must be unique.
User Action:

218

six

appropriate

<name>
characters

Evaluate and correct the global- or external-name.

Implicit declaration of BUILTIN <linkage-name> to be withdrawn
Explanation:
The compiler implicitly declares the function named
as builtin when a FORTRAN linkage-routine is being compiled.
User Action: Add
proper scope.

219

explicit

builtin-declaration

within

the

Empty compound expression is illegal
Explanation: A compound-expression block does not contain any
declarations, but it must contain at least one expression to be
legal.
User Action:
Insert an expression in the
entire block form.

E-31

block

delete

the

ERROR MESSAGES
220

PRESET items have overlapping initialization
Explanation: A preset-value must not occupy more storage than is
allocated for the da~a segment, and the field-names described in
the preset-items must not overlap.
User Action:
Evaluate
preset-attribute.

221

and

correct

User Action:
preset-item.

Insert

Source line too long.

the

missing

the

must

preset-attribute

open

bracket

User Action:

before

the

exceeds

the

Truncated to 132 characters.

Explanation: A
line
in
the
source
implementation limit of 132 characters.

223

coding

Missing left square-bracket in PRESET attribute
Explanation:
Each preset-item
preceded by an open bracket.

222

the

file

Decrease the size of the source line.

Name
used
in
<routine-name>

routine-call

not

declared

ROUTINE:

Explanation: The routine-designator used in a routine-call must
yield
a
value
declared
as
a
routine-name
in
a
routine-declaration.
User Action: Assure that the name used in
declared in a routine-declaration.
224

the

routine-call

INTERRUPT general routine call is invalid
Explanation: A linkage-name defined by an INTERRUPT linkage-type
must not be used with this dialect in a general-routine-call.
User Action: With this dialect, use an ordinary-routine-call
invoke the interrupt routine.

225

Invalid linkage attribute specified <attribute-name> is assumed
Explanation: A linkage-attribute must be either a predeclared
linkage-name or one specified in a linkage-declaration.
User Action:
Evaluate and correct the use of the linkage-name in
the linkage-attribute.

226

Value of a linkage name <name> is outside permitted range
Explanation:
The value of the linkage-name shown
compatible and transportable range of the dialect.

exceeds

the

User Action:
Provide a
linkage-name
that
is
compatible and transportable range of the dialect.

within

the

E-32

ERROR MESSAGES
227

Effective position and size outside of permitted range
Explanation: The values of the field-reference parameters have
exceeded the structure-allocation specified for the data-segment.
User Action:
Evaluate and correct the value of
field size parameters.

228

offset

and

Explanation: The instruction named did not produce a value
executed by the machine-specific-function MACHOP.

when

Builtin machop <name> has no value

User Action:
Select a machine instruction that
value when executed.
229

the

Parameter <parameter-name> of builtin <name>
the range

will

has

produce

value

outside

Explanation: The parameter named for the builtin-function
indicates a value that exceeds the specified range.

230

named

User Action:
Decrease the value of the parameter
conform with the specifications of the function named.

named

Parameter <parameter-name> of builtin <name> must be a
constant expression

link-time

Explanation: The parameter named for the builtin-function
is an invalid expression.

named

User Action:
Replace the parameter named with an expression that
meets the criteria for a link-time-constant.
231

Invalid linkage attribute specified CLEARS TACK is added
Explanation:
dialect.

The CLEARSTACK linkage-option is illegal with

User Action:
Delete
linkage-declaration.
232

the

CLEARS TACK

modifier

from

this
the

OTS linkage specified twice
Explanation: The ots-option of the ENVIRONMENT switch specifies
the use of a standard OTS file and linkage; therefore the switch
must not appear in the same module with an OTS switch and an
OTS LINKAGE switch which specifies the use of a nonstandard file
and-linkage.
User Action:

233

Evaluate and correct the coding for OTS.

OTS linkage <name> not declared before first routine declaration
Explanation: The linkage-name specified by the
OTS LINKAGE
switch must be predeclared or appear in a linkage-declaration
that precedes the first routine-declaration in the module.
linkage-name
shown
in
a
User Action:
Define
the
linkage-declaration that precedes the first routine-declaration
in the module.
E-33

ERROR MESSAGES
234

OTS linkage <name> may
parameters by register

not

use

global

registers

specified
register

Explanation: The linkage-name
switch
must
not
specify
parameter-locations.

by the
OTS LINKAGE
or
global-register
of

the

Explanation:
The linkage-name shown has not been declared
to its use in an OTS LINKAGE switch.

prior

User Action:
Evaluate
and
correct
the
use
parameter-locations in the linkage-declaration named.
235

OTS linkage <name> not defined before it's used

User Action:
Declare
linkage-declaration.
236

pass

the

First PSECT declaration
allocates storage

shown

linkage-name

appears

after

with

declaration

that

Explanation:
In BLISS-36,
the first psect-declaration in a
module must appear before the first declaration that causes
storage to be allocated or object code to be generated.
User Action:
Reinsert the first psect-declaration before the
first data- or routine-declaration (external and forward types
excepted) and/or the first plit-expression in the module.
237

239

Exponent for floating or double floating literal out of range
Explanation:

Exponent value is too large for floating literal.

User Action:

Evaluate and correct the value of the exponent.

String exceeding implementation limits «number> characters)
truncated

was

Explanation:
The string-function (such as %EXACTSTRING)
exceeds
the implementation limit of 1000 characters for the length of a
sequence.
User Action:
240

Decrease the size of the string.

<reserved-word> declaration is illegal in STRUCTURE declaration
Explanation:
The declaration defined by the reserved-word
(such as OWN) is illegal in a structure-declaration.
User Action:

242

shown

Remove the illegal declaration.

Output formal parameter <name> in
described in linkage

routine

declaration

was

not

Explanation: An output-parameter-location has not been specified
in
the
corresponding
linkage-declaration
for
the
output-formal-parameter shown.
User Action:
Specify the output-parameter-location
for
output-formal-parameter named in the routine-declaration.
E-34

the

ERROR MESSAGES
243

output actual parameter was not described in linkage
Explanation: An output-parameter-Iocation has not been specified
in
the
corresponding
linkage-declaration
for
an
output-actual-parameter specified in the caller routine.
User Action: Specify an
output-parameter-Iocation
for
output-actual-parameter specified in the caller routine.

244

the

Name declared UNDECLARE is not defined:<name>
Explanation: An undeclare-declaration has been used with a
that has not been declared.
User Action:

246

name

Declare the name shown.

FORWARD declaration
declaration

<name>

cannot

Explanation: A name declared as FORWARD must
ROUTINE, OWN, or GLOBAL name.

satisfied
be

BIND

defined

User Action:
Evaluate and correct the use of the specified
on the FORWARD declaration.
247

Character size parameter of <name> must
compile-time constant in the range I to 36

equal

name

Explanation: The character-size value of the named character
function is either outside of the permissible range or not a
compile-time constant.
User Action:
Provide
permissible range.
248

compile-time

constant

within

<number> is an illegal character size for a global byte
A local byte pointer will be generated

the

pointer.

Explanation: A program with extended addressing was compiled
having a CH$PTR function size value that is invalid for creating
a global byte pointer.
User Action:
not,
change
pointer.
249

Determine if a local byte pointer is acceptable; if
the size value to reflect a valid global byte

EXTENDED addressing is not supported under TOPS-IO
Explanation:
The compiler has reported that
extended addressing under TOPS-IO.

User Action:
program.

feature

Remove the extended

E-35

addressing

cannot

support
from

the

ERROR MESSAGES
250

Reference to uninitialized LOCAL, STACKLOCAL, or REGISTER
<name>

symbol

Explanation: The routine contains a reference to the value of
the variable named prior to its first assignment.
This message
can also occur if a reference and an assignment to the same
variable occurs in different branches of an IF, CASE, or SELECT
statement contained within a loop.
User Action:
251

Intitialize the symbol prior to its first use.

Symbol <name> is declared <class> in an outer block
Explanation: A symbol name declared in an inner block
inaccessible because it is also declared in an outer block.

User Action:
Ensure that all references to the name in the inner
block refer to the symbol declared there and not to the one
declared in the outer block.
252

Test expression is always <true/false>
Explanation:
During the optimization of an IF, WHILE,
or UNTIL
structure a test expression has been reduced to a constant with
the possible elimination of code.
User Action:

253

Evaluate the test expression for proper operation.

Action <number> <never/always> true.

<elimination-text>

Explanation:
One or more of the actions statements in a SELECT
or SELECTONE construct cannot be compiled and consequently
certain actions have been eliminated.
User Action:
operation.

E.l

Evaluate

the

select

statements

for

proper

BLISS COMPILER FATAL ERRORS

The following fatal error messages indicate serious problems with the
environment and/or compiler.
When such a condition is detected,
compilation terminates immediately.
INTERNAL COMPILER ERROR
The compiler has failed an internal consistency check.
This
message may be followed by an error number.
BLISS-32 then issues
a traceback printout. BLISS-36 is unable to issue a traceback.
Please submit an SPR and include a copy of the program that
generated this message.
INSUFFICIENT DYNAMIC MEMORY AVAILABLE
On the VAX, this error may indicate a bug in the compiler.
On
the DECsystem-lO and -20, the userls program may be too large to
compile.

E-36

ERROR MESSAGES
I/O ERROR ON INPUT FILE
An error occurred while accessing an input file.
This may be
preceded by other error messages which provide more specific
information about the error.
I/O ERROR ON OBJECT FILE
An error occurred while accessing the output object file.
This
may be preceded by other error messages which provide more
specific information about the error.
I/O ERROR ON LISTING FILE
An error occurred while accessing the output listing file.
This
may be preceded by other error messages which provide more
specific information about the error.
I/O ERROR ON LIBRARY FILE
An error occurred while accessing a BLISS precompiled library
file.
This may be preceded by other error messages which provide
more specific information about the error.
LIBRARY PRE-COMPILATION EXCEEDS COMPILER LIMIT
A pre-compiled BLISS library cannot be larger than approximately
2048
(10/20) disk blocks; the library file will be deleted. VAX
libraries have no restrictions.
MACRO OR STRUCTURE DECLARATION WITHIN STRUCTURE BODY
This is a
language.

permanent

implementation

restriction

the

BLISS

restriction

the

BLISS

REQUIRE DECLARATION WITHIN MACRO BODY
This is a
language.

permanent

implementation

FATAL ERROR IN COMMAND LINE
This message appears on VAX-VMS only, for BLISS-32 or BLISS-16.
The user1s command line was improperly formed.
A previous error
message provided additional information to describe what was
wrong.
I/O ERROR DURING COMMAND LINE SCANNING
This message appears on TOPS-IO or TOPS-20 when a severe error is
encountered in parsing the command line.
NESTED EXPRESSION TOO DEEP.

SIMPLIFY AND RECOMPILE

The source program contains more than 64 levels of nested blocks,
each containing declarations.
UNRECOVERABLE SOURCE ERRORS.

CORRECT AND RECOMPILE

This message appears on VAX-VMS only, for BLISS-32 or BLISS-16.
Errors previously encountered by the compiler have confused it to
the point at which it cannot continue the compilation.

E-37

APPENDIX F
SAMPLE OUTPUT LISTING

The following pages contain the complete output listing for the module
TESTFACT.
Chapter 3 examples use excerpts from this listing.

F-l

TESTFACT

3-Jun-1983 18:24:36
2-May-1983 15:27:31

TOPS-20 Bliss-36 3A(200)
PS:(DIRECTORY)MYPROG.B36.6

MAINPROG)
MODULE TESTFACT (MAIN
0001
0002
0
BEGIN
WARN#048
1 Ll:0002
Syntax error in module head
0003 1
0004 1
OWN
A,
0005 1
0006 1
B;
0007 1
ROUTINE IFACT (N)
0008 1
BEGIN
0009
2
0010 2
LOCAL
RESULT;
0011
2
0012 2
RESULT = 1;
INCR I FROM 2 TO .N DO
0013 2
0014 2
RESULT = .REULT*.I;
.................. 1
Ll:0014
WARN#OOO
Undeclared name:
REULT
.RESULT
0015 2
END;
0016 1
TITLE
TWOS EG

TESTFACT

.REQUEST

A:
B:

ACO=
ACl=
AC2=
AC3=
AC4=
AC5=
AC6=
AC7=
ACI0=
ACll=
AC12=
AC13=
AC14=
FP=
AC16=

SYS:B362LB.REL

RELOC
BLOCK
BLOCK

EXTERN

REULT

000000'
000000'
000001'

1
1

0
1
2
3
4
5
6
7
10
11
12
13

14
15
16

Figure F-l: Sample Output Listing

Page
(1)

TESTFACT
SP=

3-Jun-1983 18:24:36
2-May-1983 15:27:31

TOPS-20 Bliss-36 3A(200)
Page
PS:(DIRECTORY>MYPROG.B36.6 (1 )

IFACT:
L.l:
L.2:

RELOC
MOVEI
MOVEI
JRST
MOVE
IMUL
ADDI
CAMG
JRST
POPJ

Routine Size:
0017
0018
0019
0020
0021
0022
0023

1
1
1
1
1
1
1

400000
ACl,l
AC2,1
L.2
ACl,REULT
ACl,AC2
AC2,1
AC2,-1(SP)
L.l
SP,

RESULT,l
1,1
L.2
RESULT,REULT
RESULT,I
1,1
I,N
L.l
SP,

400000'
400000'
400001'
400002'
400003'
400004'
400005'
400006'
400007'
400010'

201
201
254
200
220
271
317
254
263

01
02
00
01
01
02
02
00
17

0
0
0
0
0
0
0
0
0

00
00
00
00
00
00
17
00
00

000001
000001
400005'
000000*
000002
000001
777777
400003'
000000

0012
0013
0014
0013
0008

9 words

§:

ROUTINE RFACT (N) =
IF .N GTR 1
THEN
.N * RFACT (.N - 1)
ELSE
1;

"'a

tot

tzl

c::::

Iij

I
tv

RFACT:

L. 3:
L.4:

PUSH
MOVE
CAIG
JRST
MOVE
SUBI
PUSH
PUSHJ
IMUL
ADJSP
JRST
MOVEI
POP
POPJ

Routine Size:
0024
0025
0026
0027
0028
0029

1
1
2
2
2
1

SP,AC16
AC16,-2(SP)
AC16,1
L.3
ACl,AC16
ACl,l
SP,ACI
SP,RFACT
ACl,AC16
SP,-l
L.4
ACl,l
SP,AC16
SP,

SP,AC16
AC16,N
AC16,1
L.3
ACl,AC16
ACl,l
SP,ACI
SP,RFACT
ACl,AC16
SP, -1
L.4
ACl,l
SP,AC16
SP,

400011'
400012'
400013'
400014'
400015'
400016'
400017'
400020'
400021'
400022'
400023'
400024'
400025'
400026'

14 words

ROUTINE MAINPROG : NOVALUE
BEGIN
A = IFACT (5) ;
B = RFACT (5) ;
END;

Figure F-l (Cont.): Sample Output Listing

261 17 0 00
200 16 0 17
307 16 0 00
254 00 0 00
200 01 0 00
275 01 0 00
261 17 0 00
260 17 0 00
220 01 0 00
105 17 0 00
254 00 0 00
201 01 0 00
262 17 0 00
263 17 0 00

000016
777776
000001
400024'
000016
000001
000001
400011'
000016
777777
400025'
000001
000016
000000

0018
0019
0021

I-i
"'a

c::::

I-i

tot
~
rn

I-i
~

G'l
0019
0018

TESTFACT

3-Jun-1983 18: 24: 36
2-May-1983 15:27:31

MAINPROG:
PUSH
PUSHJ
MOVEM
PUSH
PUSHJ
MOVEM
ADJSP
POPJ
C.l :
EXP
;

SP,C.l
SP,IFACT
ACl,A
SP, C.l
SP,RFACT
ACl,B
SP,-2
SP,
5

Ro ut ine Size:
0030
0031
0032

1
1
0

SP, [5]
SP,IFACT
AC1,A
SP, [5]
SP,RFACT
AC1,B
SP,-2
SP,
5

TOPS-20 B1iss-36 3A(200)
Page
PS:<DIRECTORY)MYPROG.B36.6 (1 )
400027'
400030'
400031'
400032'
400033'
400034'
400035'
400036'
400037'

261 17
260 17
202 01
261 17
260 17
202 01
105 17
263 17
000000

0
0
0
0
0
0
0

00 400037'
0027
00 400000'
00 000000'
00 400037'
0028
00 400011'
00 000001'
00 777776 0026
o 00 000000 0025
000005

9 words

END
ELUDOM
Ul

t-:rj

RELOC
.STACK. :BLOCK

2
4000

RELOC
.MAIN. : TDZA
MOVEI
JSYS
MOVE
PUSH
PUSH
PUSH
PUSH
PUSH
MOVE
SETZB
PUSHJ
ADJSP
L.5:
JSYS
JRST
C.2:
XWD

400040
AC 1 ,ACI
ACl,l
147
AC2,C.2
AC2,SP
AC2,ACll
AC2,AC7
AC2,ACO
AC 2, AC 1
SP,AC2
FP,EFPNT.
SP,MAINPROG
SP,-5
170
L.5
-4000,.STACK.-l

Routine Size:
END

Information:

AC1,ACl
ACl,l
147
AC2, [-4000" .STACK.-l]
AC2, SP
AC2,ACll
AC2,AC7
AC2,ACO
AC2,AC1
SP,AC2
FP,EFPNT.
SP,MAINPROG
SP,-5
170
L.5
-4000,.STACK.-l

400040'
400040'
400041'
400042'
400043'
400044'
400045'
400046'
400047'
400050'
400051'
400052'
400053'
400054'
400055'
400056'
400057'

16 words
.MAIN.

Low segment length:
High segment length:

000002'
000002'

2050 words
48 words

Figure F-l (Cont.): Sample Output Listing

"tI

t'4
t:EJ

634 01 0 00 000001 0000
201 01 0 00 000001
104 00 0 00 000147
200 02 0 00 400057'
261 02 0 00 000017
261 02 0 00 000011
261 02 0 00 000007
261 02 0 00 000000
261 02 0 00 000001
200 17 0 00 000002
403 15 0 00 000000*
26C 17 0 00 400027'
105 17 0 00 777773
104 00 0 00 000170
254 00 o 00 400055'
774000 000001'

0
t-3

"tI

c::
t-3

t'4

t-3

(j)

TESTFACT
Warnings:
Errors:

3-Jun-1983 18:24:36
2-May-1983 15:27:31

TOPS-20 Bliss-36 3A(200)
Page
PS:(DIRECTORY)MYPROG.B36.6 (1)

2
0

Size:
48 code + 2050 data words
Run Time:
00:00.8
Elapsed Time:
00:03.7
Lines/CPU Min:
2382
Lexemes/CPU-Min: 9528
Memory Used:
3 pages
Compilation Complete

Figure F-l (Cont.): Sample Output Listing

APPENDIX G
MIXING BLISS-36 MODULES AND BLISS-IO MODULES

The need may arise for a programmer to have both BLISS-36 and BLISS-IO
modules
in a single program:
for example,
for an incremental
conversion of a BLISS-IO program to BLISS-36.
(Refer to CVTlO in
Chapter 9.)
Another example would be for writing a BLISS-36 program
that uses a package written in BLISS-IO or an assembly language
package that was designed for use by BLISS-IO modules.
Both BLISS-36 and BLISS-IO can conveniently generate code that uses
either
the
BLISSIO
linkage
(stack-pointer=O,
frame-pointer=2,
value-register=3)
or
the
BLISS36C
linkage
{stack-pointer=15,
frame-pointer=13, value-register=l}.
To generate code that uses BLISSIO linkage:
•

In BLISS-36 modules, use the module switches LINKAGE (BLISSlO)
and ENVIRONMENT (BLISSlO_OTS).

•

In BLISS-IO modules, the default is to generate code that uses
BLISSIO linkage conventions.

To generate code that uses BLISS36C linkage:
•

In BLISS-36
BLISS36C.

modules,

the

default. linkage

•

In BLISS-IO modules, use the /Z switch in the BLISS-IO command
line, or use the following module switches:
SREG = IS, FREQ = 13, VREG

convention

I, DREGS = 7, RESERVE(O,14}

Code generated by BLISS-IO uses utility routines to save and restore
registers.
These are generated as part of a BLISS-IO module that
contains the STACK or PROLOG module switch or is compiled with the
/p
command-line switch.

G-l

APPENDIX H
USER-GENERATED OTS FILES

The BLISS-36 object-time system (OTS) contains routines that implement
various character handling functions and the condition handling
mechanism.
OTS object files use either BLISS-IO or BLISS-36C linkage
conventions.
The user determines which convention is to be used by
setting either the BLISSIO OTS or BLISS36C OTS (default)
environment
switch.
The BLISS-36 dialect of the BLISS language permits a programmer to
define a linkage convention that is incompatible with either the
BLISS-IO or BLISS-36C linkage.
Incompatible means that a routine
using one linkage could not call a routine that uses the other
linkage. This would be the case if calling and called routines used
different registers as stack pointers. A programmer may be forced to
use such a linkage when interfacing to a set of utility routines
written in assembly language or in BLISS-IO with non-default linkage
registers.
The compiler generates in the object file a request to the linker for
a user-generated OTS file and code calls to it using a user specified
linkage when OTS and OTS_LINKAGE switches appear in the module header.
To generate an OTS file, create a file (e.g., LINKAGE.MAC) having
following format:
DEFINE TYPE, < .

•

the

where the ellipsis represents one or more of the macros discussed
later.
Then, starting at monitor command level, type the following:
TOPS-20

TOPS-IO

@MACRO
*USROTS=LINKAGE,BLSOTS
*A C

.R MACRO
*U8ROTS=LINKAGE,BLSOTS
*AC

The OTS source file (BLSOTS.MAC) is assumed to be somewhere in the
user's search path.
If it is not, an appropriate device should be
defined and specified.
If no linkage file
BLISS-36C linkage.

included,

the

OTS

assembled

with

the

The first line of TYPE should specify either PUSHJ or FlO, which
correspond to the BLISS-36 linkage types of the same names.
These
must be the first item in TYPE.
If neither is specified,
PUSHJ is
assumed.
LINKAGEREGS, PRESERVE, and NOPRESERVE declarations may then
appear in any order. Each should be put on a separate line.

H-l

USER-GENERATED OTS FILES
The LINKAGEREGS declaration may take from zero to four arguments
enclosed in angle brackets « ».
The first argument represents the
register number to be used for the stack pointer (default is 0).
The
second argument represents the register number for the frame pointer
(default is 2).
Using a negative number or the default value
indicates that a preserved register is to be used as a frame pointer
if one is needed and no frame list is to be kept.
The third argument
represents the register number for the returned value (default is 3).
The fourth argument represents the register number to be used for the
applied pointer
(default is 14). This argument has meaning only if
the linkage type is FlO; it is ignored if the linkage type is PUSHJ.
PRESERVE identifies registers whose contents should be saved by any
routine that uses them. Any register that was previously listed in a
NOPRESERVE declaration or that was or will be specified in a
LINKAGEREGS declaration is ignored.
If no PRESERVE declaration is
included, the default is:
PRESERVE <0,11,12,13,14,15>

(if linkage type is PUSHJ)

or
PRESERVE <>

(if linkage type is FlO)

NOPRESERVE identifies "temporary" registers; that is, they may be used
freely, but may be modified by making a call. Any register previously
listed in a PRESERVE declaration or that was or will be specified in a
LINKAGEREGS declaration is ignored.
If no NOPRESERVE declaration is
included, the default is:
NOPRESERVE <1,2,3,4,5,6,7,8,9,10> (if linkage type is PUSHJ)
or
NOPRESERVE <1,2,3,4,5,6,7,8,9,10,11,12,13>
FlO)

(if linkage type is

All register numbers are specified in decimal radix.
The user may also include the declaration SET%KL.
This specifies that
the
OTS is to be run on a KL-10 processor
(for example,
a
DECSYSTEM-20).
If SET%KL is not specified, the generated code is for
a KA-IO processor and may be run on any DECsystem-10 or DECSYSTEM-20.
The TOPS20 macro may be used to indicate that the code is destined for
a DECSYSTEM-20.
This will have a side-effect of doing a SET%KL.
Macros are available for three of the four predefined linkages for
BLISS-36.
They may be used instead of PUSHJ, FlO, LINKAGEREGS,
PRESERVE, and NOPRESERVE.
The macros are:
BLS36C
BLSSIO
FRTFUNC

corresponding to BLISS36C
corresponding to BLISSIO
corresponding to FORTRAN FUNC

A linkage corresponding to FORTRAN SUB may not at this time be defined
because of the absence of preserved registers. An OTS with linkage
FRTFUNC is safely callable from a BLISS routine with
linkage
FORTRAN SUB.
The declaration SET%PSECT generates a PSECTED OTS as opposed to an OTS
segmented by default. A PSECTED OTS is required for programs running
with extended addressing.

H-2

USER-GENERATED OTS FILES

The default PSECT names are: $OWN$,
$GLOBAL$,
$PLIT$,
and $CODE$;
however, you can change these names by redefining the following
macros:
PSECTOWN
PSECTGLOBAL
PSECTPLIT
PSECTCODE

(defaults
(defaults
(defaults
(defaults

to
to
to
to

.PSECT
.PSECT
.PSECT
.PSECT

$OWN$)
$GLOBAL$)
$PLIT$)
$CODE$)

For example, the $OWN$ and $CODE$ PSECT can be personalized
and MYCODE, respectively, as follows:

MYOWN

DEFINE TYPE,
<

PUSHJ
TOPS20
SET%PSECT
LINKAGEREGS<l5,l3,l>
PRESERVE<O,6,7,8,9,lO,ll,l2,14>
NOPRESERVE<2,3,4,5>
>

DEFINE PSECTOWN
<

.PSECT MYOWN
>

DEFINE PSECTCODE
<

.PSECT MYCODE
>

For additional information, refer to "BLISS-36
in Chapter 13 of the BLISS Language Guide.

H-3

Linkage

Declarations"

INDEX

Abstraction mechanisms, 7-9
Add double operands, 5-3
Add float operands, 5-4
Add float-G operands, 5-4
Address calculations, 7-13
Address-relational operators,
7-15
Alignment-attribute, 7-12
Allocation of scalar data, 7-10
Allocation-unit attribute, 7-12,
7-18
Ampersand, 4-4
Arithmetic shift, 5-5
%ASCII, 7-5
ASSEMBLY, 1-16, 2-15
Asterisk, 4-4
At sign (@), 1-22
BCREF, 9-4
command line format, 9-4
command semantics, 9-5
command switches, 9-5
BINARY, 1-16, 2-15
Binding of names, 8-6
BLISS-IO language features, 9-7
BLISS-IO translations, 9-7
of BIND declarations, 9-8
of CASE expressions, 9-9
of macros, 9-9
of normal declarations, 9-8
of REQUIRE declarations, 9-8
of ROUTINE declarations, 9-9
of SELECT expressions, 9-9
of SWITCHES declarations, 9-8
Bliss-command-line, 1-3, 2-3
Bliss-compilation, 1-3
BLISSIO, G-l
BLISSIO OTS, G-l
%BLISS16, 7-5
%BLISS32, 7-5
%BLISS36, 7-5
%BPADDR, 7-4
%BPUNIT, 7-4
%BPVAL, 7-4, 7-12, 7-23
Breakpoint, 4-5
Byte
build a byte pointer, 5-15
copy, 5-6
fetch, 5-16
increment a byte pointer, 5-11
store, 5-15
%C, 7-5
CH$ALLOCATION, 7-21
CH$PTR, 7-22
Character sequence functions,
7-17
Character sequences (strings),
7-16
/CHECK, 1-10, 2-9

Check switch, 1-10, 2-8
/CODE, 1-9, 2-8
CODE, 8-7
Code generation, 8-7
Coding errors
computed routine calls, 6-4
conflicting names, 6-6
embedded routines, 6-7
in complex tests, 6-4
missing dots, 6-3
missing expression, 6-3
missing or disappearing code,
6-5
nested routines, 6-6
parentheses, 6-4
semicolon, 6-3
signed/unsigned fields, 6-4
unsigned indexed-loop, 6-7
use of complex macros, 6-5
useless value expressions, 6-3
valued/nonvalued routines, 6-3
Coding examples
PSINT program, 10-1
TRANS program, 10-10
Command
LINK, 4-2
NSAVE, 4-1
SAVE, 4-1
SIX12, 4-4
Command syntax
TOPS-IO summary, A-3
TOPS-20 summary, A-I
Command-line
indirect files in, 1-22
switch, 1-3
TOPS-IO switches, 2-6
TOPS-20 switches, 1-5
Command-line semantics, 1-3, 2-3
Command-line syntax, 1-3
COMMENTARY, 1-16, 2-15
Compare double operands, 5-5
Compare float operands, 5-5
Compare float-G operands, 5-6
Compilation
concatenation of files, 1-2
conditional, 7-5
multifile, 1-2
statistics, 3-2
summary, 3-2 to 3-3, 3-22
TOPS-IO operating procedures,
2-1
TOPS-20 operating procedures,
1-1
Compile-time constant expressions,
7-3
Compiler
organization and processing,
8-1
output, 3-1
overview, 8-1

Index-l

INDEX
Compiler (Cont.)
phases, 8-1
CODE, 8-7
DELAY, 8-6
FINAL, 8-7
FLOW, 8-2
LEXSYN, 8-1
OUTPUT, 8-8
TNBIND, 8-6
Compiling a BLISS program, 2-1
Complexity, language, 7-3
Concatenation of files, 1-2, 1-22
Conditional compilation, 7-5
Control expressions, 7-15
Conversion program (CVTIO), 9-6
Convert double to float, 5-6
Convert double to integer, 5-7
Convert float to double, 5-7
Convert float to float-G, 5-7
Convert float-G to floating, 5-8
Convert float-G to integer, 5-8
Convert floating to integer, 5-8
Convert integer to double, 5-9
Convert integer to float, 5-9
Convert integer to float-G, 5-9
Cross-reference listing
symbol types (Table), 3-16
/CROSS REFERENCE, 1-18
CVTIO,-9-6
Data segments
changing contents of, 8-3
DCB BLOCK structure, 7-25
DDT, 4-3, 4-5
/DEBUG, 1-9, 2-8, 2-21, 4-3
Debugging, 4-3
example, 4-3
SIX12 debugger, 4-3
use of BINARY switch, 3-8
Defaults
extension, 2-4
file type, 1-5
object listing, 3-8
Switches, 1-20
switches, 2-18
DELAY, 8-6
Divide double operands, 5-10
Divide float operands, 5-10
Divide f1oat-G operands, 5-10
Dots, missing, 6-3
Environment switches, 1-18, 2-17
Equivalencing, 7-15
/ERRLIM, 2-8
Error messages, E-1
fa rm 0 f, 3 - 23
in compilation summary, 3-2
on the terminal, 3-3
pointer, 3-24
/ERROR-LIMIT, 1-9
Errors
detection during LEXSYN phase,
8-2
discussion of, 6-2

/ERRS, I-II, 2-10
Examples
debug, 4-3
EXPAND, 3-11
LIBRARY, 3-11
output listing, 3-11
object part, 3-8
source part, 3-5
REQUIRE, 3-11
TRACE, 3-11
EXEC command, 1-22
Executing a program, I-I, 2-1
/EXIT, 1-9
EXPAND, 1-15, 2-13
examples, 3-11
Expressions
tree representations, 8-2
/EXTENDED, 1-19
Extended addressing
differences, 6-13
examples, 6-13
/EXTENDED:SECTION-INDEPENDENT,
1-19
Extension
TOPS-10 defaults, 2-4
Extension attribute, 7-12
Factorial routines, 3-10
FIELD, 1-10
Field selectors, 7-16, 7-30
Figures
Error Messages in Source
Listing, 3-25
Output Listing Example Showing
Library /Require File, 3-11
Output Listing with
Cross-Reference, 3-21
File specifications, 2-3
File type
TOPS-20 defaults, 1-5
File-spec separation, 1-2
FINAL, 8-7
Find first bit, 5-11
FLOW, 8-2
Flow analysis, 8-2
/FORMAT, 1-15
Format
error messages, 3-23
listing header, 3-4
source listing preface string,
3-6
/FORMAT switch options, 1-14
Formatting rules, summary, B-1
Functions
machine-specific, 5-1
General switches, 1-8, 2-7
Global switches, 1-2
/GO, 4-1
Hash mark, 4-4
/HEADER, 1-15, 2-13
Header format, 3-4
Heuristic phase of compiler, 8-6

Index-2

INDEX
Implementation limits, D-l
Indirect files, 1-22
INITIAL, 1-10
Initial-attribute, 7-20
Initialization, 7-20
Input-spec, 1-3, 2-3
Input/output support facility,
9-1
Isolation, 7-2
/KAIO,
/KIIO,
/KLIO,
/KSIO,

1-19,
1-19,
1-19,
1-19,

2-17
2-17
2-17
2-17

Language switch, 7-6
Lexical analysis, 8-1
Lexical error detection, 3-5
Lexical function
%BLISS, 7-5
%SWITCHES, 1-20
lexical function
%SWITCHES, 2-18
LEXSYN, 8-1
Libraries, 9-1
generation of, 9-1
precompiled, 9-10
MONSYM, 9-13
TENDEF, 9-11
UUOSYM, 9-13
usage, 6-1
/LIBRARY, 1-7, 1-15, 2-6
LIBRARY, 2-13
example listing, 3-11
vs. REQUIRE, 6-1
Library
usage differences, 6-1
Library switches, 2-6
LINK command, 4-2
Linkage, G-l
Linking, 4-1
extended addressing, 4-2
mixed modules, G-l
TOPS-10/TOPS-20 differences,
4-3
/LIST, 1-7, 2-13
Listing header, 3-4
Listing switches, 1-14, 2-12
Literal, 7-3
numeric, 7-4
predeclared, 7-4
string, 7-4
user-defined, 7-4
value definition, 7-4
Logical shift, 5-13
Machine specific functions, 7-2
treatment during FLOW analysis,
8-3
Machine-specific functions
ASH, 5-5
byte manipulation, 5-11
increment a byte pointer,
5-11

Machine-specific functions
(Cont. )
compilation, 5-1
conventions, 5-1
INCP, 5-11
logical
arithmetic shift, 5-5
machine code insertion, 5-1
optimization, 5-1
machine-specific functions
ADDD, 5-3
ADDF, 5-4
ADDG, 5-4
arithmetic, 5-3
add double operands, 5-3
add float operands, 5-4
add float-G operands, 5-4
divide double operands, 5-10
divide float operands, 5-10
divide float-G operands, 5-10
mUltiply double operands,
5-14
multiply float operands, 5-14
multiply float-G operands,
5-14
subtract double operands,
5-16
subtract float operands, 5-16
subtract float-G operands,
5-17
arithmetic comparison, 5-3
compare double operands, 5-5
compare float operands, 5-5
compare float-G operands, 5-6
arithmetic conversion, 5-3
convert double to float, 5-6
convert double to integer,
5-7
convert float to double, 5-7
convert float to f1oat-G, 5-7
convert f1oat-G to floating,
5-8
convert floating to integer,
5-8
convert integer to float, 5-9
convert integer to float-G,
5-9
arithmetic functions
convert f1oat-G to integer,
5-8
convert integer to double,
5-9
byte manipulation
build a byte pointer, 5-15
copy a byte, 5-6
fetch a byte, 5-16
store a byte, 5-15
CMPD, 5-5
CMPF, 5-5
CMPG, 5-6
COPY, 5-6
CVTDF, 5-6
CVTDI, 5-7
CVTFD, 5-7

Index-3

INDEX
machine-specific functions
(Cont. )
CVTFG, 5-7
CVTFI, 5-8
CVTGF, 5-8
CVTGI, 5-8
CVTID, 5-9
CVTIF, 5-9
CVTIG, 5-9
DIVD, 5-10
DIVF, 5-10
DIVG, 5-10
FIRSTONE, 5-11
JSYS, 5-11
logical, 5-3
find first bit, 5-11
logical shift, 5-13
rotate a value, 5-15
LSH, 5-13
machine code insertion
emit on instruction, 5-13
MACHOP, 5-13
MACHSKIP, 5-13
MULD, 5-14
MULF, 5-14
MULG, 5-14
POINT, 5-15
REPLACE, 5-15
ROT, 5-15
SCAN, 5-16
SUBD, 5-16
SUBF, 5-16
SUBG, 5-17
system interface, 5-3
invoke TOPS-lO system service,
5-17
invoke TOPS-20 system service,
5-11
table of, 5-2
UUO, 5-17
MACRO expansion, 3-11
MACRO tracing, 3-11
Macros, 7-2, 7-5
advanced use, 6-7
enumeration types, 6-9
using machine dependencies, 6-8
Mark points, 8-5
/MASTER CROSS REFERENCE, 1-18
/MAXCOR-; 4-3 Mixed module linkage, G-l
Modularization, 7-3
Module, 7-2
mixed module linkage, G-l
switches, 7-6, G-l
PROLOG, G-1
STACK, G-1
Module template, C-l
MODULE.BLI, C-l
MONSYl-1 library, 9-13
Multifile compilation, 1-2
MULTIPLE, 1-18, 2-17
Multiply double operands, 5-14
Multiply float operands, 5-14
Multiply float-G operands, 5-14

Name binding, 8-6
Name, defined value, 7-15
/NOLOCAL, 4-3
Nontransportable attributes, 7-12
NSAVE command, 4-1
Number-of-lines, 1-14, 2-13
Numeric literals, 7-4
/OBJECT, 1-7
OBJECT, 2-15
Object listing
default, 3-8
default switch settings, 3-8
fields, 3-8
Object part of output, 3-7
Object-file, 4-2
Offset addressing, 7-19
Operating procedures
debugging, 4-3
linking, 4-1
running, 4-3
Optimization
levels, 1-12
missing code, 6-5
of code stream, 8-7
optimize-level, 2-11
swi tch, 1-12
switches, 8-1
Optimization switches, 1-12, 2-10
/OPTIMIZE, 1-13
effect of, 8-6
effect of /OPTLEVEL value, 8-7
effect of /SAFE switch, 8-4
OPTIMIZE, 1-10
Optimize-value, 2-11
Option file, 2-20
Options
/FORMAT switch, 1-14
/LIST switch, 2-13
/OPTLEVEL, 1-13, 2-12
effect of, 8-7
OTS, H-1
OTS LINKAGE, H-1
OUTPUT, 8-8
Output
file production, 8-8
specifications, 2-5
terminal, 3-2
Output listing
complete listing, F-l
default source listing, 3-11
examples, 3-11
object part, 3-8
source part, 3-5
fields, 3-7
listing header format, 3-4
object part, 3-7
preface, 3-5
preface format (Table), 3-6
segments, 3-3
source part, 3-5
source part options, 3-10
with macro expansions, 3-11,
3-14

Index-4

INDEX
Output listing (Cont.)
with macro tracing, 3-11
with REQUIRE and LIBRARY info,
3-11, 3-13
Output switches, 1-6
Packed data initalization, 7-23
/PAGSIZ:lines, 1-15, 2-13
Parameterization, 7-1, 7-24
Parentheses, 6-4
PLIT, 7-17
Pointer in error message, 3-24
Predeclared literals, 7-4
Preface string format, 3-6
Programming considerations, 6-1
centralized common declarations,
6-1
compilation costs, 6-1
~~ficiency of library files,
6-1
symbol tables, 6-1
Programming tools, 9-1
PROLOG module switch, G-l
Question mark in indirect files,
1-22
/QUICK, 1-13, 2-12
Quoted strings
used as character strings, 7-17
used as numeric values, 7-16
REDECLARE, 1-10
Reference switches, 1-17
References switches, 2-15
Relational operators, 7-15
REQUIRE, 1-15, 2-13
example listing, 3-11
vs. LIBRARY, 6-1
Require
usage differences, 6-1
REQUIRE declaration
files invoked by, 6-2
REQUIRE files, 7-2, 7-8
search rules, 7-9
Reserved names, 7-8
Rotate a value, 5-15
Routines, 7-9
Running a program, 4-3
/SAFE, 1-13, 2-12
effect of, 8-4
/SAVE, 4-3
SAVE command, 4-1
Saving a program, 1-1, 2-1
Scalar PLIT items, 7-18
Segments of output listing, 3-3
Semicolon
used as expression terminator,
6-3
used as mark point, 8-5
Sign extension rules
consistent use of, 6-4
/EXTENDED:SECTION-INDEPENDENT,
Simplicity, 7-3

SIX12
commands, 4-4
&ABREAK, 4-5
&BREAK, 4-5
&CALLS, 4-4
&DABREAK, 4-5
&DBREAK, 4-5
&DDT, 4-5
&GO, 4-5
&SIXRET, 4-5
debugger, 4-3
radix, 4-4
SOURCE, 1-16, 2-14
Source
code errors corrected, 3-10
part of output listing, 3-5
Special features
TOPS-10
indirect files, 2-20
option file, 2-20
TOPS-20
EXEC command, 1-22
indirect files, 1-22
STACK module switch, G-l
/STATISTICS, 1-11, 2-10
String literal in PLITs, 7-18
String literals, 7-4
Strings (character sequences),
7-16
Structures, 7-27
Subtract double operands, 5-16
Subtract float operands, 5-16
Subtract float-G operands, 5-17
Summaries
compilation, 3-22
formatting rules, B-1
machine-specific functions, 5-2
switch effects, 8-8
Switch vs. module switch names,
2-19
switch vs. module switch names,
1-21
TOPS-10 command syntax, A-3
TOPS-20 command syntax, A-I
Switch
command-line, 2-6
LANGUAGE, 7-6
module, 7-6
types of, 2-6
Switches
check
/CHECK, 1-10, 2-9
FIELD, 1-10, 2-9
INITIAL, 1-10, 2-9
OPTIMIZE, 1-10, 2-9
REDECLARE, 1-10, 2-9
command-line, 1-3, 1-5
/DEBUG, 4-3
defaults, 1-20, 2-18
environment
/EXTENDED, 1-19

Index-5

INDEX
Switches
environment (Cont.)
/KAI0, 1-19, 2-18
/KII0, 1-19, 2-18
/KLI0, 1-19, 2-18
/KSI0, 1-19, 2-18
/ TO PS 1
1-1 9 , 2 -18
/TOPS20, 1-19, 2-18
/ERRS, 3-2
for output listing, 3-7
/FORMAT, 1-22
general
/CODE, 1-9, 2-8
/DEBUG, 1-9, 2-8
/ERRLIM, 2-8
/ERROR-LIMIT, 1-9
/EXIT, 1-9
/VARIANT, 1-9, 2-8
global settings, 1-2
/GO, 4-1
/LIBRARY, 2-6
/LISTING, 1-22
listing
ASSEMBLY, 1-16, 2-15
BINARY, 1-16, 2-15
COMMENTARY, 1-16, 2-15
EXPAND, 1-15, 2-13
/FORMAT, 1-15
/HEADER, 1-15, 2-13
/LIBRARY, 1-15
LIBRARY, 2-13
/LIST, 2-13
OBJECT, 2-15
/PAGSIZ:lines, 1-15, 2-13
REQUIRE, 1-15, 2-13
SOURCE, 1-16, 2-14
SYMBOLIC, 1-16, 2-15
TRACE, 1-15, 2-14
/UNAMES, 1-15, 2-13
/MAXCOR, 4-3
module
ENVIRONMENT, G-l
LINKAGE, G-l
PROLOG, G-l
STACK, G-l
module-head
ENVIRONMENT, 1-20
/NOASSEMBLY, 3-8
/NOCOMMENTARY, 3-8
/NOLOCAL, 4-3
optimize
/OPTIMIZE, 1-13
/OPTLEVEL, 1-13, 2-12
/QUICK, 1-13, 2-12
/SAFE, 1-13, 2-12
/ZIP, 1-13, 2-12
/OPTIMIZE, effect of, 8-6
/OPTLEVEL, effect of, 8-7
OTS, H-l
OTS LINKAGE, H-l
output
/LIBRARY, 1-7
/LIST, 1-7
/MASTER-CROSS-REFERENCE, 1-7

°,

Switches
output (Cont.)
/OBJECT, 1-7
/p, G-l
positive and negative, 1-22,
2-20
reference
/CROSS REFERENCE, 1-18
/MASTER CROSS REFERENCE, 1-18
MULTIPLE, 1-18, 2-17
/SAFE, effect of, 8-4
/STATISTICS, 2-20 to 2-21, 3-2
terminal
/ERRS, 1-11, 2-10
/STATISTICS, 1-11, 2-10
/TEST, 4-3
TOPS-10 defaults, A-5
TOPS-20 defaults, A-2
type of, 1-3
/UNAMES, 6-6
vs. module switch names, 1-21,
2-19
/ZIP, effect of, 8-7
SWITCHES declaration, 6-2, 8-1
%SWITCHES lexical function, 2-18
testing during compilation,
1-20
Symbol table
entries for declarations, 8-2
SYMBOLIC, 1-16, 2-15
Symbols
content, 6-6
greater than 15 characters, 6-6
length, 6-6
same name in different contexts,
6-6
uniqueness, 6-6
Syntactic analysis, 8-1
System interfaces, 9-1, 9-10
implementation limits, D-l
TOPS-10 example, 9-14
TOPS-20 example, 9-17
Table
BLISS-10 language features, 9-7
cross-reference listing
symbol types, 3-16
machine-specific functions, 5-2
source listing preface string
format, 3-6
switch vs. module switch names
TOPS-10, 2-19
TOPS-20, 1-21
TENDEF library, 9-11
Terminal output, 3-2
Terminal switches, 1-11, 2-9
Terminating LINK, 4-1
/TEST, 4-3
TNBIND, 8-6
Tools, 9-1
BCREF, 9-4
CVTI0, 9-6
TUTIO, 9-10
XPORT, 9-1

Index-6

INDEX
TOPS-20 special features, 1-22
/TOPSIO, 1-19, 2-17
/TOPS20, 1-19, 2-17
TRACE, 1-15, 2-14
examples, 3-11
Transportability
key to, 7-9
techniques, 7-10
tools, 7-3
Transportability guidelines, 7-1
address calculation, 7-14
allocation attribute, 7-12
attributes, 7-12
character sequences, 7-17
checking, 7-6
control expressions, 7-15
declarations, 7-13
field selectors, 7-30
isolation, 7-2
literals, 7-3
modularization, 7-3
module switches, 7-6
relational operators, 7-15
REQUIRE and LIBRARY files, 7-8
reserved names, 7-8
simplicity, 7-3
string literals, 7-17
string literals in PLITs, 7-20
strings, 7-17

Transportable
control expressions, 7-15
declarations, 7-11
expressions, 7-14
structures, 7-14, 7-27
Transportable tools, 9-1
TUTIO, 9-10
Tutorial terminal I/O package,
9-10
/UNAMES, 1-15, 2-13
UPLIT, 7-18
%UPVAL, 7-4, 7-14, 7-19
utility programs
BCREF, 9-4
CVTIO, 9-6
TUTIO, 9-10
UUOSYM library, 9-13
Values, changing of, 8-3
/VARIANT, 1-9, 2-8
Weak-attribute, 7-12
XPORT, 9-1
/ZIP, 1-13, 2-12
effect of, 8-7

Index-7

BLISS-:36
User's Guide
AA-H712D-TK
READER'S COMMENTS
NOTE: This form is for document comments only. DIGITAL will use comments submitted on this form at the
company's discretion. If you require a written reply and are eligible to receive one under Software
Performance Report (SPR) service, submit your comments on an SPR form.

Did you find this manual understandable, usable, and well organized? Please make suggestions for improvement.

Did you find errors in this manual? If so, specify the error and the page number.

Please indicate the type of user/reader that you most nearly represent.
[] Assembly language programmer
Higher-level language programmer
IJ Occasional programmer (experienced)
[] User with little programming experience
IJ Student programmer
rJ Other (please specify)
[J

Name _________________________________________________ Date _______________________________
Organization
Street
City ____________________________________

State _ _ _ _ _ _ Zip Code _ _ _ _ __
or Country

-I

Do Not Tear - Fold Here and Tape

No Postage
Necessary
if Mai led in the
United States

111111

BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO.33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

BSSG PUBLICATIONS ZK1-3/J35
DIGITAL EQUIPMENT CORPORATION
110 SPIT BROOK ROAD
NASHUA, NEW HAMPSHIRE 03061

Do Not Tear - Fold Here