TABLE OF CONTENTS SECTION TITLE PAGE

HARD REAL-TIME OPERATING SYSTEMKERNEL STUDYTASK8,Volume BTESTING OF MODIFICATIONS TO YORK ADAAndrew HutcheonYork Software Engineering Limited,UK25th September1992AbstractThis document describes the testing of modifications made to the York Ada Compiler and York Ada Run-Time System to implement the features described in Appendix A of the Task5deliverable,Design of the Hard Real-Time Kernel[1].ESTEC/Contract No.9198/90/NL/SFESTEC TECHNICAL MANAGER:Mr F.Gomez-Molinero©York Software Engineering Limited,1992TABLE OF CONTENTSSECTION TITLE PAGE 1INTRODUCTION12LARGE PRIORITY RANGE1 2.1YAM01A1 2.2YAM01B2 2.3YAM01C23PRIORITY QUEUING3 3.1YAM02A3 3.2YAM02B34PACKAGE CALENDAR45PROTECTED TASKS4 5.1YAM04A4 5.2YAM04B5 5.3YAM04C6 5.4YAM04D7 5.5YAM04E86DELAY UNTIL9 6.1YAM05A9 7BUDGET TIMING9 7.1YAM06A9 7.2YAM06B10 7.3YAM06C10 7.4YAM06D10 7.5YAM06E11 7.6YAM06F11 8PERIOD TRANSFORMATIONS12 8.1YAM07A12 8.2YAM07B13 8.3YAM07C13 8.4YAM07D149USER INTERRUPT HANDLERS14 9.1YAM08A14 9.2YAM08B15 10FAST USER INTERRUPT HANDLERS15 10.1YAM09A15 10.2YAM09B16REFERENCES17 A TEST SOURCE CODE181.INTRODUCTIONThis document describes the testing undertaken on the modifications to York Ada which are outlined in;[2]the reader is expected to be familiar with these modifications.Each amendment is covered in sequence,and the one or more tests performed are discussed. The style of presentation is the same in each case:the purpose of each test is described;a brief description of the test is given;the results obtained by executing the test are presented.Note the results that are presented are what you would see if the test was rerun, within the constraints of any nondeterminism exhibited by the test code.Appendix A at the end of this document contains the Ada source code for each of the test programs.This source text will also be supplied in machine readable form as part of the delivered system.RGE PRIORITY RANGE(Amendment Request01)2.1.Test Purpose:YAM01AThis test demonstrates the correct operation of the extension of the priority range to0.63in package SYSTEM.2.1.1.Test DescriptionThe test creates a number of tasks of different priority levels in order to illustrate that priorities throughout the extended range behave correctly.The number of tasks is limited to maintain legibility of the output,but the test has been repeated with various assortments of priority levels in order to increase confidence that the priority range behaves as expected.The code consists of seven tasks which print an identification of themselves while executing;each task has a different priority level.2.1.2.Test ResultsThe program,when executed,produces output which shows the high priority tasks return-ing to a runnable state after delays and pre-empting the executing lower priority task.This is illustrated by the sample output trace:333344444444444444444444444444444455555555555555555555555544444444446666666222222This fragment of output shows task t4being pre-empted by t5.A continuous output trace of this form is produced.2.2.Test Purpose:YAM01BThis test shows that passive task priorities above63also disable hardware interrupts to the level given by priority minus63.2.2.1.Test DescriptionThe program is a variant of the simple interrupt test,yam08a,with an additional passive task which has a priority high enough to mask out the interrupt source.Each time the entry provided by this passive task is called,it busy waits by calling a procedure containing a loop,and so masks out interrupts for a period of time.Interrupts are unmasked,and can be reacted to again,when the passive task rendezvous completes.2.2.2.Test ResultsA trace of the following form is produced,with the rate at which i’s are written depending upon the interrupt rate,and a delay of several seconds each time the word"blocking"is printed before the stream of i’s recommences. iiiiiiiiiiiiiiiiiiblockingiiiiiiiiiiiiiiiiiiiblockingiiiiiiiiiiiiiiiiiiblockingiiiiiiiiiiiiiiiiiiiblockingiiiii2.3.Test Purpose:YAM01CThis is a repeat of test YAM01B,using a user procedure interrupt handler rather than a protected task entry.Behaviour is the same whether or not the-Fflag is used to Ac to dis-ablefloating point coprocessor state save around interrupt handling.This test is the same as YAM01B except for the change to interrupt handling mechanism.2.3.2.Test ResultsThe test output is the same as that for YAM01B.3.PRIORITY QUEUING(Amendment Request02)3.1.Test Purpose:YAM02AThis test shows the correct operation of priority ordering of entry queues.3.1.1.Test DescriptionThe test consists of a number of tasks with different periods and priorities and a server with single entry which they all call.The server accepts all calls queued on its entry and then performs a delay before repeating the process.The delay periods are arranged so that tasks will not always make entry calls in priority order.The server prints the identity of the task it is serving when it accepts an entry.3.1.2.Test ResultsWhenever the queue is cleared,tasks are served in high to low priority order.After an ini-tial delay,calling task numbers are printed in the order in which they are accepted.A sam-ple output trace is:321020210320210320This form of output trace continues while the program runs,with each line always consist-ing of descending numbers.3.2.Test Purpose:YAM02BThis test shows the correct operation of priority acceptance of open select alternatives.The test consists of a number of tasks with different periods and priorities and a server which presents several entries accepted within a select statement.Each accept statement in the select prints the identity of the accepted task.If no tasks are queued on entries,the server performs a delay to allow tasks to become queued and then repeats the process.3.2.2.Test ResultsWhenever more than one branch of the server select statement has a task queued on the entry,the highest priority task is accepted.After an initial delay,calling task numbers are printed in the order in which they are accepted.A sample output trace is:321020210320210320This form of output trace continues while the program runs,with each line always consist-ing of descending numbers.4.PACKAGE CALENDAR(Amendment Request03)Package CALENDAR has not been tested in isolation,as it is felt that the use of these facilities in the testing of delay_until(amendment request05)and period transformation (amendment request07)is sufficient to demonstrate correctness.5.PROTECTED TASKS(Amendment Request04)5.1.Test Purpose:YAM04ATo demonstrate the operation of protected tasks and the use of guards to open and close protected task entries.5.1.1.Test DescriptionThree tasks of different priorities each attempt to call each of the three entries of a pro-tected task in sequence.Guard conditions cause each task in turn to be accepted by each entry of the protected task in turn,where without the guards each task would make all of its entry calls in priority order before the next was able to run.5.1.2.Test ResultsThe test output is the trace:1111231365.2.Test Purpose:YAM04BThis test demonstrates the propagation of exceptions from protected tasks.5.2.1.Test DescriptionAn array of ten tasks is created,and each of these calls an entry of a protected record which calls a procedure which performs a divide by zero and so raises CONSTRAINT_ERROR.The calling task catches the exception and prints a message. 5.2.2.Test ResultsThe test output is the trace:6000exception caught in calling task10006000exception caught in calling task10006000exception caught in calling task10006000exception caught in calling task10006000exception caught in calling task10006000exception caught in calling task10006000exception caught in calling task10006000exception caught in calling task10006000exception caught in calling task10006000exception caught in calling task10005.3.Test Purpose:YAM04CThis test demonstrates that period transformation affects the base priority of a task,but not the active priority inherited as a result of calling a protected task.5.3.1.Test DescriptionA pair of tasks,one period transformed between a high and low priority and the other at a medium priority,compete for the processor.This results in output alternating between the two tasks as the period transformation raises and lowers the priority of thefirst task.How-ever,when thefirst task calls a protected task and so inherits that task’s(higher)priority as its active priority,output is produced solely as a result of the protected task call until that completes.5.3.2.Test ResultsThe output starts as a stream of the character"2",then alternates between three lines each of"1"and"2",then prints a stream of"f",andfinally reverts to a stream of"2"before ter-minating.5.4.Test Purpose:YAM04DThis test demonstrates that pragma protected causes an optimisation which avoids the need for context switches when a rendezvous is made with a passive task.5.4.1.Test DescriptionFour tasks are queued on the entries of a passive server task,whose entry guards are unblocked by the rendezvous performed by the last task.This last task then performs all outstanding rendezvous on behalf of the queued tasks.In order to demonstrate that this is happening,calls are made to a routine which prints the identity of the task currently being executed by the runtime system.5.4.2.Test ResultsWith the server task marked by pragma passive,all entries are handled with the current task identity t4,showing that the passive task is not context switched to and that t4 executes the pending rendezvous before it leaves the passive task.t1thistask:a0act2thistask:c19ct3thistask:e28ct4thistask:1037ce4thistask:1037ce3thistask:1037ce2thistask:1037ce1thistask:1037ct1endt2endt3endt4endWhen the pragma passive is removed,the server task is created and runs as a separate task to handle each rendezvous,as shown by the additional task identifier in the trace below:t1thistask:c3bct2thistask:e4act3thistask:1059ct4thistask:1268ce4thistask:a2cce3thistask:a2cce2thistask:a2cce1thistask:a2cct1endt2endt3endt4end5.5.Test Purpose:YAM04EThis test shows that the exception PROGRAM_ERROR is raised when a task calls a passive task which does not have a higher priority than the calling task.5.5.1.Test DescriptionThis test is a modified version of YAM04D,with the priority of the server passive task lowered to that of the highest priority calling task,and the calls to the runtime system to print task identities removed.5.5.2.Test ResultsTask t1,the highest priority caller,suffers and catches PROGRAM_ERROR when it attempts to call the server passive task,while the remaining tasks perform their rendezvous successfully.t1t1got program_errort2t3t4e4e3e2t2endt3endt4end6.DELAY UNTIL(Amendment Request05)6.1.Test Purpose:YAM05AThis test demonstrates that the DELAY_UNTIL(TIME)procedure call has the correct tim-ing properties.6.1.1.Test DescriptionThe main procedure loops indefinitely.Each loop iteration delays until a time5.0seconds in the future,the prints a message.Initial loop entry is causes a delay to a time in the past, demonstrating that such requests do not cause any delay to be experienced.6.1.2.Test ResultsThe program waitsfive seconds,produces two messages together,then settles down to writing the line:i’m still hereevery 5.0seconds.This timing can be checked with an external timer,such as a stopwatch.7.BUDGET TIMING(Amendment Request06)7.1.Test Purpose:YAM06AThis test verifies that the processor budget timing mechanism works,and that it raises the BUDGET_OVERRUN exception after the requested time period.It also shows that CANCEL_BUDGET can safely be applied to the null budget_id and the budget_id of an expired budget.7.1.1.Test DescriptionThe main procedure sets a budget of(for example)60.0seconds,then enters an infinite loop.When the budget expires,the resulting exception is handled and a message printed. CANCEL_BUDGET is then applied to the expired budget_id and to the null budget_id. The parameter to SET_BUDGET can be modified and the test recompiled to vary the time period before the exception occurs.7.1.2.Test ResultsWhen the execution time budget is exhausted,the messagealarm call!is printed.Correct time behaviour can be verified externally timing from program start to the appearance of the message,which should give the time set for the execution budget(in the example as given,60seconds).7.2.Test Purpose:YAM06BDemonstration of the correct operation of nested execution budgets and the last_overrun function call.7.2.1.Test DescriptionThe main procedure sets a budget,then calls an inner procedure which also sets a budget but does not handle any resulting exception.If the inner budget is shorter than the execu-tion time of the inner procedure then the main procedure catches BUDGET_OVERRUN and LAST_OVERRUN returns INNER_ID as it was the budget in the called procedure which expired,otherwise LAST_OVERRUN returns MY_ID as the called procedure com-pleted and cancelled its budget.7.2.2.Test ResultsAs currently configured,the program printsInnerto indicate that the inner budget expired.Changing the length of the inner budget to,for example,10.0seconds allows the inner procedure to complete and results inMinebeing printed instead.7.3.Test Purpose:YAM06CThis test demonstrates the minimum time required for a budget to return a valid identifier.7.3.1.Test DescriptionA very short budget is set,and the associated exception handler attempts to identify it using LAST_OVERRUN.If the budget expired before the budget_id was assigned from the function result,then the comparison in the exception handler fails.7.3.2.Test ResultsWith a budget time of0.000020s,the test printsMinewhereas with a time of0.000016s(NB.the timer has a resolution of0.000004s)produces Other?Assigning the budget_id to a component of a complex record structure involving resolving access values required0.000024s.7.4.Test Purpose:YAM06DThis test demonstrates the correct operation of LAST_OVERRUN when multiple tasks have budgets expire.7.4.1.Test DescriptionBoth the main procedure and a high priority task loop and catch budget overruns,each time verifying that the budget_id returned by last_overrun is the expected one.7.4.2.Test ResultsEach BUDGET_OVERRUN exception causes an identifying character to be printed ifLAST_OVERRUN returns the correct budget_id,otherwise an error message is produced.The resulting output trace is: mmmsmmmmsmmmmsmmmmsmmmmsmmmmsmmmmsmmmmsmmmmsmmmmsmm7.5.Test Purpose:YAM06EDemonstration of the use of multiple tasks with execution budgets.7.5.1.Test DescriptionThe test consists of a set offive harmonic tasks,taken from the Hartstone benchmarks[3].Each task has afixed execution budget per period,and gradually increases its processingload per period until it exhausts its budget.7.5.2.Test ResultsThe tasks print an identifying string each time they execute,and a report message whenthey exhaust their budget.The resulting trace is:54433322221111155445533344554455333222244555445333544554453335222211111445544553 33445554453332222544554453335445544533322225111114455544333554455443335222254455 44533354455544333222251111154455443335544553334452222544553335445544533354422225 11111544553334455445533322225445544533354455445333522224451111154453335544554433 35222254455445333544554453335222211544111554433355445544333552222445533344555445 33354452222544511111533344554455333445222525445333544t4budget overru5nt3budget overrun552222555111115555552222555555552222115111555555522225t5budget overrun222211111t1budget overrun 22222222222222222222222222222222222222222222222222222222222222222222222222222222 22222222222222222222222222222222222222222222222222222222222222222222222222222222 t2budget overrun7.6.Test Purpose:YAM06FThis test demonstrates the TIME_LEFT function used to obtain the remaining executionbudget available,and the raising of the BUDGET_ERROR exception as a result of misuses of the budget timing facilities.7.6.1.Test DescriptionThe main program sets a budget,the calls a procedure which attempts to set a longer budget.After catching the resulting BUDGET_ERROR,a loop prints out the remaining budget time ten times,with nested delaying loop.The budget is then cancelled twice, showing that it is a null operation to cancel a cancelled budget,and an attempt made to obtain the remaining budget time.Again,the resulting BUDGET_ERROR is caught and a message printed.7.6.2.Test ResultsA typical output trace is:budget_error calling do_proc9.96952000009.60593600009.24417600008.88235200008.52051200008.15873200007.79692800007.43511600007.07326000006.7114280000cancelled twicebudget_error in main8.PERIOD TRANSFORMATIONS(Amendment Request07)8.1.Test Purpose:YAM07AThis tests demonstrates that the priority of a period-transformed task is lowered once it exhausts its high priority execution time,and that period transformation and execution budgets work together.8.1.1.Test DescriptionA period-transformed task executes a nested pair of loops,with the inner loop becoming longer with each iteration of the outer loop.A second task has a priority which is lower than the high priority of the transformed task,but higher than the low priority of the transformed task.Messages printed by both tasks indicate whether the transformed task completed its inner loop before or after its priority was reduced and the other task conse-quently became able to execute.Eventually,the transformed task overruns its execution time budget and so demonstrates that execution budgets and period transformation work together.8.1.2.Test ResultsThe program output follows this form:transformer ended loopt2activetransformer ended loopt2activetransformer ended loopt2activetransformer ent2activeded loopt2activetransformer ended loopt2activetransformer ended loopoverrun in t1Messages output before the switch in order,and before thefinal overrun,have been abbre-viated to save space.8.2.Test Purpose:YAM07BThis test shows that the priority of a transformed task is both lowered and raised correctly.8.2.1.Test DescriptionA pair of tasks,one transformed between high and low priority,the otherfixed at medium priority,compete for the processor.Characters are output to indicate which task is execut-ing,and this output can be observed to verify correct behaviour.8.2.2.Test ResultsThe program commences with T2outputting a stream of the character"2".When T1starts to run,the output alternates every0.5second between streams of"1"and"2",as period transformation lowers and raises T1’s priority.Each time T1iterates round its outer loop, the sequence"@@@@@"is printed and a stream of"2"’s output until T1completes a delay statement and the alternating"1"and"2"streams restart.8.3.Test Purpose:YAM07CThis test demonstrates correct operation of period transformation as the high priority exe-cution time is varied.8.3.1.Test DescriptionAs for YAM07B,but with the high priority time of the transformed task starting as0.75s and reduced by0.25s with each iteration of its outer loop.8.3.2.Test ResultsAs for YAM07B,but with the alternating output stream varying as high priority time varies until T1no longer has any high priority time and the output becomes a stream of "2"’s.8.4.Test Purpose:YAM07DThis test demonstrates the operation of multiple tasks with period transformation,and shows the use of period transformation to modify the order in which deadlines are missedfrom that which would be expected as a result of the task periods.8.4.1.Test DescriptionThe test consists of a set offive harmonic tasks,taken from the Hartstone benchmarks[3].These are accompanied by a high priority STRESSOR task which gradually consumesmore and more of the processor time.As a result,tasks begin to miss their deadlines.Theorder in which deadlines are missed can be altered by appropriate priority assignments and accompanying period transformations in tasks.8.4.2.Test ResultsThe program is currently configured to miss deadlines in the order T3,T4,T1,T5,T2.This is confirmed by the trace of missed deadline notifications below,which is given up tothe point at which T2begins to miss its deadline.Note that the exact output is likely tovary slightly due to nondeterminism in execution.3333443333334433344443333434434443333343 4434434434434443443444434434434434444444 4344344344344344344444444444444344444434 1434341444444444444444344445444444544444 4434444444444444444444344444444444444434 4344344355443443554554314444444444444344 4444544444454444445444445355554345545535 4435455455354545345554535441354554535555 4555435545435555455541354554535555545555 1435455345555545513455453545545555553455 4553455545555515355545555555555554555555 3555554555555554525355454534552413455435ER INTERRUPT HANDLERS(Additional Amendment Request)9.1.Test Purpose:YAM08AThis test demonstrates a simple Ada programming handling interrupts from an external source.9.1.1.Test DescriptionThe programfirst configures the PIT device(further details in hardware manual and manufacturer’s datasheet)to provide interrupts when a signal is applied to the H1 handshake line.This signal is provided by a function generator with a variable output fre-quency.Interrupts are handled by a passive task,which accepts an entry call from anothertask after every1000interrupts.This second task,when released,prints a message to indi-cate that the requisite number of interrupts have been handled.9.1.2.Test ResultsThe program outputs an stream of the character i at a rate proportional to the interruptrate provided by the external function generator.For example,due to the interrupt count-ing performed by the program,an interrupt rate of50Hz results in the output of one i per second.At an interrupt rate slightly greater than3000Hz,the time spent handling interrupts leavesno time for execution of user code.As a result,output ceases to appear,but returns if the interrupt rate is lowered.9.2.Test Purpose:YAM08BThis test shows user interrupt handling in Ada operating in conjunction with a programwhich performs other activities.9.2.1.Test DescriptionThe test is a variant of YAM07D,with the STRESSOR task released by a user interrupt handler rather than executing periodically.The other tasks in the system can be made tomiss deadlines by increasing the interrupt rate applied to the system,and so increasing therate at which STRESSOR is released and executes.9.2.2.Test ResultsThe results are similar to those from YAM07D,but vary with interrupt rate rather thanmore deadlines being missed as the program runs for longer.An example output is:3333333443334344344344444435454344344344 4434445444454455453555455435443444444544 1453444454444545553455555455525234555555 5455553455413445354434555453545555415354 5555545354555555545355545543555455555552 5145352554555555555345555545555555553455 5554553455455555515354555555555545555535 4555425553555455555555545555535555455555 5555421535452545354555555455355555545555 5555554553555555545555555525145355555554 5552453555455555555553455555555455555555 3455555555554555525153545555552554555555 3545555555455553552455555455553545555555 455153555455554555355545555545535555455510.FAST USER INTERRUPT HANDLERS(Additional Amendment Request)10.1.Test Purpose:YAM09AThis test demonstrates a simple Ada programming handling interrupts from an external source with a procedure interrupt handler.Behaviour is the same whether or not the-Fflag is used to Ac to disablefloating point coprocessor state save around interrupt handling.10.1.1.Test DescriptionThe test is as for YAM08A,but using a procedure interrupt handler rather than a protectedtask entry.10.1.2.Test ResultsThe program outputs an stream of the character i at a rate proportional to the interruptrate provided by the external function generator.For example,due to the interrupt count-ing performed by the program,an interrupt rate of50Hz results in the output of one i per second.At an interrupt rate of about13000Hz,the time spent handling interrupts leaves no time for execution of user code.As a result,output ceases to appear,but returns if the interrupt rateis lowered.10.2.Test Purpose:YAM09BThis test shows user procedure interrupt handling in Ada operating in conjunction with a program which performs other activities.Behaviour is the same whether or not the-Fflagis used to Ac to disablefloating point coprocessor state save around interrupt handling.10.2.1.Test DescriptionThe test is similar to YAM08B,using the procedure interrupt handling mechanism.10.2.2.Test ResultsThe results are similar to those from YAM08B.An example output is:3333333333343334343333433334334433343443 4434433333433443443443444344344343434434 4443344344344443444344344344434444434444 3434444344434444344443444413443443443414 3443443434444534545453454545453454545345 4513454545453454545345454545345451345454 5345454534545454534545451453454545345454 5453454545345454545134545454534545453454 5454535455245135455453545552453545545354 5525134554553455455253455455345545251345 5455354554525345545535455451235455453545 5524535455453545551234554554535455253455 4553455455251345545534554525345554535455REFERENCES1. A.Burns and A.J.Wellings,‘‘Design of Hard Real-Time Kernel’’,Task5Deliver-able on ESTEC Contract9198/90/NL/SF,Department of Computer Science, University of York(September1991).2.J.R.Firth,‘‘Modifications to York Ada’’,Task8(Volume A)Deliverable onESTEC Contract9198/90/NL/SF,York Software Engineering Limited(March 1992).3.N.Weiderman,‘‘Hartstone:Synthetic Benchmark Requirements for Hard Real-Time Applications’’,CMU/SEI-89-TR-23,Software Engineering Institute,Carne-gie Mellon University(June1989).APPENDIX A:TEST SOURCE CODELarge priority rangeYAM01Awith SYSTEM;with BASIC_IO;procedure MAIN istask T6ispragma PRIORITY(63);end T6;task T5ispragma PRIORITY(16);end T5;task T4ispragma PRIORITY(8);end T4;task T3ispragma PRIORITY(4);end T3;task T2ispragma PRIORITY(2);end T2;task T1ispragma PRIORITY(1);end T1;task T0isend T0;task body T6isROUND_COUNT:INTEGER:=0;begindelay0.4;loopfor I in1..10loopROUND_COUNT:=ROUND_COUNT+1;if ROUND_COUNT>4thenBASIC_IO.PRINT("6666666");BASIC_IO.NEWLINE;ROUND_COUNT:=0;end if;end loop;delay10.0;end loop;end T6;task body T5isROUND_COUNT:INTEGER:=0;begindelay0.35;loopfor I in1..100loopROUND_COUNT:=ROUND_COUNT+1;if ROUND_COUNT>20thenBASIC_IO.PRINT("555555");BASIC_IO.NEWLINE;ROUND_COUNT:=0;end if;end loop;delay 5.0;end loop;end T5;task body T4isROUND_COUNT:INTEGER:=0;begindelay0.3;loopfor I in1..1000loopROUND_COUNT:=ROUND_COUNT+1;if ROUND_COUNT>100thenBASIC_IO.PRINT("44444");BASIC_IO.NEWLINE;ROUND_COUNT:=0;end if;end loop;delay 2.5;end loop;end T4;task body T3isROUND_COUNT:INTEGER:=0;begindelay0.25;。