Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for Handling Intermediate Language Imposed Rules in Stream Based Architectures

IP.com Disclosure Number: IPCOM000114996D
Original Publication Date: 1995-Feb-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 111K

Publishing Venue

IBM

Related People

Kleon, GC: AUTHOR

Abstract

Pool based Intermediate Language (IL) architectures impose various ordering rules on the code which make up their constituent streams. Generally, these rules exist to make life easier for the compiler backends. Unfortunately, by making life easier for a backend compiler, the IL architecture can make life more difficult for the frontend. These difficulties (for the frontend designer/developer) can be substantial when dealing with single pass frontends targeting languages supporting strange constructs.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method for Handling Intermediate Language Imposed Rules in Stream
Based Architectures

      Pool based Intermediate Language (IL) architectures impose
various ordering rules on the code which make up their constituent
streams.  Generally, these rules exist to make life easier for the
compiler backends.  Unfortunately, by making life easier for a
backend compiler, the IL architecture can make life more difficult
for the frontend.  These difficulties (for the frontend
designer/developer) can be substantial when dealing with single pass
frontends targeting languages supporting strange constructs.

      The problems associated with having to output IL codes to
streams in an order unnatural to what would be considered the normal
flow of processing within a frontend compiler is solved herein and
the developer is freed from the task of having to write IL codes to a
stream in any particular order.

      A generalized virtual IL manager is implemented to take care of
the maintenance and eventual ordering of IL codes within virtual
streams before presenting them to the backend.  A mechanism is
defined to tell the virtual IL manager to which rule/stream the
subsequently emitted IL codes belong.

      The mechanism for defining and communicating the rules of order
consists of identifying all logically grouped codes within each
stream and then associating with each group a symbol and a number
indicating the groups relative position in the stream relative to the
other groups in the same stream.  Then the IL focus is set to
indicate to the virtual IL manager to which group within a specified
stream subsequently generated IL codes belong.

For example, the following three rules were used:
  o  1.  "BLOCK1" IL codes must appear first in the "StreamN" stream.
  o  2.  "BLOCK2" IL codes must appear after "BLOCK1" codes in the
          "StreamN" stream.
  o  3.  "BLOCK3" IL codes must appear after "BLOCK1" codes and
before
          "BLOCK2" codes.

The three stream, symbol and relative position triples are defined as
follows:
  o  (StreamN,Rule_BLOCK1,1), (StreamN,Rule_BLOCK2,3),
      (StreamN,Rule_BLOCK3,2)

      The virtual IL manager is informed as to  which of these
triples is in effect for subsequently emitted IL codes.

      To accommodate more complex rules where logical groupings of
differing IL codes are addressed relative to or nested within other
groupings, the relative position element of the above triples is
replaced by an appropriate mapping function which yields a relative
key.

      In general, where we...