If a register array is assigned an ID, the first register receives the value of the ID. Each subsequent register in the array is assigned the ID of the previous register incremented by one. For example:

    REGISTER { reg_number(5) } R[32];

Register R[0] is assigned ID 5, R[1] is assigned ID 6, R[2] is assigned ID 7, and so forth. You can use the reg_number_increment parameter to step between registers in an array, starting with reg_number. If, for example, reg_number_increment was set to 2 in the earlier example, R[1] would not be used.

Example 2.3 shows how to use the virtual parameter. The parameter enables the abstract definition of a resource in much the same as C++ permits the definition of pure virtual functions. If virtual functions are used, the C++ programmer of the derived class is forced to implement them. Similarly, the LISA+ programmer is forced to implement a read and a write access behavior and not rely on the existence of a variable that has the resource name.

component foo
{
	resources
	{
		REGISTER { type(uint32_t), virtual(true), read_function(GetStatus),
           write_function(SetStatus) } STATUS;
		REGISTER { type(uint32_t) } ENABLED;
		REGISTER { type(uint32_t) } ACTIVE;
	}

	behavior GetStatus(uint32_t id, uint64_t *data, bool doSideEffects) :
       AccessFuncResult
	{
		*data = ENABLED & ACTIVE;
		return ACCESS_FUNC_OK;
	}

	behavior SetStatus(uint32_t id, const uint64_t *data, bool doSideEffects) :
       AccessFuncResult
	{
		return ACCESS_FUNC_OK;
	}
}

In Example 2.3, component foo has registers STATUS, ENABLED and ACTIVE:

Registers are accessed in the same way as C variables. See Example 2.4.

behavior
{
    R[4] = a;
    R[b] = gpr[a];
}

LISA+ supports registers that are embedded within other registers. That is, they are a component, or child, of a parent register. The implementation of component registers requires that:

The specification of the component register can be fully defined by the following parameters:

The registers behave like an integer of the size specified in the bitwidth attribute. However, all modifications on a child or parent register affect the value of the corresponding parent or child registers. This is handled automatically. A child register can also be a parent. This enables component register relationships to extend to component register hierarchies. The consistency of the hierarchies is enforced automatically.

A simple example of a component register hierarchy is shown in Example 2.5:

REGISTER { bitwidth(64) } RAX;
REGISTER { bitwidth(32), partof(RAX) } EAX;
REGISTER { bitwidth(16), partof(EAX) } AX;
REGISTER { bitwidth(8), partof(AX) } AL;
REGISTER { bitwidth(8), partof(AX), lsb_offset(8) } AH;

The default functions that a debugger calls to access registers can be overridden by using behaviors that conforms to a specific prototype. The prototypes for these functions are listed in Table 2.2:

behavior <name>(uint32_t reg_id, uint64_t *data,
       bool side_effects) : AccessFuncResult

behavior <name>(uint32_t reg_id, const uint64_t *data,
       bool side_effects) : AccessFuncResult

behavior <name>(uint32_t reg_id, string &data,
       bool side_effects) : AccessFuncResult

behavior <name>(uint32_t reg_id, const string &data,
       bool side_effects) : AccessFuncResult

Where:

For write_function, the semantics for side_effects are:

Register and memory access functions must inform the calling code whether or not the access operation was successful. The following symbols have been added to the LISA+ language for this purpose:

In Example 2.6, registers R1 and R2 are assigned CADI ids and a shared read access function. The access function returns one's complement for R1 and two's complement for R2. If the access function is assigned to a different register, it reports an illegal argument.

resources
{
    REGISTER { read_function(my_read), reg_number(1) } R1;
    REGISTER { read_function(my_read), reg_number(2) } R2;
}

behavior my_read(uint32_t id, uint64_t *data, bool se) : AccessFuncResult
{
    if (id == 1)
        *data = ~R1;
    else if (id == 2)
        *data = ~R2 + 1;
    else
        return ACCESS_FUNC_IllegalArgument;

    return ACCESS_FUNC_OK;
}

PV peripherals implement memory-mapped register by connecting an external slave port of type PVBus to an internal slave port of type PVDevice.

Register IDs are specified explicitly and have the same value as the address offset. The register accesses are implemented by an internal read/write behavior. Memory-mapped port accesses and debug accesses are directed to this behavior.

If a unique internal port of type PVDevice exists, all memory-mapped register read and write operations over this port are directed to the automatically generated access functions.

If not already overwritten by read_function and write_function parameters the new access functions are also used for debug accesses.

Masks are used to influence the register access:

Two additional tokens can be used to generate error responses:

If the automatic mechanisms are not sufficient, you can provide a local implementation that overrides the access behaviors. The arguments for the access behaviors are:

register_read_behavior(uint32_t reg_id, pv::ReadTransaction tx) :
    pv::Tx_Result

register_write_behavior(uint32_t reg_id, pv::WriteTransaction tx) :
    pv::Tx_Result

Each register resource has an ID that must be used in the read and write behaviors. See Debugger register access functions.