NAME

pc − Pascal compiler

SYNOPSIS

pc [ −c ] [ −g ] [ −o output ] [ −O ] [ −b ] [ −C ] [ −fsky ] [ −H ] [ −i name ... ] [ −l ]

[ −lpfc ] [ −L ] [ −P ] [ −s ] [ −S ] [ −z ] filename.p ...

DESCRIPTION

Pc is the Sun Pascal compiler.  If given an argument file ending with .p, pc compiles the file and leaves the result in an executable file called a.out by default. 

A program may be separated into more than one .p file.  Pc will compile a number of .p files into object files (with the extension .o in place of .p). Object files may then be loaded into an executable a.out file.  Exactly one object file must supply a program statement to successfully create an executable a.out file.  The rest of the files must consist only of declarations which logically nest within the program.  References to objects shared between separately compiled files are allowed if the objects are declared in included header files, whose names must end with .h.  Header files may only be included at the outermost level, and thus declare only globally available objects.  To allow external functions and procedures to be declared, an external directive has been added, whose use is similar to the forward directive but restricted to appear only in .h files.  Function and procedure bodies may not appear in .h files.  A binding phase of the compiler checks that declarations are used consistently, to enforce the type checking rules of Pascal. 

Object files created by other language processors may be loaded together with object files created by pc. The functions and procedures they define must have been declared in .h files included by all the .p files which call those routines. 

Pascal’s calling conventions are the same as in C, with var parameters passed by address and other parameters passed by value. 

Both pc and pi(1) support ISO Level 1 Standard Pascal, including conformant array parameters.  Deviations from the ISO Standard are noted under BUGS below. 

See the Pascal User’s Manual for details. 

OPTIONS

See ld(1) for load-time options.

−c Suppress loading and produce .o file(s) from source file(s). 

−g Produce additional symbol table information for the symbolic debugger dbx(1).

−o  name
Name the final output file name instead of a.out. 

−O Optimize the object code. 

−b Buffer the file output in units of disk blocks, rather than lines. 

−C Compile code to perform subscript and subrange checks, verify assert statements, and initialize all variables to zero as in pi. Note that pointers are not checked.  This option differs significantly from the -C option of the cc compiler. 

−fsky Generate code which assumes the presence of a SKY floating-point processor board.  Programs compiled with this option can only be run in systems that have a SKY board installed.  Programs compiled without the −fsky option will use the SKY board from library routines, but won’t run as fast as they would if the −fsky option were used.  If any part of a program is compiled using the −fsky option, you must also use this option when linking with the pc command, since different startup routines are used to initialize the SKY board. 

−H Compile code to perform range checks on pointers into the heap. 

−i name
Produce a listing for the specified procedures, functions and include files. 

−l Make a program listing during translation. 

−lpfc Load common startup code for programs containing mixed Pascal and FORTRAN object files.  Such programs should also be loaded with the FORTRAN libraries (see files below). 

−L Map upper case letters in keywords and identifiers to lower case. 

−P Use partial evaluation semantics for the boolean operators and and or.  For these operators only, left-to-right evaluation is guaranteed, and the second operand is evaluated only if necessary to determine the result. 

−s Accept standard Pascal only; nonstandard constructs cause warning diagnostics. 

−S Compile the named program, and leave the assembly language output on the corresponding file suffixed ‘.s’.  No ‘.o’ is created. 

−z Allow execution profiling with pxp by generating statement counters, and arranging for the creation of the profile data file pmon.out when the resulting object is executed. 

Other arguments are taken to be loader option arguments or libraries of pc compatible routines.  Certain flags can also be controlled in comments within the program, as described in the Pascal User’s Manual in the Sun Pascal Manual. 

FILES

file.pPascal source files
/lib/cppmacro preprocessor
/usr/lib/pc0compiler
/lib/f1code generator
/usr/lib/pc2inline expander of library calls
/lib/c2peephole optimizer
/usr/lib/pc3separate compilation consistency checker
/usr/lib/pc3.2stringstext of the error messages
/usr/lib/how_pcbasic usage explanation
/usr/lib/libpc.aintrinsic functions and I/O library
/usr/lib/libpfc.astartup code for combined Pascal and FORTRAN programs
/usr/lib/libF77.aFORTRAN intrinsics library
/usr/lib/libI77.aFORTRAN I/O library
/usr/lib/libU77.aFORTRAN<=>Unix interface library
/usr/lib/libm.amath library
/lib/libc.astandard library, see intro(3)

SEE ALSO

The Pascal User’s Manual in the Sun Pascal Manual. 
pi(1), pxp(1), pxref(1)

DIAGNOSTICS

For a basic explanation do

tutorial% pc

In the diagnostic output of the translator, lines containing syntax errors are listed with a flag indicating the point of error.  Diagnostic messages indicate the action which the recovery mechanism took in order to be able to continue parsing.  Some diagnostics indicate only that the input is ‘malformed.’ This occurs if the recovery can find no simple correction to make the input syntactically valid. 

Semantic error diagnostics indicate a line in the source text near the point of error.  Some errors evoke more than one diagnostic to help pinpoint the error; the follow-up messages begin with an ellipsis ‘...’. 

The first character of each error message indicates its class:

EFatal error; no code will be generated. 

eNonfatal error. 

wWarning − a potential problem. 

sNonstandard Pascal construct warning. 

If a severe error occurs which inhibits further processing, the translator will give a diagnostic and then ‘QUIT’. 

Names whose definitions conflict with library definitions draw a warning.  The library definition will be replaced by the one supplied in the Pascal program.  Note that this can have unpleasant sideeffects. 

BUGS

The keyword packed is recognized but has no effect.  The ISO standard requires packed and unpacked structures to be distinguished for portability reasons. 

Binary set operators are required to have operands with identical types; the ISO standard allows different types, as long as the underlying base types are compatible. 

The −z flag doesn’t work for separately compiled files. 

Because the −s option is usurped by the compiler, it is not possible to pass the strip option to the loader.  Thus programs which are to be stripped, must be run through strip(1) after they are compiled.

Sun Release 2.0  —  Last change: 1 February 1985