IEEE Transactions on Nuclear Science, Vol. NS-26, No. 4, August 1979

An Incremental Compiler for Data Acquisition

L. M. Taff and F. Sporrel**

ABSTRACT

Computer software is described which incrementallycompiles threaded code for pulse-height analysis accordingto console keyboard commands. This technique allows asingle program to adapt to many experimental situations ofarbitrary complexity, and to be changed during anexperiment. Details of the "data acquisition processor"are discussed. We also mention some shortcomings of theprogram in which this routine is imbedded, mainly in therealm of user interaction. Suggestions are made forfuture work to avoid past problems.

Introduction

This paper describes a portion of a computerprogram for data acquisition in a nuclear physicsresearch laboratory. Our technique -incrementally linking code modules which performspecialized tasks - is quite general, and may beuseful in a variety of other applications demandinga combination of high flexibility and highperformance. Much of the present paper is drawnfrom ref.1.

The paper firstly defines what a "data acquisitionprocessor" is, introduces the idea of such aprocessor which is the thesis of this paper, anddescribes the routine we have written in somedetail. At the end of the paper we give a critiqueof some areas where improvement is warranted in theprogram in which our routine is imbedded, andpresent our ideas for such improvement.

The KVI is a nuclear research laboratory, operatinga cyclotron providing particles of 160 q**2/A MeV(70 MeV protons). The data acquisition systemconsists of 3 Digital Equipment Corporation PDP-15computers, an 18-bit single-address machine with a

memory cycle time of 0.8 microseconds. Experimentstypically require several runs over 4-8 months,each run lasting from 1 to 5 days.

Prior to this work, the main data acquisitionprograms were implemented in FORTRAN with several"real-time extensions" in the form ofFORTRAN-callable assembly-language subroutines toprovide high-speed processing in time-criticalareas. The approach has been proven over severalyears by being easy to adapt to new experiments.In our experience, the drawback of this approach isthe proliferation of similar programs, and the fact

** L. M. TaffFermi National Accelerator LaboratoryBatavia, Illinois, U. S. A.

F. SporrelNuclear Accelerator Institute (KVI)University of Groningen, The Netherlands

that virtually every new experiment will require atleast some programming effort.

The goal of the present work was to developsoftware whose flexibility was high, yet givingcomplete run-time control of operation. A primarymotivation was to reduce unclear proliferation ofmultiple versions of one program. However, theflexibility and run-time specification of theprocessing algorithm has opened qualitatively newpossibilities in data acquisition complexity.

The means by which the flexibility is achieved isthe incremental compiling and linking of analysissubroutines at run time.

What is a Data Acquisition Proessor?

The data processing routine which we call the "dataacquisition processor" (dap) is shown from twopoints of view in figures 1 and 2. The internaloperation of a dap is the subject of this paper.

doFu Gnput dotaoquisTtlon hordwtre data acqulsition possohardware softwirellusr e

Figure 1. Global flow of data during processing.The role of the data acquisit ion processor togenerate appropriate output from data gathered bythe hardware is illustrated.

Figure 1 is the essence of the definition, as seen

from the input stream of data - the dap operates on

0018-9499/79/0800-4500$00.75 1979 IEEE4500

the raw data to produce the results the userdesires. Such results might be histograms, scatterplots on a display screen, and data on magnetictapes.

The main-program context within which our dap findsitself is shown in figure 2. It receives controlas part of a master polling loop when the dataacquisition hardware and interrupt-service softwarehave produced a full data buffer (many 'events").

4. Add base address of coincidence histogramto result 3 and increment correspondingmemory location.

5. Add base addressresult 1 andmemory location.

6. Add base addressresult 2 andmemory location.

of 64-bit histogram toincrement corresponding

of 32-bit histogram toincrement corresponding

The wording of the example suggests that thealgorithm might be implemented with subroutines(one for shifting, one for appending one descriptorto another, and one for incrementing histograms)called with appropriate arguments. In our system,in fact, every operation is carried out by asubroutine. The structure is that of a miniature,fast executive calling each in a series ofsubroutines. The keys to power and flexibility lierespectively in (i) the choices of operationsavailable in the subroutines, and (ii) the factthat the series is not specified at load time.Although the subroutines themselves are alwaysmemory resident, the series is filled in (thesubroutines incrementally linked and theirarguments compiled) only at run time in anarbitrary sequence. Therefore the same program maybe used in widely different experiments of varyingdegrees of complexity.

Figure 2. Typical main-program polling loop. Ondetection of a command, the command table issearched. If a match is found, a routinecorresponding to the command is called. If it isdesired to retain control when no commands arepresent, special measures are needed to input acommand from the console device so that control isnot lost to the executive while waiting for inputto terminate.

Control over the dap, as well as over theinterrupt-service software and data acquisitionhardware (CAMAC at the KVI - see ref.2), is throughkeyboard commands (e.g., "1ACUI1 for 'accumulate").

Basic Processor Structure

We consider a two-parameter counting experimentwhere an event consists of two 12-bit descriptors,e.g., from two 12-bit adc's. We wish to accumulatea two-parameter coincidence histogram of 32 * 64bins, and simultaneously gather the 32- and 64-binprojection histograms of each parameter. Theprocessing algorithm for such an event might be asfollows:

1. Shift descriptor 1 right 6 bits and saveresult.

2. Shift descriptor 2 right 7 bits and saveresult.

3. Append 6-bit result of step 1 to right of5-bit result of step 2 and save result.

Data Acquisition Processor

The dap is entered when the main program hasdetected that an input buffer has been filled. Onecomplete event is then extracted from the bufferand held in an internal "event array" forprocessing (see fig.3 - the unnumbered entries inarray III). The dap dispatcher is given controland it threads its way ("threaded code") throughthe series of subroutines (I).

get eventfromInput buffer

Uimot A iE-no urnz..subroultne A

pu

brute3r.donuelmet int hedata a isitio

address of a simple processing subroutine. Notethat more than one list element may call (point to )the same subroutine. Even though the samesubroutine is called from several places in theprocessing list, each call passes a uniqueparametser block .

4501

At each subroutine call, pointers are passed to theevent array and (II) to a block of parameters to beused by the called subroutine in its processing.Each time the subroutine list has been traversed anew event is extracted until the buffer isexhausted.

The parameter block includes the addresses in theevent array of the data to be operated on, theaddress to deposit its result, and constants to beused in its calculation (e.g., the number ofbit-positions to shift, or a digital offset abovewhich a histogram is to be stored). The eventarray contains not only the original input data,but has an entry (III) for the result of everysubroutine called. Thus a subroutine may make usenot only of hardware-acquired data, but of resultspreyiously calculated. We have arbitrarilyrestricted output to one word per subroutine,though there may be multiple inputs.

After the dap series of processing subroutines isspecified (linked), execution of any call may betemporarily suspended by replacing its entry in theseries with the address of a dummy (no operation)routine. The address removed from the series issaved in an additional list (IV) so it may berestored later.

Examples

To fix ideas, we describe a few of the keysubroutines. They are designed for single- andmulti-parameter pulse-height analysis.

1. Create a histogram bin number from adatum. Bin number = [datum - (digitaloffset)]/scale. The histogram length(always a power of 2) determines thescaling (always a shift operation).

2. Create a two-parameter bin number from twodata. To construct a 2-parameterdescriptor one applies subroutine 1) twiceand constructs the 2-parameter result fromthese numbers, as in steps 1, 2, and 3 ofour introductory example above. Thisroutine can be re-applied to its own

results with additional single or

multiple-parameter descriptors to producedescriptors for more than two parameters.

3. Increment a bin in a histogram residing inmemory or on a disk. Parameters includethe location of the bin descriptor in theresult array, and the histogram baseaddress. There are separate subroutinesfor incrementing memory- and disk-storedhistograms. Steps 4-6 of our example use

the memory version. Although the diskroutine is non-trivial (ref.3), itscalling sequence is identical to that formemory-stored spectra; complications dueto the need to read and write data on thedisk are transparent to the caller. The(fixed-head) disk has a capacity of 26214418-bit words, which can be divided as

desired, e.g., one 512 x 512 channelmatrix, or 64 4K histograms.

4. Test if a datum falls into a digital"gate" or "cut". The gate number isreturned if the datum falls within a gate;if not, a code indicates this fact.

We are not gate-checking by maintaininglists of lower and upper gate limits,testing each datum by successivesubtractions. We use instead a tablelook-up. A table or "gate histogram' , ofthe same length as the histogramcorresponding to the descriptor to begated contains either a gate number or anot-in-gate code in each of its various"bins". When a datum is to be tested onemerely looks in the corresponding bin inthe proper gate histogram to find the gatenumber. Though this method requiresmemory space for gate histograms, it isfast, with a constant execution time forall channels even with very many gates.

5. "Branch' over one or more followingoperations if a specified gate testfailed. If the 'not-in-gatel" code isfound, the routine increments its returnaddress such that a number of followingoperations is skipped.

This subroutine implements decision-makingcapability, and adds qualitatively newpower to standard data-acquisitionfunctions. It could be used, for example,to treat various particles differentlyafter particle identification, or simplyto quickly skip an uninteresting event.

6. Add two data together. This is useful inparticle-telescope work where the totalenergy is lost in multiple detectors.

Da.l Subroutines

We have chosen the specific detailed design of theprocessing subroutines, their calling sequences,argument blocks, etc., to optimize performancewhile conserving memory; they are notFORTRAN-callable. We expect rate limitations tolie in these processing subroutines for mostcounting experiments. These assembly-languagecoded routines and their calling sequences can behighly machine-dependent, taking full advantage ofany special features of the hardware, such as indexregisters, autoincrementing, fixed andfloating-point arithmetic hardware, microcoding ofinstructions, etc. In our implementation thesubroutines are "pure' in nature, with impure datasuch as absolute addresses, bit-shift-counts, etc.,being contained in the parameter block passed tothem. This saves reproducing multiple copies ofthe pure code at the expense of a few extra memorycycles for indirect references. In some cases itmight be worthwhile to compile combined code/datablocks to improve speed. It would then be only a

minor step to replace threaded code with in-linecode.

4502

Installing a subroutine

When a subroutine is to be added to the dapprocessing series, a corresponding command is typedat control console keyboard. The setup routine forthe desired process obtains the parameters it needsvia keyboard conversation. It sets up a parameterblock (obtained from a simple software memorymanager) for the processing subroutine, and obtainsthe memory address of this block (needed forabsolute address binding) via a smallassembly-language routine. Then an "add a process"primitive of the dap is called to append theabsolute addresses of the processing subroutine andparameter block to the ends of the current seriesin pre-allocated arrays (I) and (II). The processnumber is returned by the dap to use in setting theparameters of the parameter block, and is reportedto the user on the console teleprinter.

ExDerience with the Program

Performance

We have measured rates for single-parameterpulse-height-analysis. It is difficult to givemeaningful performance figures for more complexprocessing algorithms.

The counting of one single-parameter spectrum hasbeen measured at about 9500/sec. The 105microseconds per event can be divided into: Ci)fetching and identifying the event (36 microsec),(ii) constructing a histogram bin number (27),(iii) incrementing a histogram bin (21), (iv)subroutine linkage overhead (5.6 microsec/process x2 processes = 11 microsec), and (v) generaloverhead of the main-program loop,interrupt-service register saving and restoration,etc. The total of steps (i)-(iv) is about 95microseconds, so we conclude about 10microseconds/word is spent on general overheadexternal to the dap. This includes transfersthrough the PDP-15 "data-channel" hardware (3memory cycles per word and associated I/O bussynchronization). The rather long "fetch" stepinvolves identifying which of eight adc's wasdigitized, insuring that a valid coincidence wasregistered, checking that the adc's were digitizedin the proper order, and seeing that the datum isvalid (non-zero). Similarly, step (ii) subtracts adigital bias from a datum, guarantees the result iswithin a digital window, and scales it to fit thelength of the desired histogram. In some systemsthese functions may be carried out by the hardware,or simply not done at all. We note that theoverhead price for using threaded coded rather thanin-line increases the time spent in actualprocessing routines by about 20%.

We have also measured the rate achieved by theroutine of Snyder (ref.3) which we have adopted forupdating spectra kept on an fixed-head disk. Inour test a 512 x 512 matrix (i.e., 262144 totalbins) was updated at an average rate of about 350events/sec, in agreement with an analysis of thealgorithm for the sorting buffer sizes we utilized(see appendix, ref.1).

Usage

The original implementation of the program asdescribed has been employed for about three yearsin experiments with heavy ions, in gamma-gammacoincidence measurements, in measurements ofcoincidences between gamma- and x-rays, and betweengamma-rays and conversion electrons. A nearlyidentical version of the data-acquisition programis available for analyzing data on magnetic tape.

In general the flexibility of this program is suchthat there has not been a request which could notbe implemented. To this extent our goal - oneprogram to take the place of many - has beenreached.

Critique

As mentioned in ref.1, there are four problem areasin our first release of the software. All concernthe interaction of the user with the system, andnot our dap itself. Firstly, there does not yetexist a mechanism to obtain a complete overview ofhow real-time processing is set up at any givenmoment (except for hard-copy teleprinter output).It turns out such an overview is highly desirable;Tippie and Kulaga (ref.4) also reportdissatisfaction with this aspect of their ownsystem.

Secondly, once set up, the list of processingsubroutines cannot be changed without a completelynew setup. This is because absolute memoryreferences have been bound.

Thirdly, we have not yet implemented a way torecord a particular software setup so it may beeasily re-loaded into the program from massstorage. This would be useful if the system fails,or if it is desired to temporarily run anotherprogram and return later to data-taking.

These inconveniences can be overcome by alteringthe procedure whereby each command to install aprocessing routine is executed immediately.Instead, relevant arguments can be written to anexternal file in text form. When data acquisitionis to begin, the entire collection of such commandscan be "compiled" at once - either by a separate"compile" command, or automatically when dataacquisition is started. The parameters specifiedby the user would then always be available in theiroriginal form for a status overview. In addition,the processing specifications, being in text form,could be edited or extended easily, and finally,the setup would automatically be retained forsubsequent use in other runs or experiments.

The fourth problem area relates to the actualentering of a dap procedure at the keyboard. Wechose a conversational interaction based onprompting to avoid the confusion of order-dependentarguments. As a result, the setup procedure isrelatively time-consuming, since the highflexibility requires specification of arguments inconsiderable detail. Our intention is to reducethe use of prompting, and to implement acommand-line interpreter. An ideal design would beboth easy to for the novice to learn and use, yet

4503

could be operated quickly by the more experienced.

We are presently considering a scheme based onkeywords. A hypothetical example to make an 8-inchplot of 1024-bin histogram number 2 on anincremental plotter might be:

PLOT HIST=2,FROM=256,TO=1024,BASELINE=O,UPPER=1000,VERTICAL=8

Any keywords not specified in a command line wouldtake on default values, which may or may not be"sticky" (take the last value entered). Our PLOTcommand might be simplified to:

PLOT HIST=2,FROM=256,UPPER=1000,VERTICAL=8

The tables of keywords and defaults might beprinted in response to a "HELP" command. Theywould also be useful to prompt if a command isentered without a keyword which cannot bedefaulted.

Only as many letters should be required of thekeyword as are needed to specify it uniquely.Then, by choosing keywords for each command withcare, entering one letter per keyword could besufficient. Our example would become:

PLOT H=2,F=256,U=1000,V=8

Operating convenience could be increased further byallowing several characters to function asalternative argument separators and fielddelimiters - especially those characters notrequiring use of a shift key when typing. It mightbe feasible to also allow transitions fromalphabetic to numeric or vicg versa to function asseparators. Then we could have:

PLOT H 2,F 256,U 1000,V 8

or

PLOT H 2 F 256 U 1000 V 8

This last shortcut could not be used on keywordswhich either do not take an assignment (e.g.,"LINEAR" or "LOG") , or whose assigned value is analphabetic literal like 'ON"t or "OFF". Onealternative would be to enclose literals in quotesor to precede them with some special flagcharacter.

Future D-irections

We believe the basic technique of incrementallinking of application-oriented code modules yieldshigh flexibility and performance. Developmentefforts are directed toward the points in theprevious section, namely, a smoother interactionwith the user.

Acknowledgments

Part of this work was performed as part of theresearch program of the "Stichting voorFundamenteel Onderzoek der Materie" (FOM) withfinancial support from the "Nederlandse Organisatievoor Zuiver Wetenschappelijk Onderzoek" (ZWO); thework was also partially supported by the UnitedStates Department of Energy.

Refgrences

1. L. M. Taff and F. Sporrel, FlexibleReal-Time Nuclear Data AcquisitionProcessing Software, Nucl. Instr. andMeth., Vol.160, no. 1, 147-158, March,1979.

2. L. M. Taff, Two-LevelSoftware, Computer Phys.271-281, 1975.

3. F. Snyder, DigitalUser's Societycontribution 15-96.

CAMAC HandlerCommun., Vol.9,

Equipment CoMputer(DECUS) library

or even

PLOT H2F256U 1000V8

4. J. W. Tippie and J. E. Kulaga, A CommandLanguage Based Data-Acquisition andAnalysis System for Low Energy Physics,IEEE Trans. Nucl. Sci., Vol.NS-24, No.1,492-496, February, 1977.

4504