R. Clayton (rclayton@monmouth.edu)
Mon, 23 Oct 2000 11:08:42 -0400 (EDT)
It seems that the idle time shown in your results is always same as the Op-code
1 counts. You also said that Op-code 1 is the ADD instruction, and Op-code 13
is NOOP. But idle time to me is NOOP, so do I miss something here?
Possibly, although if you haven't done a lot of assembly programming, I
wouldn't expect you to get it right off. The problem with noop idle
programs is that the idle time is proportional to the length of the program;
an n noop program gives an n cycle idle. Because the idle process can run
for an arbitrary number of cycles, the noop program would have to be
arbitrarily long, which would be a difficult program to write
Fortunately, it's easy to simulate an arbitrarily long noop program with a
program of definite length using loops:
idle: noop
br idle
Once you do that, the next step is easy: get rid of the noop to get
idle: br idle
The motivation for shortening the idle program is laziness; I had to hand
assemble the idle program, so the shorter it was, the less work for me.
The final step is to get rid of the br instruction. The problem is not so
much with the br but with the labels it requires. In general, assembling
labels, while not hard, does take some work and attention to detail, which
are better off avoided if possible. Fortunately, it is possible by directly
manipulating the pc. Once instruction I is executed, the pc advances to the
instruction immediately following I. If I backs up the pc one instruction,
the pc advances to I again, which gives the final form of the idle program:
add pc, -1
As a rule, the operating system defines its own idle process (back in the
olden days when computers had 16 or 32 leds on the front panel, we used to
spend an inordinate amount of time writing idle processes to flash the leds
in various patterns. These days, people run seti or prime factoring programs
as the idle process). I defined an idle program for you because I felt it
was going to far afield to expect you to come up with the idea yourself
(although I did leave it up to you to figure out why it was an idle program
was needed at all).
As an aside, many modern CPU chips destined for power-limited devices, such
as pdas and cell phones, have fast-slow or on-off switches that help limit
power consumption during idle times. In these cases the simulator is a more
accurate model in that the hardware provides facilities the os should use
when there are no processes to execute.
Also I am still not clear what exactly ADD and MOVE instructions do?
Although the exact meaning depends on addressing modes, ADD x, y adds the
value y to the contents found at location x, and MOVE x, y moves the value y
to the location x.
Is there anyway we can check ADD and MOVE instructions value the same way as
we check for SYSC instruction? Thanks again.
For ADD, not in general because the idle process can properly run for any
period of time, so any value for ADD would be correct. For MOVE, yes, but it
shouldn't tell you anything more than what SYSC would do:
number of MOVEs = number of exit SYSC + 2*(number of sleep SYSC)
Each SYSC requires one MOVE to move the system-call code in register 0; sleep
requires a second MOVE to move the sleep time into register 1.
You should keep in mind that simple instruction-counting checks generally
won't work for the pa2 programs. Pa2 programs contain idle loops that wait
for the terminal to free up; they may execute for an arbitrarily long time,
and so any instruction count may be correct. Also, pa2 programs contain ADD
statements, so the simple correspondence between idle time and ADD counts
won't hold either.
This archive was generated by hypermail 2.0b3 on Mon Dec 18 2000 - 13:30:05 EST