Hi,
Carl Lionberger wrote:
The thought was that the subarray record would be purely a soft
record, and any hardware device support would be for waveform records
that the subarray would read from. The MALM code makes sense in this
context because the API for the dbaccess (as Noburu alluded to)
always starts at element 0 of the source record. Therefore it is
impossible to index an element larger than the buffer space you have.
In the case of a module which have more memory than the main memory on
CPU board, you might want access part of memory using a subarray record.
But the subarray record does not allow it.
We wanted to divide a very long waveform into several small waveforms so
that we can monitor it on medm/dm2k. In this case, we need O(N * N) size
of buffer memory for EPICS database, where N is a size of source
waveform. Using the compact subarray record, it can be reduced to O(N)
buffer size.
As Carl pointed out, the specification of the SubArray records is a
result of the dbaccess API. In other words, if the dbaccess library
have had an API which allow access to a part of waveform data, we
would have another specification of the SubArray record.
( And it could be quite similar to our compactSubArray record.)