Browse Prior Art Database

HEAP DATA, VIRTUAL MEMORY AND APL

IP.com Disclosure Number: IPCOM000127995D
Original Publication Date: 1976-Dec-31
Included in the Prior Art Database: 2005-Sep-14
Document File: 6 page(s) / 31K

Publishing Venue

Software Patent Institute

Related People

George O. Strawn: AUTHOR [+3]

Abstract

A memory management scheme for an API.. system i s described. First, some aspects of the APL 1 anguage that are relevant to memory manage-lent are discussed. Then a set of ruin-time structures is introduced along with a virtual mpmnry based on a segmentatinn strategy. Finally, the effect of high level ontinization upon the memory structures is considered.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 14% of the total text.

Page 1 of 6

THIS DOCUMENT IS AN APPROXIMATE REPRESENTATION OF THE ORIGINAL.

HEAP DATA, VIRTUAL MEMORY AND APL

by George O. Strawn

Technical Report # 76-2 June, 1975

ABSTRACT

A memory management scheme for an API.. system i s described. First, some aspects of the APL 1 anguage that are relevant to memory manage-lent are discussed. Then a set of ruin-time structures is introduced along with a virtual mpmnry based on a segmentatinn strategy. Finally, the effect of high level ontinization upon the memory structures is considered.

INTRODUCTION

Seriantitolly, APL tan he viewed as a certain "worst tale" sublanr,uage of Algol 68. Worst case, that is, in the amount of information that is available at towpile time about the program variables. It its as if every variable in an APL program were, of the mode un i on ( rea 1, char, C) real, char, [A real, ... ), with all bounds i n actual dPClarers 1: 7f 1 ex . Because of this vn r i ah i 1 f ty, a common apnroath to v1PL storae r.iana;c,,nnnt is to I:nen all variahlc~s, local an-l global, 1n an A1i;o1-1 il;e heap. Since APL makes extensive use of a hear, storagP management for an APL systew riay bA of some interest to A lt;ol 63 irnnlo*irnt(-. r >. Of course, t!tere are si fi,ni f it.ant differences as moll as similarities between the two languages and their memory structures. In order to highlight the differences as cell as the similarities, tie begin by giving a discussion -of those general features of APL that have direct inf luencn nn the memory structures. Then we discuss one approach to AIL storage management as influenced by those features and by recent hardware developments. Finally, we discuss extensions to this approach that are suggested by high level optimization procedures. The only aspen of the system described here that has any cl a ir.l to uniqueness i s the use of the worst fit allocation strategy to enable (in a multiprocessor environment) the overlapping of much of the storage management overhead. -

SOME GENERAL FEATURES OF APL

APL has only two atomic data types, real number and character. Integer and boolean values (with 0 as false and 1 as true) are embedded within the real numbers. The character type consists of the lOG (or so) characters of the APL character set, many of which are formed by overstrike combinations of graphic symbols. There is a single data structuring facility for each of the atomic types, nanely, the rectangular array. Thus, APL has arrays of numbers and arrays of characters. The present definition does not allow for array elements of arrays, although such a generalization appears to be on the horizon (1). It is seen that, for the present, APL is rather poor in data structuring facilities (although it is rich in semantics with respect to those facilities). An APL program (called a "workspace") i s compose! of data objects and defined functions. Data objects are constructed dynamically during, execution whereas defined functions are

Iowa State University Page 1 Dec...