|Home > Iris APIs > Tables|
The tables interface allows an instance to expose an ordered series of records which all have the same fields.
Clients first call
table_getList() to get a list of tables exposed by the instance. Then they call
table_write() to read or write the contents of the table cells.
This interface can be used to expose arbitrary information in tabular form. Enough meta information is provided so that clients can display the information without understanding it.
If it is more appropriate to represent the information as a resource, memory space, or disassembly, they should be used instead, because they contain semantic information.
Table rows are accessed by a densely allocated index. Each index uniquely corresponds to one table row. So, for example, index range 4-8 is 5 table rows.
Information that has a non-dense key, for example addresses, or that uses non-unique keys, for example addresses in translation tables, can expose this non-dense or non-unique key as a column and hide the index column. Then the index becomes an opaque id of a display slot.
The following types are allowed in table cells and must be supported by all clients:
NumberU64 is used to represent binary data which exceeds 64 bits,
for example cache line data.
The cell values returned or specified must be consistent with the cell type specified
NumberU64 in a
column has the same length for all rows. The length is specified in the
TableColumnInfo. Clients must handle inconsistent types
As for resources and memory, the semantics are peek rather than bus read and poke rather than bus write, and reads and writes should be as side-effect free as possible.