An Implementation of the New IEEE Standard Routines for FASTBUS
The minimum of implementation level details in the standard document is helpful from the point of view of the implementor (and the subsequent user also). The standard for the most part is defined at a fairly abstract and functional level. This gives the implementor more freedom then would otherwise...
Saved in:
Published in: | IEEE transactions on nuclear science Vol. 34; no. 4; pp. 800 - 803 |
---|---|
Main Authors: | , |
Format: | Journal Article |
Language: | English |
Published: |
IEEE
1987
|
Subjects: | |
Online Access: | Get full text |
Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
Summary: | The minimum of implementation level details in the standard document is helpful from the point of view of the implementor (and the subsequent user also). The standard for the most part is defined at a fairly abstract and functional level. This gives the implementor more freedom then would otherwise be available, and results in quite portable routines. The explicit provision in the standard for implementation dependent extensions in operational parameters, error returns, and some routine calls, makes it quite easy to adapt the standard to particular hardware or to a particular application environment. Some mandatory features can seem unecessary. The default environment, and the mandatory requirement that primitive routines and interrupt related routines supported by the hardware must be implemented, are examples. But a goal of the standard routines is to increase uniformity of implementations, and therefore portability, and these mandatory features help in achieving that goal. The error reporting defined in the standard document can be difficult to understand, because of its potential complexity. But in our low level implementation of error reporting there were no problems. In the case of the GPM, some performance improvement could be obtained by supporting delayed execution mode. This is especially true in its use as a host interface. We have not looked at these aspects in detail however. Because of our particular application and the resultant simplicity of the implementation we have chosen not to implement delayed execution mode. It may be useful to do so at some time in the future. |
---|---|
Bibliography: | SourceType-Scholarly Journals-2 ObjectType-Feature-2 ObjectType-Conference Paper-1 content type line 23 SourceType-Conference Papers & Proceedings-1 ObjectType-Article-3 |
ISSN: | 0018-9499 1558-1578 |
DOI: | 10.1109/TNS.1987.4334740 |