iSyntax10.Scn.FntGWParcElemsAlloc Syntax24m.Scn.FntSyntax14.Scn.Fnt GW Syntax14b.Scn.FntSyntax12b.Scn.FntGW Syntax12.Scn.FntTGW GW  Syntax14i.Scn.Fnt HJ5AE?        5    R    )   0   GW  + f   GW R@#B+TableElemsAllocrSyntax10.Scn.FntGWParcElemsAlloc .сSyntax14.Scn.Fntdz/columns "-ll"/table key code (heX) meaning Front (L5) 0A4X mark viewer F1 .. F3 0F1X .. 0F3X toggle screen mode F4 .. F6 1X, 0FX, 15X, german umlauts F7 .. F9 81X, 8FX, 95X german umlauts up C1X cursor up down C2X cursor down right C3X cursor right left C4X cursor left Ctrl-C 03X interrupt (on most keyboards) Ctrl-L 0CX redraw all viewers Break 0ACX break character   *  @     C  =1(k     $U\ d?pp;Syntax10.Scn.FntSyntax14.Scn.FntTh/columns "-l"/table data type internal representation SHORTINT 1 Byte signed CHAR, BYTE 1 Byte unsigned BOOLEAN 1 Byte unsigned (0 = FALSE, 1 = TRUE) INTEGER 2 Bytes signed LONGINT 4 Bytes signed SET 4 Bytes ({0} = 1) PointerType 4 Bytes (NIL = 0) ProcedureType 4 Bytes (NIL = 0 REAL 4 Bytes IEEE-format (754-1985) LONGREAL 8 Bytes IEEE-format (754-1985) k # ]U#vSyntax14.Scn.FntSyntax10.Scn.FntGWParcElemsAlloc ./columns "-lll"/table Name Argument types Result type Meaning ADR(v) v: any type LONGINT address of variable v BIT(a, n) a: LONGINT BOOLEAN n IN Mem[a] n: integer type (if a MOD 4 = 0 & 0 <= n <= 31) CC(n) n: integer constant BOOLEAN icc n (if n < 16) fcc n MOD 16 (if n >= 16) LSH(x, n) x, n: integer type LONGINT logical shift ROT(x, n) x: integer type, type of x rotation BYTE, CHAR VAL(T, x) T, x: any type T x interpreted as of type T @U ]U.lSyntax10.Scn.FntParcElemsAlloc Syntax14.Scn.Fnt=>/columns "-lll"/table Name Argument types Meaning GET(a, v) a: LONGINT v := Mem[a] v: any basic type GETREG(n, v) n: integer constant v := ireg n (if n < 32) v: any basic type v := freg n MOD 32 (if n >= 32) PUT(a, x) a: LONGINT Mem[a] := x x: any basic type PUTREG(n, x) n: integer constant ireg n := x (if n < 32) x: any basic type freg n MOD 32 := x (if n >= 32) MOVE(a0, a1, n) a0,a1: integer type move n bytes from address a0 to a1 n: integer type, n> 0 NEW(v, n) v: any pointer type allocate storage block of n bytes and n: integer type assign its address to v |h 1!^H":t94  SPARC-Oberon User Guide J. Templ Abstract  SPARC-Oberon is an implementation of Oberon for SPARC processors. It covers both the programming language Oberon and the Oberon System closely resembling the original implementation on Ceres. Hence, this report describes only the differences between SPARC-Oberon and the Ceres implementation (Ceres-Oberon) from a user's point of view. Contents  1. Introduction 2. Installation 3. Differences to Ceres-Oberon 4. Data Representation and Alignment 5. Low-level Facilities 6. External procedures References 1. Introduction The programming language Oberon [1, 2] evolved from a project with the goal of developing a portable operating system (also named Oberon) for personal workstations [3, 4, 5]. The original Oberon implementation on Ceres workstations proved to be useful for doing many kinds of personal computing including program development, document preparation, and teaching programming. To make Oberon available on other machines, there are some projects in work for MC68020, MIPS, RS/6000, and Intel 80386 processors. This report focuses on the version for Sun-SPARC, which is (due to register windows) especially interesting for compiler writers as described in the companion report "SPARC-Oberon Implementation". SPARC-Oberon has been designed to be as (Ceres-)Oberon-like as possible. Compatibility with existing software running under SunOS, the Unix implementation for Sun computers, was definitely not the goal. Oberon should be considered as an alternative to Sun-View or X-Windows and it is up to the user to choose his/her favorite environment. SPARC-Oberon runs as a single Unix-process and requires a bitmapped display, a three-button mouse and a keyboard. It makes no sense to run Oberon via a serial terminal or via remote login. However, in principle it is possible to provide for special Oberon subsets running on terminals just to use the language, or to provide for an Oberon version based on a client server model. As the Oberon system relies on dynamic loading of modules (without pre-linking), which was not supported by SunOS, it has been necessary to use special object files and a special loader. This allows for arbitrary extensibility of Oberon programs and for low overhead in the edit-compile-execute cycle, typically requiring only two mouse clicks and almost no time. 2. Installation SPARC-Oberon may be installed on all Sun computers featuring the SPARC architecture. To install SPARC-Oberon you just have to copy all files of the distribution medium into a directory. This directory is intended to be the public Oberon library. The prefered name for it is /usr/local/Oberon and it is a good idea to make this library read only. File naming conventions: Files ending with ".Z" are compressed and may be uncompressed by the command uncompress. Files ending with ".tar" are tape archives that may be handled by the tar command. The Oberon environment may be entered by executing the command oberon. When working under SunView or OpenWindows it has to be prefixed by the command overview. Note that overview cannot be used via remote login and requires the file /etc/utmp to be user writable. The calling syntax of the oberon command is: [overview] oberon [-h heapSize] [-f defaultFont] [-x Mod Proc] options: -h heapSize set heap size to specified number of bytes. If not specified, 2 MB are used for the Oberon heap. -f defaultFont set default font to specified font name. If not specified, Syntax10.Scn.Fnt is taken as default font. -x Mod Proc execute command Mod.Proc. If not specified, Oberon.Loop is executed. Note, there is also a slightly modified version of SPARC-Oberon that runs within an X-window. See file readme for installation hints. New files and files used internally by Oberon are always allocated in the current directory. Internal files are named .tmp.pid.nr, where pid is a process id and nr is a unique number within this process. Make sure, that you have read and write permission in the current directory. The search path for existing files is specified by the environment variable OBERON. The default setting for OBERON is .:/usr/local/Oberon. This means, if the environment variable OBERON doesn't exist, files are first searched in the current directory and second in the public Oberon library. Following Unix conventions, colons are used as path name separators. Environment variables may be set under the C-shell by the command setenv (e.g. setenv OBERON .:MyLib:/usr/local/Oberon). The Oberon command System.Suspend exits the Oberon environment but preserves its state, whereas System.Quit kills the Oberon process. Ctrl-C (keyboard interrupt) may be used to interrupt an Oberon command, display a trap viewer, and resume execution in the central Oberon loop. Ctrl-\ (quit) may be used to kill the Oberon process, if it is out of control. If for any reasons the keyboard does not respond as usual after leaving oberon, the command "stty sane " should solve the problem. 3. Differences to Ceres-Oberon SPARC-Oberon differs in some details from Ceres-Oberon. These differences are due to the underlying hard- and software. However, Oberon programs that do not use low-level features are fully portable. There are no differences in the implemented language. Module System provides additional commands for the integration of Oberon into Unix. Module Display handles screen maps and patterns differently. Module Unix provides a low level interface to the underlying operating system. Module Input emulates some keys that are not available on Sun keyboards. Module Files provides an additional procedure to change the working directory. Module Oberon returns the time in milliseconds instead of 1/300 seconds. Module Printer generates PostScript output. Module Miscellaneous does not provide commands specific to Ceres-Oberon. Module V24 and the Net, and ColorSystem tool packages are not implemented. Module Display1 provides additional display operations. Module Backup provides an additional Eject command. System Suspend Stop the Oberon process and preserve its state. When working under SunView, Oberon may be reentered by clicking at the oberon icon, otherwise by executing a foreground command (fg). Quit Kill the Oberon process and remove temporary files. Execute command | ^ Execute an arbitrary (non-interactive) bourne-shell command and display its output in a text viewer. The command is terminated by "end of line". If System.Execute is followed by a "^", the most recent text selection is executed, where multiple lines are separated by blank characters and the command is terminated by "end of selection". ChangeDirectory newdir | ^ Change the working directory to newdir. Display NewPattern (image: ARRAY OF SET; W, H: INTEGER): Pattern; Return a descriptor to a new pattern initialized with image. Each line of the image is expected to be stored as a sequence of sets. The bottom left bit is defined by bit 0 of image[1]. image[0] is reserved for internal usage. Map (X, Y: INTEGER): LONGINT; Return the address of screen map at X, Y. Procedures for handling the hardware cursor on color monitors of a Ceres computer are not supported. Unix Module Unix provides an Oberon interface for all SunOS system calls and defines all data types and error numbers used in these calls. The procedures Unix.Done() and Unix.Result() may be used to check for success and to examine the error number (immediately after system calls). Note, that the semantics of SunOS system calls is slightly different from the semantics of the corresponding C-lib calls for some system calls. Input The following table shows the code of special keys as generated by module Input:  Files ChangeDirectory (path: ARRAY OF CHAR; VAR res: INTEGER); Change the working directory. A zero result indicates success. Oberon Time (): LONGINT; Return the time since start of the Oberon system in milliseconds. Printer Module Printer generates a (temporary) PostScript file named Oberon.Printfile.ps and sends it to a printer using the Unix command lpr. A header file Oberon.Header.ps is always included at the beginning of Oberon.Printfile.ps. The printer name none specifies that only the file Oberon.Printfile.ps should be generated. The header file may be used to specify the mapping from Oberon to PostScript fonts. Backup Eject ejects the diskette in drive /dev/rfd0. Note that Oberon's Backup utility uses a proprietary directory format in order to allow file exchange between all ETH-Oberon implementations. Module Backup cannot be used for file exchange with Unix or MS-DOS. 4. Data Representation and Alignment The following table shows the internal representation of data types in SPARC-Oberon:  Variable addresses, record field offsets and record sizes are always aligned to a multiple of the type's base. The base of an unstructured type is the type's size, the base of an array is the base of the element type and the base of a record type is the maximum base of its field types. 5. Low-level Facilities Module SYSTEM The module SYSTEM provides some low level operations specific to this particular Oberon implementation. It provides the following functions and procedures. v stands for a variable, a, n and x for expressions, and T for a type. Function procedures:  The function SIZE remained in the language as defined in [1]. SIZE(T) returns the number of bytes reqired for type T. Note, SYSTEM.VAL neither produces any code for conversions nor performs any compile time checks but forces the compiler to interpret the type of an expression differently. Proper procedures:  Types: No representation of values is specified. Instead, certain compatibility rules with other types are given: BYTE: 1. BYTE is compatible with CHAR and SHORTINT. 2. if a formal VAR-parameter is of type ARRAY OF BYTE, then the corresponding actual parameter may be of any type. PTR: 1. variables of type PTR are compatible with any pointer type. 2. VAR-parameter of type PTR contain the static type of the actual parameter upon procedure entry (to allow for runtime type checks). Code procedures Code procedures (marked with a minus) are inlined byte sequences used to implement the Unix system call interface for Oberon as shown in the following example. As usual, the asterisk indicates that the code procedure is exported. PROCEDURE -ReadBlk* (fd: LONGINT; VAR blk: ARRAY OF BYTE): LONGINT 82H, 0, 20H, 3, (* %g1 := nr of syscall *) 91H, 0D0H, 20H, 0; (* trap 0 *) 6. External Procedures SPARC-Oberon supports calling library functions that are implemented in a foreign language such as C by employing the runtime linking facilities of SunOS. This requires that such functions are exported from a shared object library (a library with .so.* postfix). Linking of shared object libraries is done via dlopen (3X) and dlsym(3X) calls. Module Kernel exports these two procedures in a way that is convenient for Oberon programmers. Kernel.dlopen also mimics the library search strategy of ld.so (1), i.e. it is not required to pass the full path name of the library (see example below). A library is first searched in all directories specified by the LD_LIBRARY_PATH environment variable. If not found, libraries are also searched in the /usr/lib and /usr/local/lib directories. For the sake of simplicity, the implemented lookup strategy deviates from ld.so by simply requiring the library name to be a prefix of the actual directory entry. The effect is that missing postfixes such as the minor version number are ignored. This might cause troubles, if multiple library versions are present in a system. Example: VAR OpenDisplay: PROCEDURE (nameAdr: LONGINT): LONGINT; libX, display: LONGINT; BEGIN libX := Kernel.dlopen("libX11.so.4", 1); IF libX # 0 THEN Kernel.dlsym(libX, "XOpenDisplay", SYSTEM.VAL(LONGINT, OpenDisplay)); display := OpenDisplay(SYSTEM.ADR("unix:0")); ... ELSE Out.String("libX11.so.4: object could not be mapped"); Out.Ln END Parameter passing is compatible with C-calling conventions except for * passing of REAL and LONGREAL value parameters in SPARC-Oberon is done in floating point registers. C passes REAL and LONGREAL parameters as one or two long integers. * structured value parameters are always copied by the callee. * For record variable parameters an additional parameter describing the dynamic type of the record is passed. * for dynamic array parameters an additional len parameter is passed for each dimension. * structured function results are not supported by Oberon. * functions with variable number of parameters are not supported by Oberon. Note that Oberon pointers should not be assigned to blocks allocated outside the Oberon heap because that would confuse the garbage collector. Use LONGINT to refer to such blocks. References 1. N. Wirth. The programming language Oberon. Software-Practice and Experience, 18 , 7 (July 1988) 2. N. Wirth. From Modula to Oberon & The Programming Language Oberon Report 143, ETH Zurich, 1990. 3. N. Wirth, J. Gutknecht. The Oberon System. Software - Practice and Experience, 19, 9 (Sept. 1989) 4. J. Gutknecht. The Oberon Guide Report 138, ETH Zurich, 1990. 5. M. Reiser The Oberon System, User Guide and Programmer's Manual Addison-Wesley, 1991 File: SparcOberon.Text / J. Templ / 21-Nov-91 / 7-Apr-93