AN672 查看數據表（PDF） - Silicon Laboratories

零件编号

产品描述 (功能)

生产厂家

AN672

PRECISION32™ SI32LIBRARY OVERVIEW

Silicon Laboratories 

AN672

6.1. Derived Types

Each object contains a context, which contains a pointer to a function table, and zero or more attributes. Derived

objects contain multiple contexts, each with their own function pointer and attributes. This allows derived types to

have attributes with the same names as those of their base types that are independent of the same named

attributes of the base type. Figure 5 shows the derived object structure.

obj* my_ object

Base

Derived

functions

variable

...

variable

functions

variable

...

variable

(*fn)()

...

(*fn)()

(*fn)()

...

(*fn)()

Base

Derived

Figure 5. Derived Object Structure

Objects also have a type signature that is not represented in the diagram. This type signature allows operations to

assert that the self parameter is an object of a specific type. Those assertions can be compiled away in release

builds. The current implementation uses cstrings and strcmp to perform runtime type checking. This allows

checking whether an object is derived from some other object and is legible in memory. Occasionally attempting to

call strcmp on a non-object can result in a fault. This is arguably less friendly than an assertion, but the error is

caught in the debugger.

6.2. Object Life Cycles

All objects in the library derive from the si32RootObject. This provisions all of the library objects with a small set of

fundamental capabilities. All objects in the library, including those that are not dynamically allocated on the heap,

employ reference counting to govern their life cycles. The operations for accomplishing this are:

allocate: An object can be allocated on the stack, or it can be incrementally, or dynamically, allocated from

one of several memory zones. The act of allocating an object reserves memory for that object and

configures it for use as an object by preparing it's reference count, function tables, etc.

initialize: All objects must be initialized prior to being used.

retain: Increments the object's reference count.

release: Decrements the object’s reference count. When a dynamic object's reference count decrements

from 1 to 0 it is deallocated.

deallocate: Called when the reference count reaches 0. Only objects dynamically allocated from the heap

zone are actually deallocated.

This reference counting mechanism is employed throughout the si32Library. The policy is that newly created

objects have a reference count of 1, and it is the responsibility of the creator of that object to release it once it is no

longer needed. When a reference to an object is provided to some other object, the receiving object must retain it

in order use it beyond the current function call. Otherwise it may be released, potentially resulting in deallocation;

thus, subsequent use may result in a pointer error. The policy is to retain it if it will continue to be used.

Consequently, every call to retain must be paired with a corresponding call to release. This allows one object to

allocate a second object, hand it over to a third object, and then release it, thus relieving itself of ownership. The

object that performed the allocation is not required to be responsible for its eventual deallocation.

In general, memory is allocated at compile time or automatically on the stack at runtime. Heap-based dynamic

memory allocation functions are provided to allocate, reallocate, and deallocate RAM in a controlled, monitored

10

Rev. 0.1

Share Link: