Browse Prior Art Database

Hardware Assistance for Type Checking

IP.com Disclosure Number: IPCOM000085744D
Original Publication Date: 1976-May-01
Included in the Prior Art Database: 2005-Mar-02
Document File: 5 page(s) / 52K

Publishing Venue

IBM

Related People

Lomet, DB: AUTHOR

Abstract

The present hardware architecture assists in supporting run time type checking. The emphasis is on the word assistance. The type checking is not realized completely in hardware. To do it in hardware alone is undesirable for a number of reasons.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 33% of the total text.

Page 1 of 5

Hardware Assistance for Type Checking

The present hardware architecture assists in supporting run time type checking. The emphasis is on the word assistance. The type checking is not realized completely in hardware. To do it in hardware alone is undesirable for a number of reasons.

In the existing widely used high-level languages, e.g., PL/1, FORTRAN, COBOL, and ALGOL (60 and 68), it is possible to perform most of the type checking at compile time. Hence, continually repeating those checks at run time is both unnecessary and inefficient. A reasonable requirement for a hardware mechanism is no performance degradation for the cases which do not require a run-time check. Despite their general similarities, there are many differences in detail as to how the above languages define their types. A built-in time checking has to be enormously flexible to support all these languages. Further, of course, it is extremely difficult to predict the direction of future languages and their data types. This argues for leaving it to software to provide the type checking details. Each language processor can then establish its own methodology.

Even when given a particular data type, it is not always clear how it should be represented. For instance, how big should an array be and what should its usage characteristics be in order to switch from a row major element representation to a sparse representation? It is difficult to choose a single best representation or even an algorithm for determining it. This is one argument for a data extension mechanism. Again, the exact details of such a mechanism are hard to establish. Thus, hardware assistance rather than a full hardware implementation appears to be the preferred approach.

The hardware mechanisms discussed hereinafter are described in terms of extensions to the area machine which was introduced in reference (1). This is not strictly necessary. A segmented virtual memory of the ordinary variety could also provide the required basis.

Using a conventional virtual memory for this purpose would, however, create inefficiencies because of the large number of small segments which must be created, leading to wasted storage because the small segments must be at least one page long. It is because the area machine makes the allocation of a large number of small areas reasonable that it is chosen to provide the framework for the exposition.

What is required of the area machine is secure storage management for each area, and protected storage associated with each area where the type information can be recorded. A brief description of the area machine is given below.

In addition to a segment table, each entry of which has an associated page table, there is a second table also associated with each segment table entry. This table is called the area table. Further, each address of the area machine is tagged to distinguish it from ordinary data, i.e., to control the generation and protection of addresses, and contains an...