ModulaTor logo, 7.8KB

The ModulaTor

Oberon-2 and Modula-2 Technical Publication

Ubaye's First Independent Modula-2 & Oberon-2 Journal! Nr. 73, Nov-1997


64 Bit Oberon

Günter Dotzel and Hartmut Goebel

Abstract

To exploit the 64 bit address space, we migrated ModulaWare's 32 bit Oberon System [DG 96] to OpenVMS Alpha V7.1 [AXP] using very large memory [VLM]. We describe the required language extensions of the Oberon-2 programming language in order to support 64 bit pointers and 64 bit integers. The goal was to keep the number of languages extensions minimal and to disallow any language changes which would break existing code developed for the 32 bit Oberon System. We also summarize the modifications required to get the Oberon System running in the 64 bit address space.

Keywords: Oberon, compiler, Alpha, OpenVMS, 64 bit addressing.

Introduction

The Oberon System [Wir92] is an object-oriented programming framework written in Oberon-2 [M~os92]. The Oberon System is available for all popular 32 bit processors and 32 bit operating systems [DS 96]. Although the Oberon-2 language report does not contain explicit assumptions about the number of bits in the pervasive integer types, the low-level modules of the Oberon System contain many 32 bit dependencies.

In Oberon-2 there are three integer types, namely SHORTINT, INTEGER, and LONGINT. Most low-level modules developed on 32 bit computers assume that the size of the integer types is 1, 2, and 4 bytes respectively and that the type size of pointers is equal to 4 bytes. Changing the type size of LONGINT to 8 bytes leaves a gap in the integer type hierarchy. So we extended module SYSTEM by four integer data types, two address data types and two function procedures. We added one new pervasive set type and made only two syntax extension to support 64 bit hex and set literals.

Initially we wanted to keep a 32 bit version of the Alpha Oberon System. After the 64 bit port was completed, we found out that by doubling the size of integers, pointers and procedure variables, the memory requirement of the Oberon System increased only by about 30%. So we decided to support only the 64 bit version of the Alpha Oberon System and we describe only the 64 bit Alpha Oberon-2 compiler here. We give no explications for the language extension made nor implementation details in this article; they are described in [DG 97].

0. Data Types

The Oberon-2 integer type hierarchy is SHORTINT <= INTEGER <= LONGINT.

Module SYSTEM got four integer types: SIGNED_8, SIGNED_16, SIGNED_32, and SIGNED_64, with SIGNED_64 being synonym with LONGINT.

Module SYSTEM got two additional address types: ADDRESS_32 and ADDRESS_64, with ADDRESS_64 being synonym with SYSTEM.PTR.

SIGNED_32 is only needed for (1) system specific data structures, (2) when reading/writing 32 bit binary integers from/to a file, (3) to save memory in large arrays of integers. ADDRESS_32 is only needed in some low-level, operating system specific modules to access layered software which still have 32 bit restrictions.

A new set type LONGSET was added with MAX (LONGSET) = 63.

The type size of pointers and procedure variables is 64 bits.

1. Literals

Integer literals are in the range [-9223372036854775808 .. 9223372036854775807].

The syntax for hex literals was extended from


  integer = digit {digit} | digit {hexDigit} "H".
to

  integer = digit {digit} | digit {hexDigit} ("H" | "S").
The "H" marks a 32 bit signed hexadecimal literal, wheras the "S" marks a 64 bit signed hexadecimal literal. The "S" is taken from the German word "Sedezimal", which stands for a base 16 notation. Examples for hexadecimal number literals:

   80000000H = MIN(SIGNED_32)         80000000S = MAX(SIGNED_32)+1  
  0FFFFFFFFH = -1                    0FFFFFFFFS = 4294967295
                             0FFFFFFFFFFFFFFFFS = -1
   7FFFFFFFH = MAX(SIGNED_32) 7FFFFFFFFFFFFFFFS = MAX (SYSTEM.SIGNED_64)
We allow a set constructor to be optionally be prefixed with an identifier of a set type. If the set type is omitted, the set constructor is of type SET. Set constructors for the pervasive type SET are not compatible with type LONGSET. Examples for the declaration of a negated empty set s and longset l:

  CONST s = -SET{}; t = -LONGSET{};
or

  TYPE SET = LONGSET; CONST s = -SYSTEM.SET_32{}; CONST l = -SET{};
  CONST SameSet1 = -{} = {0..MAX(SET)}; SameSet2 = -{} = {0..MAX(LONGSET)};
The Oberon-2 syntax for Set changes from

  Set =             "{" [Element {"," Element}] "}".
to
  Set = [Qualident] "{" [Element {"," Element}] "}".

2. Standard functions

The standard functions SHORT and LONG convert in the integer type hierarchy SHORTINT <= INTEGER <= LONGINT. In order to get to SIGNED_32, we added two procedures SHORT and LONG in module SYSTEM, for which the type hierarchy is SIGNED_8 <= SIGNED_16 <= SIGNED_32 <= SIGNED_64.

3. 64 Bit Alpha Oberon System

The language extensions described above served our purpose to get a true 64 bit Alpha Oberon System (AOS) with the least possible changes in existing code.

The lower-level modules of the 32 bit Oberon System, such as the garbage collector, exception handler, display and file system interface and run-time debugger needed a lot of modifications, because it was assumed in many places by the original implementors, that the SIZE(LONGINT) = SIZE(PTR) = 4. In the lower-level modules, we had to check every occurence SYSTEM.GET, SYSTEM.PUT, SYSTEM.VAL, SYSTEM.ADR, SYSTEM.VAL, SHORT, LONG, explicit storage allocation, and any occurence of the the value 4 or multiples thereof.

After the bootstrap of the 64 bit AOS, about 400 application modules were recompiled and they all worked.

AOS is the first full 64 bit Oberon development system with a true 64 bit Oberon-2 compiler, 64 bit pointers, 8, 16, 32, and 64 bit integers, S, T, F, D, and G-floating, which provides meta-programming, coroutines, full run-time type information, X11-interface, hypertext-architecture, automatic garbage collector, object finalization, persistent objects, fine grained symbol files and is year 2000 ready.

Oberon-2 applications can now exploit the 64 bit virtual address space, which is four billion times larger than the 32 bit address space. AOS uses the OpenVMS P2-space not only for dynamic data, but also for global variables and program code, leaving no 32 bit address restrictions (except for the main- and coroutine-stack, which is due to an implementation restriction of OpenVMS 7.1). The built-in 64 bit dynamic linker-loader allows program execution directly after compilation. AOS outperforms OpenVMS stand-alone programs, where the OpenVMS linker restricts static data, i.e.: global data-, strings-, linkage-section, as well as program-code, to reside in the 32 bit memory. Stand-alone programs may use VLM only for dynamic memory.

When calling OpenVMS I/O system service routines, the file and record access blocks are still required to reside in 32 bit memory even with VLM. Alpha Oberon automatically allocates these data structures in 32 bit memory, but there is no need to copy I/O-buffers, since the extended record management services (RMS) allow 64 bit values for user buffer address and buffer size. X11 of OpenVMS is still 32 bit only, but Alpha Oberon hides this OpenVMS implementation restrictions of X11 through the module Display.

4. References

[AXP] Richard L. Sites (ed.): Alpha Architecture Reference Manual. Burlington, 1992

[VLM] Michael S. Harvey and Leonard S. Szubowicz: Extending OpenVMS for 64-bit Adressable Virtual Memory.
Thomas R. Benson, Karen L. Noel, and Richard E. Peterson: The OpenVMS Mixed Pointer Size Environment.
Duane A. Smith: Adding 64-bit Pointer Support to a 32-bit Run-time Library.
In Digital Technical Journal (DTJ) at http://www.hpl.hp.com/hpjournal/dtj/vol8num2/intro.htm, DEC, Littleton, U.S.A., Vol. 8, number 2, 1996 (pp. 57-95).

[DG 96] Guenter Dotzel and Hartmut Goebel: Porting the Oberon System to AlphaAXP, ACM SigPlan, Nov-1996.

[DG 97] Günter Dotzel and Hartmut Goebel: 64 bit Alpha Oberon-2 compiler implementation notes.

[DS 96] Günter Dotzel and W. Skulski: Oberon-2, a high performance alternative to C++, in Computers in Physics, Vol 11, No. 1 (Jan-1997), American Institute of Physics. In PostScript ftp://nuchem.nsrl.rochester.edu/pub/Oberon/CiP/NewestDraft.ps.gz

[M~os92] Hanspeter Mössenböck: Object Oriented Programming in Oberon-2, Springer Verlag, 1992.

[Wir92] Niklaus Wirth, Juerg Gutknecht: Project Oberon, The Design of an Operating System and Compiler. Addison-Wesley, 1992

[Ed. note: This article has been submitted for publication in ACM SigPlan Notices. Copyright may be transferred without further notice and this version may no longer be accessible.]


The ModulaTor Forum

Recommended Reading

The Hacker Crackdown, by Bruce Sterling, 1994.
Here is what the author writes in the preface of his book:

If you're a computer cop, a hacker, or an electronic civil liberties activist, you are the target audience for this book. I wrote this book because I wanted to help you, and help other people understand you and your unique, uhm, problems. I wrote this book to aid your activities, and to contribute to the public discussion of important political issues. In giving the text away in this fashion, I am directly contributing to the book's ultimate aim: to help civilize cyberspace.

Information wants to be free. And the information inside this book longs for freedom with a peculiar intensity. I genuinely believe that the natural habitat of this book is inside an electronic network. That may not be the easiest direct method to generate revenue for the book's author, but that doesn't matter; this is where this book belongs by its nature. I've written other books -- plenty of other books -- and I'll write more and I am writing more, but this one is special. I am making The Hacker Crackdown available electronically as widely as I can conveniently manage, and if you like the book, and think it is useful, then I urge you to do the same with it.


IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be taken as working papers and personal rather than organizational statements. Items are printed at the discretion of the Editor based upon his judgement on the interest and relevancy to the readership. Letters, announcements, and other items of professional interest are selected on the same basis. Office of publication: The Editor of The ModulaTor is Guenter Dotzel; he can be reached by tel/fax: [removed due to abuse] or by mailto:[email deleted due to spam]


[ Home | Site_index | Legal | OpenVMS_compiler | Alpha_Oberon_System | ModulaTor | Bibliography | Oberon[-2]_links | Modula-2_links | General interesting book recommendations ]

© (1998-2010) by modulaware.com
Webdesign by www.otolo.com/webworx, 07-Dec-1998. Revised 20-Nov-2010 (broken links to DTJ articles, hacker crackdown, and ps.gz article updated)