Browse Prior Art Database

Large Character Strings for Segmented Memory Architectures

IP.com Disclosure Number: IPCOM000121522D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 3 page(s) / 102K

Publishing Venue

IBM

Related People

Boswell, MW: AUTHOR

Abstract

A process is disclosed that demonstrates a method for creating and managing character strings that exceed the size supported by the default string support of a computer language especially on segmented memory computer architectures. Its use in C programs will allow the programs to support character strings 2**32 bytes in length rather than the 2**16 limit imposed by large model support of most C compilers without having the performance impacts of the C compiler's huge model support.

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

Large Character Strings for Segmented Memory Architectures

      A process is disclosed that demonstrates a method for
creating and managing character strings that exceed the size
supported by the default string support of a computer language
especially on segmented memory computer architectures.  Its use in C
programs will allow the programs to support character strings 2**32
bytes in length rather than the 2**16 limit imposed by large model
support of most C compilers without having the performance impacts of
the C compiler's huge model support.

      The INTEL iAPX 86 family of micro-processors is known for its
segmented architecture.  A feature of these chips is that all storage
is addressable in 64kB chunks (segments). Any part of a given segment
of memory may be accessed in a similar manner, but accessing memory
elements within different segments requires an added level of
complexity. As a result of this complexity in inter-segment
addressing most programming languages restrict any single data object
to be no more than one segment (64kB) in size.  Many languages do
have multiple segment data object (huge model) support; however,
using this support usually places a large performance penalty on the
final program.  This penalty is such that every data element
reference that can possibly cross a segment must contain extensive
checks in order to trap and handle the times that the segments are
crossed.

      This invention can be used for any individual data type made up
of sequential data elements.  The simplest of these is an array of
characters (i.e., a string).  For simplicity I will refer to the data
type and structure of this invention as an Hstring.

      An Hstring consists of two parts.  The first part is a
structure to describe the actual data contained in the Hstring:
typdef unsigned int LENSTRING;
typedef struct H_str {
   struct H_str * strnext;       /* pointer to next control block
*/
   char far     * strpart;       /* pointer to data block */
   LENSTRING      strbuflen;     /*      of chars allocated for
strpart*/ } H_str;

      This H_str control block could contain other control
information.  One such addition could be a "LENSTRING strused" field
to keep track of the actual number of characters used for any given
strpart in order to allow any individual H_str to be only partially
filled.  There may be multiple H_str nodes for any given Hstring.

      The second part of an Hstring is a descriptor node to act as an
anchor for a collection of H_str parts.
              typedef unsigned long H_OFFSET;
typedef struct H_desc {
   H_str        *strbase;     /* poi...