JP2009059350A - Information processing apparatus and method, program, and recording medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem that it is required to minimize the size of an executable code and minimize the number of cycles. <P>SOLUTION: The computer system is provided with: a means for providing a plurality of classes for managing text string data; and a means for managing the text string data to be managed in a memory using a class specified by a user among the plurality of classes provided by the providing means. The providing means provides both classes for managing the text string data by using and not by using a heap memory. An overhead of the executable code is minimized to minimize a required memory capacity, and power consumption is minimized by execution in the minimum number of cycles. The operating system is particularly well suited to ROM based mobile computing devices. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to improvements in object oriented operating systems for computers. The invention particularly relates to an operating system based on C ++ programming techniques. A commercially available embodiment of this operating system is the EPOC32 operating system manufactured by Psion Software Plc, UK. The EPOC 32 is an operating system suitable for a mobile computer environment.

The C ++ programming language is widely used to describe application programs for computers such as personal computers, but has rarely been used to describe operating systems. When writing an operating system for a personal computer, the requirement to minimize the size of executable code or to minimize the number of cycles required to execute a step in a program is usually not preferred. . In general, performance and ease of description are more important requirements.
Nothing in particular

  However, in other situations, the space occupied by executable code must be minimized (eg, to minimize power consumption) (eg, to minimize the capacity of the ROM and / or RAM that stores it). May need to be executed in a minimum number of cycles.

  Mobile computing (eg, personal digital assistants: PDAs), smart phones (eg, GSM cellular phones with built-in word processors that can send and receive facsimiles and browse the Internet), and network computer (NC) environments are It is an example of an environment where it is advantageous to minimize code size. That is, minimization can reduce the cost of hardware (particularly ROM and / or RAM). This is particularly important in the above situation, as extensive consumer applications typically rely on relatively low hardware prices. Similarly, in the category of mobile computing and smartphones, minimizing processor execution cycles minimizes power consumption, and minimizing power consumption is critical to extending battery life. is there. A well-designed operating system written in C ++ is usually quite large and consumes considerable power. This is therefore not suitable for mobile computing, smartphones and NC environments.

  In addition, it is generally considered difficult to design a fully functional operating system in C ++ that meets the stringent requirements of code size and overhead cycles, especially the demanding requirements of mobile, smartphone and NC computing environments. It has been.

(the term)
"String Class Objects"
In C ++, text (eg, a string of characters that actually appears on a computer screen) is represented as an “object”. Those skilled in the art of C ++ or other object-oriented languages will be familiar with this categorization. Such text-related objects are of a specific type called “string class objects”. The type of class to which the object belongs (eg, a string class in the case of text) defines the operations that are allowed to be performed on the object. Only certain operations (eg, concatenating two text strings together) can be performed on a string class. Thus, a particular object of the string class represents a specific text string. It is only operated in a specific, well-defined way.

To create a string class object from an item of text when the text is present in a filing system file, conventional C ++ programming performs the following steps:
• Shift the buffer position in memory.
Read the text into the buffer using a file read service.
Use a string generation service to turn buffered data into string class objects.
-Discard the contents of the buffer.

  In C ++, it is difficult to identify the actual storage position of the text string, but it is not necessary to know the position of the text string. This is because it is a string class object that is directly manipulated, so that the actual text string is manipulated. Thus, a string class object knows virtually the memory location of a text string and can handle all of the necessary memory management tasks associated with text manipulation.

(Multiple classes of string class objects)
In the C ++ version, known as the ANSI / ISO C ++ standard draft, all objects of the string class (for example, the string class referred to as <string> in the standard library draft section above) are Sophisticated memory management tasks are handled in a way that is feasible (e.g. expansion, contraction, and merging, i.e. fully dynamic, buffer space relocation for text). However, this level of memory management uses a large amount of code and requires a very large heap space.

  Here, two examples of conventional C ++ memory management are shown.

(Example 1: C ++ literal text processing)
In C ++, there are many instances where the source code contains a text string. These text strings are known as “literal text” and are literally stored in buffer memory when the source code is compiled into executable object code. When working with literal text, you must create a string class object from it. However, by generating this string class object, a text string is generated in memory, and this text string is actually manipulated by the newly generated string class object. In short, the text string is duplicated in memory. That is, the text string is generated once in the original buffer resulting from the compilation of the source code, and is again generated at the memory location associated with the string class object that allows the manipulation of the text.

  As mentioned above, code space and power consumption are important in certain computer environments. However, with conventional C ++ (as implemented in the ANSI / ISO C ++ standard draft), there is no mechanism to eliminate duplication specific to literal text. This is particularly a problem with operating systems, as the operating system often has to deal with literal text.

(Example 2: Processing text with C ++ length limited)
In C ++, the programmer uses heap memory to process text. Text with limited length does not actually require the sufficiently flexible approach necessary to process text with unlimited length. Nevertheless, with conventional C ++, there is only a sufficiently flexible mechanism well characterized for string class objects, and no other mechanism, regardless of the length of the text. This increases the overhead in the memory management code because heap memory operations are code and cycle intensive.

  Overall, text memory management in C ++ is code and cycle intensive. Since code space and power consumption are important in a mobile environment, the conventional C ++ approach results in an operating system that has an unacceptably large code size and consumes a large amount of power.

  The operating system of the present invention replaces a string class object (eg, as defined in the ANSI / ISO C ++ standard draft) with a triple string object, ie three new object classes. Redefine it. Traditionally well-characterized memory management functions that are functionally related to <string> according to the draft ANSI / ISO C ++ standard do not apply to all three new classes. While having full functionality is useful in many environments, it is a problem (among others) in mobile computing environments where code space and power consumption are important.

  Accordingly, the general inventive idea of the present invention is to provide code operating systems with three different classes for handling text strings, ie, three different classes, each suitable for different situations. And minimizing cycle overhead. This provides flexibility. For example, a fully functional memory management function can be applied only to text strings that actually require it.

  This family of new string class objects will be referred to as “descriptors”. In the preferred embodiment, members of this family are referred to as “pointer descriptors”, “buffer descriptors” and “heap descriptors”. It should be noted that these concepts are different (although related) to the established concepts of “pointers”, “buffers” and “heaps” familiar to those skilled in the art. Also note that the descriptors envisioned herein have nothing to do with the VMS facility of the same name or the small integer UNIX® term used to identify the active operating system. is required. One skilled in the art will appreciate that the operating system can be designed to have more than three classes that handle text strings. Such modifications are also included in the technical scope of the present invention. The triple structure is the least (and most effective in almost all cases) as a propagation of classes.

  Furthermore, the descriptor is preferably polymorphic (has polymorphism). Thus, a single service can work on all descriptors. This saves considerable code and, to a lesser extent, reduces overhead. This is because each of the different descriptors requires a modified service unless such a configuration is used.

  According to a first aspect of the present invention, a computer programmed with an object-oriented operating system configured to handle objects related to text strings, wherein the operating system changes all of the objects to different ones. Perform functions and treat as belonging to one of three classes (mainly pointer descriptor class, buffer descriptor class and heap descriptor class), at least one of which has been modified to reduce code and cycle overhead A computer characterized by this is provided.

  In order to significantly reduce code and cycle overhead, the present invention replaces a conventional single form string class object with three different forms (for example), each form optimized for different situations. Based on the knowledge that the operating system needs to be redesigned instead of objects.

  In the preferred form of the present invention, conventional memory intensive text processing techniques apply only to objects that belong to a new descriptor class (ie, heap descriptor) that defines objects that require such techniques. The On the other hand, pointer and buffer descriptor classes are designed to reduce code and processor cycles compared to traditional string classes.

  Using the two examples described in the above prior art (ie, Example 1: C ++ literal text processing and Example 2: C ++ length limited text processing), the operating system of the present invention: (I) handle literal text so that duplication of literal text is no longer necessary, (ii) make intensive use of heap memory code only in limited situations where it is actually needed, and (When you know the maximum length of the text), instead of using static memory, handle text that is determined dynamically at runtime. Further details of the specific process are described below (see the best mode for carrying out the invention).

  Preferably, the operating system is configured to handle not only text but also raw data using the same triple structure.

  In addition to the computer / operating system combinations defined above, other inventive aspects could be recognized as well. For example, any device that must interface with such an operating system must use the same triple structure for string class objects. For example, peripheral device driver software such as a solid-state memory device needs to use such a triple structure. The software for the peripheral device control panel is the same.

  Accordingly, in a second aspect of the present invention, there is provided a computer peripheral device programmed with an object-oriented operating system configured to handle objects related to text strings, wherein the operating system receives all of the objects respectively. Belongs to one of three classes (mainly pointer descriptor class, buffer descriptor class, and heap descriptor class) that perform different functions, at least one of which has been modified to reduce code and cycle overhead A peripheral device is provided, characterized in that the peripheral device is programmed to treat the object as if it were in the three classes.

  In a third aspect of the present invention, a computer operating system configured to handle objects related to text strings and encoded on a computer readable medium, the operating system comprising: In one of three classes (mainly pointer descriptor class, buffer descriptor class, and heap descriptor class), each executing a different function, at least one of which has been modified to reduce code and cycle overhead An operating system is provided which is characterized as being treated as belonging.

  According to a fourth aspect of the present invention, there is provided a method for operating a microprocessor using a computer operating system configured to handle objects related to text strings, wherein the operating system includes: Belongs to one of three classes (mainly pointer descriptor class, buffer descriptor class, and heap descriptor class) that perform different functions, at least one of which has been modified to reduce code and cycle overhead A method is provided that is characterized as being treated as a thing.

  In a fifth aspect, a computer-readable medium encoded with a computer operating system configured to handle objects related to text strings, wherein the operating system includes all of the objects, each Those that belong to one of three classes (primarily pointer descriptor classes, buffer descriptor classes, and heap descriptor classes) that perform different functions, at least one of which has been modified to reduce code and cycle overhead A medium characterized in that it is treated as is provided. Typically, the computer readable medium is a mask ROM. For distribution, the medium may be a general CD-ROM or floppy disk.

  The present invention will be described with respect to an embodiment known as EPOC32. EPOC32 is a 32-bit operating system (particularly) for mobile and smartphone environments developed by Psion Software Plc, UK. A more detailed description of the EPOC32 embodiment is disclosed in the part attached to Appendix 1 of the SDK for EPOC32 published by Psion Software Plc, UK. To the extent that the rights of the inventor and assignee are not limited in any way, the entire SDK is incorporated herein by reference.

  The EPOC 32 has been ported to run on a number of different microprocessor architectures. Details of operating system porting are essentially outside the scope of this specification, but will be appreciated by those skilled in the art. In particular, EPOC32 has been ported to the ARM RISC type microprocessor of Advanced RISC Machines in the UK. Various models of ARM microprocessors are widely used in digital cellular telephones and are well known to those skilled in the art. However, the present invention can be implemented on a number of different microprocessors. Accordingly, the claims appended hereto should be understood to cover any and all hardware and software implementations in which the operating system performs the functions as recited in the claims. is there.

  Returning to the example of literal text and limited-length text given in the prior art discussion above, EPOC 32 uses the triple structure for string class objects as follows.

(Example 1: Literal text in EPOC32)
As mentioned above, in conventional C ++, text strings for literal text are duplicated in memory. That is, it is generated once in the original buffer that results from the compilation of the source code and then replicated again at the memory location for the string class object that allows the manipulation of the text. This duplication is useless.

  However, EPOC 32 uses a pointer descriptor that points to the original memory location of the literal text (ie, the memory location defined by the compiler). This pointer descriptor (referred to as a TPtrC pointer descriptor in EPOC32) is an object of a string class for literal text (in C ++, normally a pointer is not essentially recognized as an object). Thus, the EPOC32 pointer / object hybrid completely eliminates the need for additional copies of literal text.

(Example 2: Text with limited length in EPOC32)
As described above, in conventional C ++, there is only a mechanism that uses a sufficiently flexible and well-characterized string class object regardless of the length of the text, and no other mechanism. Since heap memory processing is code and cycle intensive, this creates a lot of overhead in the memory management code.

  In EPOC32, there is a special class of string objects of limited size called buffer descriptors. Since it is limited in size, it does not require complex memory allocation code to operate. Furthermore, the buffer descriptor can use static memory (not heap memory). Static memory cannot be relocated in a manner that uses heap memory intensive code, but it is more efficient to use because it requires fewer code cycles to perform the necessary operations. (Thus reducing power consumption). The EPOC 32 uses heap memory with a lot of cycle overhead only if it is actually dynamic. In that case, heap descriptor class is used.

  The EPOC 32 defines a length-limited string class parameter using a class template of the “TBuf” class (a class template defines the properties of a number of objects of the string class. For example, TBuf A template for buffer descriptors, that is, a template for all objects of the string class of buffer variants, TBuf defines certain common properties for all such string class objects.)

In addition to minimizing code size and cycle overhead, EPOC 32 exhibits several important features. The main points are as follows.
• Strings and raw data buffer class objects behave as “flat” structures.
• Descriptors give polymorphic properties (polymorphism).
Descriptors allow for uniform coding of Unicode (ASCII) and ASCII (ASCII).

(Strings as flat structures and raw data buffer class objects)
All descriptors have a “flat” structure (ie, when a descriptor is copied, only the descriptor itself is copied. In conventional C ++, copying an object is not just a copy of the object itself, but all related objects. There was also a need for a copy of the pointer and the data pointed to by the pointer, that is, a copy of the complex associated structure that gives the object meaning. Thus, in EPOC32, copying descriptors is much more economical in memory overhead and cycles than copying objects that are equivalent in normal C ++.

This is implemented in EPOC 32 as follows for buffers and pointers. :
The buffer descriptor (TBuf) contains the actual text referenced by the buffer. Thus, copying the buffer essentially copies the associated text. There is no need for a copy of the pointer and associated data as in C ++.
Since the pointer descriptor (TPtr) contains a C ++ type pointer, only a copy of the single TPtr is required when copying. In conventional C ++, it was necessary to copy not only one entity but also other related pointers and text.

(Descriptor as a polymorphic object)
A common effect is achieved by different mechanisms, but when all objects in a group act like a single object, the group of objects is said to exhibit polymorphism. In conventional C ++, polymorphism is provided by virtual functions. That is, all the polymorphic objects have a pointer to the virtual function table at a common position (thus a pointer is required in each object). This table identifies the actual code for each polymorphic function. A separate table is required for each class that shares polymorphism. However, this approach uses a relatively large space because each pointer is 32 bits (ie 4 characters) and each object requires a pointer to a virtual function table. In addition, a 32-bit long field is used in each object.

  In (especially) mobile operating system environments, this overhead is a problem. In EPOC32, the string class object is handled as follows. That is, a 32-bit long field is subdivided, and the first 4 bits describe the descriptor type. The function then refers to the 4 bits and points to the correct text position (for example, in the descriptor itself if the descriptor is a buffer or the like). Thus, each of the three different classes of descriptors for string class objects (ie, pointer descriptor, buffer descriptor, and heap descriptor) can be described using only the first 4 bits of a single 32-bit field. This provides polymorphism. In this way, considerable memory savings are achieved. More generally, a field shares a machine language with another data item.

(Code that does not change in Unicode and ASCII)
In C ++, 16-bit Unicode coding would double the size of all text data that would otherwise be 8-bit code. Conventionally, when a programmer writes source code, it has been necessary to decide whether to use ASCII or Unicode.

  In EPOC32, the same source code is used regardless of the final choice of ASCII or Unicode. This is accomplished by building the system using class name aliases that are not changed by ASCII and Unicode, but not the class itself (eg, pointer descriptors, buffer descriptors and heap descriptors). Therefore, instead of using the pointer TPtr16 indicating the Unicode code or using TPtr8 indicating the ASCII code, the programmer performs the build using the TPtr class name. At build time, the class name can be compiled as either 16-bit Unicode or 8-bit ASCII code. This approach can be applied to include all character sets encoded with different bit lengths.

(Supplementary benefits of EPOC32)
In C ++, the text string normally ends with “0”, which allows the system to easily know the end position of the text string. In EPOC32 this is no longer necessary. This is because the descriptor includes a description that defines the length of data to be referred to. Therefore, it is not necessary to use “0” to indicate the end of every text item, so that the code can be further saved.

(Summary of descriptor characteristics)
There are three classes of descriptors. That is, a pointer descriptor, a buffer descriptor, and a heap descriptor.

● There are two types of “pointer descriptors”. An invariant (const) constant descriptor TPtrC and a variable pointer descriptor TPtr.
Invariant pointer descriptor: TPtrC
・ The data cannot be changed.
• All member functions are invariant.
Used for references to immutable strings or data (eg, data that cannot be changed).
Since it is derived from TDesC, it has a large number of member functions.
Variable pointer descriptor: TPtr
Data can be changed by this descriptor (variable) as long as the maximum length set by the designer is not exceeded.
-Directly point to the memory area that contains the area to be changed.
-The number of data items included is determined by the pointer length.
Inherit all TDesC member functions, plus TDes member functions that manipulate and modify data.
A pointer descriptor is separate from the data representation, but consists of a pre-existing area in the memory.

● There are two forms of “buffer descriptors”.
Invariant buffer descriptor: TbufC <Tint S>
Data can be set in the descriptor at the time of creation or later using an assignment operator (operator =).
• The length is defined by an integer template. That is, TBufC <40> includes 40 data items.
Inherit all TDesC member functions.
Variable buffer descriptor: Tbuf <Tint S>
-It contains (variable) data that can be changed within the maximum length.
• Maximum length defines the maximum number of data items.
• The actual length defines the actual number of data items.
• The length is defined by an integer template. That is, TBuf <40> includes only 40 data items.
The data area is a part of the descriptor object.
It is useful for including data that needs to be manipulated and changed, but its length does not exceed a known maximum (eg WP text).
Inherit all TDesC member functions plus TDes member functions for data modification and manipulation.

-Heap descriptor is only one form-Invariant heap descriptor: HBufC
-Data is included after the length information-The data area is part of the descriptor object, and the entire object occupies cells allocated from the heap-At the time of creation or using the assignment operator (operator =) Later, data can be set in the descriptor. • Inherits all TDesC member functions. • Reassignable, ie the data area can be expanded or reduced.

=====================================
<< Appendix 1 >>
Psion Software Plc. EPOC32 “Descriptor” SDK (excerpt) to be issued in 1997. Psion Software Plc. Refers to the entire SDK published in July 1997 (Revision 1.0).

__________________________________
(SDK: descriptor outline)
The triple structure of descriptor classes (ie, pointer descriptor class, buffer descriptor class, and heap descriptor class) allows access and manipulation of both strings and general binary data, regardless of the type of memory in which they reside. Provide a safe and consistent mechanism to do. For example, a string of code parts in ROM can be handled in the same way as a file record in RAM.

  The data represented by the descriptor exists in a data area at a predetermined position in the memory. This data area is not expandable. Manipulation of descriptor data is safe in the sense that accidental or deliberate access to memory outside the defined data area is not allowed (generally code that performs invalid access (usually known as panic) Cause an exception).

Since descriptors do not differentiate between the type of data represented, both string and binary data are treated similarly. Some of the descriptor object member functions are designed to manipulate text data, but they also work on binary data. This unifies the handling of strings and binary data and increases efficiency by allowing code to be shared. Descriptor classes satisfy many important requirements. :
Provide support for both Unicode and ASCII text. The _UNICODE macro is used to select ASCII or Unicode build variables.
・ Unify handling of strings and binary data.
Enables safe and convenient reference of text or data in ROM.
Provide rich member functions that operate on related text or data.
• Allows data modification, but prohibits any attempt to write outside the defined data area.
Eliminate memory overhead associated with virtual functions.
It acts like a built-in type, can be created safely on the stack, and can be safely orphaned.
(HBufC is allocated on the heap and is an exception to the rule.)

__________________________________
(ASCII and Unicode text)
E32.descriptors.char-set

ASCII text characters are represented by 8 bits (1 byte), while Unicode characters require 16 bits (2 bytes). To support both ASCII and Unicode text, the descriptor class has two variants, 8-bit and 16-bit. For example, there are two pointer descriptor classes, TPtr8 and TPtr16.

  The program can be configured to support either Unicode or ASCII text using class names that are independent of build variables. For example, the descriptor class TPtr can be used to configure the system to use either TPtr8 or TPtr16. It is determined at build time depending on whether or not the _UNICODE macro is defined.

  The following code extracted from the header file E3232def.h (see Appendix 1 of the SDK) shows how to achieve this by properly defining a class name independent of the variables.

#If defined (_UNICODE)
...
typedef TPtr16 TPtr;
...
#Else
...
typedef TPtr8 TPtr;
...
#Endif

  Application code should not use "C" style string literals directly. Instead, the _S macro should be used to return the appropriate type of pointer to generate the appropriate width “C” style string. Also, the _L macro (_L for "literal") should be used to create the appropriate type of descriptor. See e32.macro._S and e32.macro._L for definitions of these macros.

For example,
const TText * str = _S (“Hello”);
Generates a string of 1-byte characters created in ASCII, but generates a string of 2-byte characters in Unicode creation.

_L (“Hello”);
Generates an 8-bit descriptor created in ASCII and a 16-bit descriptor created in Unicode. For example, _L (“abcdef”) is always used instead of plaintext “abcdef” so as to always create a correct variable descriptor.

  By using macro_S8 and macro_L8, respectively, an 8-bit “C” style string and an 8-bit pointer descriptor are explicitly generated independent of the created variables. Corresponding 16-bit versions, _S16 and _L16 can also be used. For these definitions, see e32.macro._S8, e32.macro._L8, e32.macro._S16 and e32.amcro._L16.

__________________________________
(Length and size)
E3232.descriptors.length-and-size

A descriptor characterizes the data it represents by the length of that data. The length of the descriptor is the number of data items. For an 8-bit variable, the descriptor length is the number of 1-byte data it represents, and for a 16-bit variable, the descriptor length is the number of 2-byte data it represents.

The descriptor size is the number of bytes occupied by the descriptor data. This need not be the same as the descriptor length. For an 8-bit variable, the size is the same as the length, but for a 16-bit variable, the size is twice the length. A descriptor that allows modification of data is also characterized by its maximum length. For these descriptors, the length of the data represented can vary from zero to this maximum value, including the maximum value. The maximum length of any descriptor is 2 ^28.

__________________________________
(Text and binary data)
E3232.descriptors.text-and-binary

In “C”, the string is characterized by requiring a zero terminator to indicate the end of the string. These cause a number of problems. In particular, they cannot contain binary data (if the data contains binary zeros) and operations on them are generally not efficient. “C” strings need to be handled differently from binary data, as reflected in the ANSI “C” library function groups, memxxx () and strxxx (). Descriptors allow string and binary data to be represented in the same way, which allows the same function to be used in both cases. For binary data, an 8-bit descriptor must be explicitly used. For binary data, the distinction between Unicode and ASCII is meaningless. Note that 16-bit binary data is virtually unused.

______________________________________________________
(Memory allocation)
E3232.descriptors.alloc

Descriptor classes (except HBufC) behave like built-in types. They do not allocate memory and have no destructors. This means that descriptor classes can be "isolated" on the stack as well as built-in types. This is especially important in situations where you can leave code. (See E3232.exception.trap.cleanup.requirements for the impact of isolation)
The HBufC descriptor object is allocated on the heap and is not created on the stack.

__________________________________
(exception)
E3232.descriptors.exceptions

All parameters of the descriptor member function are examined to ensure that the operation is correctly specified and no data is written outside the descriptor's data area. As a result, no member function can extend the variable descriptor beyond its maximum allocation length. Depending on whether the original allocation is large enough or a larger descriptor is dynamically allocated at run time in anticipation of the need for larger descriptors, ensuring that all descriptors are large enough to accommodate the data is It is the responsibility of the programmer. The static approach is simpler to implement, but the dynamic approach may be more effective in certain cases where it turns out to be useless in certain cases. In the case of an exception, it can safely be assumed that no unauthorized memory access is performed and that no data is moved or damaged.

__________________________________
(Descriptor type)
E3232.descriptors.types

There are three types of descriptor objects. That is,
Pointer descriptor A descriptor object is created in a pre-existing area in memory, although it is separate from the data it represents. This includes
Immutable pointer descriptor, TPtrC
Variable pointer descriptor, TPtr
There are two forms.

Buffer descriptor The data area is a part of the descriptor object. This includes
Immutable buffer descriptor, TBufC <Tlnt S>
Variable buffer descriptor, TBuf <Tlnt S>
There are two forms.

-Heap descriptor The data area is a part of the descriptor object, and the entire object occupies cells allocated from the heap. this is,
Immutable heap descriptor, HBufC
There is only one form.

_____________________________________________
(Pointer descriptor-TPtrC)
E3232.descriptors.buffer-descriptor.TPtrC

TPtrC is an immutable descriptor that does not change any data. All of its member functions are constant (except for constructors). FIG. 1 schematically shows TPtrC. TPtrC is useful for referencing immutable strings or data. For example, it is useful when accessing text generated in ROM resident code or when passing a reference to data in RAM whose data should not be altered by that reference. TPtrC is derived from TDesC, which provides a number of member functions that manipulate its contents, such as, for example, the positioning of characters in the extracted portion of text or data.

________________________________
(Pointer descriptor-TPtr)
E3232.descriptors.buffer-descriptor.TPtr

TPtr is a pointer descriptor that can change data within a range in which the data does not exceed the maximum length. The maximum length is set by the constructor. TPtr directly points to an area in the memory containing the data to be changed. TPtr is shown schematically in FIGS. 2A and 2B.

  The maximum number of data items that an area can contain is defined by the maximum length. The length of TPtr indicates how many data items are currently included in the data. When this value is smaller than the maximum value, a part of the data area is unused. TPtr is a reference to an area of RAM that contains data that is intended to be changed by reference, or a reference to an area of RAM that has no data yet but is generated using descriptor references and member functions. It is effective to generate

  TPtr is also useful for generating a reference to a TBufC or HBufC descriptor that contains the data being changed. TPtr used in this way points to a TBufC or HBufC descriptor. Data included in the TBufC or HBufC descriptor can be changed by TPtr. TPtr is derived from TDes derived from TDesC. Therefore, TPtr inherits all the const member functions defined in TDesC, as well as the TDes member functions that can manipulate and change data, such as adding characters to the end of existing text. .

_____________________________________________
(Buffer descriptor-TBufC <Tint S>)
E3232.descriptors.buffer-descriptor.TBufC

TBufC is a buffer descriptor having length information followed by a data area. Data can be set in the descriptor at generation time or at any other time using the assigned operator (operator =). The data held by the descriptor is unchanged. TBufC is shown schematically in FIG. The length of TBufC is defined by an integer template, for example, so that TBufC <40> defines TBufC that can contain up to 40 data items.

  TBufC is derived from TDesC, which provides many member functions that manipulate its contents, such as positioning characters in text or extracting a portion of data. TBufC provides a member function Des () that creates a variable pointer descriptor (TPtr) that refers to TBufC. As a result, TBufC data can be changed by TPtr as schematically shown in FIG. The maximum length of TPtr is the value of the integer template parameter.

__________________________________
(Buffer descriptor-TBuf <Tint S>)
E3232.descriptors.buffer-descriptor.TBuf

TBuf is a buffer descriptor including data that can be changed within a range where the data does not exceed the maximum length. FIG. 5 schematically shows TBuf. The number of data items that TBuf can contain in the internal data area is defined by the maximum length. The length of the descriptor indicates how many data items are currently included in the data area. When this value is smaller than the maximum value, a part of the data area is unused. The maximum length of TBuf is defined by an integer template. For example, TBuf <40> defines a TBuf that can contain up to 40 (and not exceed!) Data items. TBuf is useful for holding data that requires manipulation and modification, such as word processor text, but whose length does not exceed a known maximum. TBuf is derived from TDes derived from TDesC. Therefore, TPtr inherits all the const member functions defined in TDesC, as well as the TDes member functions that can manipulate and change data, such as adding characters to the end of existing text. .

__________________________________
(Heap descriptor-HBufC)
E3232.descriptors.buffer-descriptor.HBufC

HBufC is a descriptor having length information and subsequent data. It is allocated on the heap using the static member functions New (), NewL () or NewLC (). The descriptor length is passed as a parameter to these static functions. FIG. 6 schematically shows HBufC. Data can be set in the descriptor at generation time or at any other time using the assigned operator (operator =). The data that the descriptor already has is constant. HBufC is derived from TDesC, which provides a number of member functions that manipulate its contents, for example, positioning characters in text or extracting a portion of data.

  HBufC provides a member function Des () that creates a variable pointer descriptor (TPtr) that refers to HBufC. This makes it possible to change the HBufC data using TPtr. The maximum length of TPtr is the length of the HBufC data area. FIG. 7 schematically illustrates this.

  Heap descriptors can be relocated. The function ReAlloc () or ReAllocL () enables expansion or contraction of the data area of the heap descriptor. However, the length of the data area cannot be shorter than the length of data currently held. Before reducing the data area, the data held by the descriptor must be reduced. The length of data that can be set in the heap descriptor by the allocation operator is limited to the space allocated to the data area of the descriptor. The memory occupied by the heap descriptor needs to be explicitly freed by calling User :: Free () or using the keyword delete.

__________________________________
(Relationship between descriptor classes)
E32.descriptors.classes

All descriptor classes, TPtrC, TPtr, TBufC, TBuf, and HBufC are derived from the abstract base classes TDesC and TDes. The class TBufCBase has been shown as an abstract base class, simply because it is easy to implement. FIG. 8 schematically shows the relationship between classes.

  The behavior of the actual descriptor class is very similar, so most functions of the descriptor are provided by the abstract base class. Since descriptors are widely used (especially in the stack), it is necessary to minimize the size of descriptor objects. To assist this, no virtual function is defined in order to eliminate the overhead of the virtual function table pointer in each descriptor object. As a result, the base class potentially has knowledge of the classes derived from it. E32 supplies two descriptor class variables, one that handles 8-bit (ASCII) text and binary data, and one that handles 16-bit (Unicode) text. The actual 8-bit variables are TPtrC8, TPtr8, TBufC8 <Tint S>, TBuf8 <TInt S>, and HBufC8, and the 8-bit variables of the abstract class are TDesC8 and TDes8. Similarly, the names of the 16-bit variables are TPtrC16, TPtr16, TBufC16 <Tlnt S>, TBuf16 <TInt S>, HBufC16, TDesC16, and TDes16, respectively. This distinction is transparent to the descriptor used to represent the text. By writing programs that generate and use TPtrC, TPtr, TBufC <Tint S>, TBuf <Tint S> and HBufC classes, compatibility for both Unicode and ASCII is maintained. Depending on whether the _UNICODE macro is defined, the appropriate variable is selected at build time. If the _UNICODE macro is defined, a 16-bit variable is used, otherwise an 8-bit variable is used as described in E32.descriptors.char-set.

  Binary data descriptors must explicitly use 8-bit variables. In other words, the code must explicitly generate classes TPtrC8, TPtr8, TBufC8 <Tint S>, TBuf8 <TInt S>, and HBufC8. Although it is possible to explicitly use 16-bit variables for binary data, it is not recommended. In general, 8-bit and 16-bit variables are identical in structure and implementation, and the description of the class itself uses names that are independent of the build throughout.

  Note that many member functions take TUint8 * or TUint16 * type arguments, depending on whether the descriptor is an 8-bit or 16-bit variable. To simplify the explanation, these arguments are replaced with the function prototype TUint? ? Describe as *.

It is a figure which shows the outline of TPtrC. It is a figure which shows the outline of TPtr. It is a figure which shows the outline of TBufC. It is a figure which shows the relationship between TPtr and TBufC. It is a figure which shows the outline of TBufC. It is a figure which shows the outline of HBufC. It is a figure which shows the relationship between TPtr and HBufC. It is a figure which shows the relationship of inheritance and derivation between classes.

Claims (19)

A computer device programmed with an object-oriented operating system configured to handle objects related to text strings, the operating system performing all of the objects, each performing a different function, at least one of which is code And a computer apparatus characterized in that it is treated to belong to one of three classes that have been modified to reduce cycle overhead. A computer peripheral programmed with an object-oriented operating system configured to handle objects related to text strings, wherein the operating system performs all of the objects, each performing a different function, at least one of them. Program to treat one as belonging to one of the three classes, one of which has been modified to reduce code and cycle overhead, and also so that the peripheral treats the object as belonging to the three classes Peripheral device characterized by being made. A computer operating system configured to handle objects related to text strings and encoded in a computer readable medium, wherein the operating system performs all of the objects, each performing a different function, An operating system, characterized in that it is treated as belonging to one of three classes, at least one of which has been modified to reduce code and cycle overhead. A method of operating a microprocessor using a computer operating system configured to handle objects related to text strings, wherein the operating system performs all of the objects, each performing a different function, at least A method characterized in that it is treated as belonging to one of three classes, one of which has been modified to reduce code and cycle overhead. A computer readable medium encoded with a computer operating system configured to handle objects related to text strings, wherein the operating system performs all of the objects, each performing a different function. A medium characterized in that it is treated as belonging to one of three classes, at least one of which has been modified to reduce code and cycle overhead. 6. The apparatus or method according to claim 1, wherein one object of the three classes is a pointer. The apparatus or method of claim 6, wherein the pointer points to the original memory location of the literal text. The apparatus or method according to claim 6, wherein the object has a flat structure. 6. An apparatus or method according to any one of the preceding claims, wherein one object of the three classes handles text of limited length. 10. The apparatus or method of claim 9, wherein the object handling length limited text is provided by a limited subset of memory management functions that may be available. 11. The apparatus or method of claim 10, wherein the object that handles text of limited length uses static memory. 10. The apparatus or method of claim 9, wherein the object that handles text of limited length is a flat structure. 6. An apparatus or method according to any one of the preceding claims, wherein one object of the three classes uses heap memory and requires a full set of available memory management functions. 14. An apparatus or method according to any one of the preceding claims, wherein the object of any of the three classes is polymorphic. Polymorphism is achieved in one instance by an operating system that includes a function that examines a given field in each object and provides different types of action depending on the value in the field. Item 15. The apparatus or method according to Item 14. The apparatus or method of claim 15, wherein the field shares another data item with the machine language. 17. An object according to claim 1, characterized in that it is written in a form that does not change in an 8-bit character set and a 16-bit character set using an alias of a class name that does not change in an 8-bit character set and a 16-bit character set An apparatus or method according to any one of the preceding claims. 18. Apparatus or method according to claim 17, characterized in that it is written in a form that does not change in ASCII and Unicode, using an alias for class names that does not change in ASCII and Unicode. 19. An apparatus or method according to any one of the preceding claims, wherein an object of any of the three classes is essentially specified in length and therefore has no "0" terminator.

Images