Idling gracefully.


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