Homework Set #10
Using your YAK kernel code from lab 6, make the measurements described
below using whatever tools are most convenient. To simplify, assume
that the application code running is that from lab 6. (For the
measurements relating to semaphores, assume that the lab 5 application
code is running.) This constrains such factors as worst-case
interrupt nesting, number of tasks, and number of semaphores, ensuring
that we're actually measuring the same things. (With these
assumptions in mind, please report raw numbers, not expressions that
include any sort of variables.)
- All measurements except the last three are in terms of
machine instructions on the target platform.
- You should spend less than two hours on this assignment.
- For each answer, explain briefly how it was determined.
- You should be able to defend the accuracy of your reported
- You may work with your lab partner and you only need to submit one
copy of the assignment for both partners. Make sure both names are on
the assignment then submit your results to the HW
TA via email.
- Longest critical section. The maximum number of
consecutive instructions your kernel ever executes with interrupts
disabled. Don't count initialization code that runs before YKRun and
ignore YKNewTask. (Let's limit our attention to code likely to run in
- Worst case interrupt latency. The maximum number of
instructions your kernel could execute from the time an interrupt is
asserted until the execution of the first instruction of the interrupt
handler (not the ISR but the C routine it calls). To simplify, assume
that we are concerned with the level i interrupt, that
interrupts at level i are enabled, and that no higher priority
interrupts take place from the time interrupt i is asserted
until its interrupt handler begins execution. (In other words, ignore
interrupt nesting for this measurement.) This does not imply
that interrupts are enabled (i.e., that IF in the flag register is set
at the time of the interrupt. This measurement is therefore the
longest critical section above plus the length of your longest ISR (to
the point of calling the handler). For consistency, don't include the
first instruction of the handler in your answer, just the instructions
to that point.
- Overhead to post to a semaphore. The maximum number of
instructions that could be executed from the call to YKSemPost until
it returns, assuming that no task is made ready and that no context
switch takes place. (Start counting immediately after the call
instruction and stop counting with the return instruction at the end
of YKSemPost.) Assume no interrupts occur and that lab 5 application
code is running.
- Overhead to pend on a semaphore. The maximum number of
instructions that could be executed from the call to YKSemPend until
it returns, assuming that the semaphore is available at the time of
the call. (Start counting immediately after the call instruction and
stop counting with the return instruction at the end of YKSemPend.)
Assume no interrupts occur and that lab 5 application code is running.
- Overhead to switch contexts with YKDelayTask. The maximum
number of instructions that must be executed from the call to
YKDelayTask until the first instruction of the newly dispatched task
executes. (Start counting after the call instruction and stop
counting with the first instruction of the new task.) Assume no
- Size of YAK C source code. Simply give the line count in
all the .c and .h files for your kernel. (This should include your
interrupt handlers if written in C, but not the application code.)
This admittedly isn't a terribly meaningful measure (or the sort of
thing you want to maximize or minimize) but it is interesting to
compare. You can use the wc command in Unix to count lines; note that
it can handle wildcards and multiple filenames.
- Size of YAK assembly source code. Simply count the lines
of code in all your .s files that you wrote by hand (that were not
automatically generated from C files). Do not include clib.s in your
total. Make sure all kernel files are counted in this or the previous
count as appropriate.
- Amount of memory required in bytes. This is the amount
of RAM and ROM required in a system to hold both the application code
and your kernel. (This is easily obtained from the size of the .bin
FOR THIS ASSIGNMENT ONLY, submit your
solutions to all of the above via email to the HW TA before midnight on
the due date. One submission per team is sufficient, but be sure to
identify both team members in your email.
Last updated 29 August 2016
James Archibald firstname.lastname@example.org