The compiler gcc-dlx has the following bug. If you write the following if-statement,
if (handle < 0 || handle > 15) {
XXX
}
and compile it with gcc-dlx. The first condition (handle < 0) is not checked
is the generated assembly code.
In the words, if you pass handle value -1,
the body of the if-statement would not be executed.
We recommend the following get-around of this problem:
if (handle < 0) {
XXX
} else if (handle > 15) {
XXX
}
timerget() is described as a "hardware trap" that generates timing information for processes. It returns, in milliseconds, the time elapsed since the start of the simulator.
Unfortunately, a bug in dlxos means there is no actual implementation for this function. Invoking timerget() merely causes an undefined return value.
We recommend the following function (defined in process.c and declared in process.h) to find out the time elapsed since simulator start:
uint32 my_timer_get(){
uint32 temp = total_num_quanta * 100 + total_num_quanta * 1;
return temp;
}
Here my_timer_get() returns the total time elapsed (in milliseconds) since the start of the simulator. The variable total_num_quanta is a global
variable that stores the total number of time quanta that have elapsed since
the start of the simulator. It is a counter that should be incremented (by
one) ever time ProcessSchedule() is entered. Place, e.g., the following code
in the first few lines within ProcessSchedule()...
The "100" in my_timer_get() signifies that each quantum is actually 0.1s
long, so if we want the time elapsed in milliseconds, we multiply the total
number of quanta that have elapsed since the start of the simulator by 100.
The "1" in my_timer_get() is just a "jitter" present to acknowledge that
ProcessSchedule() itself takes some time to complete. We estimate that
ProcessSchedule() takes slightly less than one quantum to run from start to
finish. The nearest approximation, therefore, is 1 quantum. Thus, if
ProcessSchedule() is entered at, say, 3s into run-time, it will exit (after
looking at the run-queues, selecting the next process to run, performing some
"book-keeping" tasks (updation of priority etc), freeing resources of all
processes in the zombie queue) at or around 3.1s.
CAUTION: The return value for the trap (timerget()) is often "1" which sometimes leads programmers to believe this function is working and causes buggy, hard-to-debug code. DO NOT RELY ON RETURN VALUES FROM timerget(). Use, instead, the work-around provided above.
The gcc-dlx compiler has another bug - it causes an arithmetic / math overflow on XORing with 0xffffffff.
The usual method for "inverting" a number i.e. for flipping all its bits (useful if you are doing some sort of bit-wise "switching" - depending on the value of a particular bit in a variable to indicate the presence/absence of a condition) from 0 to 1 or vice-versa involves a bit-wise XOR with 0xffffffff.
As an example, consider the following code...
( "i" is some uint32 variable with some of its bits set to 1)
i = i ^ 0xffffff;
In theory, the above code "inverts" the value of i -- it sets all its 0 bits to 1 and
resets all its 1 bits to 0.
But using gcc-dlx, the above code will cause an arithmetic overflow exception to be thrown at
run-time.
As a workaround, we suggest the following (taken from memory.c)
static inline uint32 invert(uint32 n){
return (n ^ 0xffffffff);
}
For further reading, see "memory.c".
The implementation of printf in gcc-dlx suffers from at least one known bug. printf() will not work reliably when asked to print more than one argument. If you ask it to print two or more values, the values are taken from the top of the stack. This leads to garbage being printed. In a few cases, the printed values will match the expected values, making it hard to debug errors.
The work-around to this problem is simple...never print more than one value at a time!
Despite a PROCESS_MAX_PROCS constant defined as 32, our current incarnation of DLXOS appears to dump core after more than about 10 processes. For the Spring 2004 term, Dr. Brylow has placed a price on the head of this bug: double your lowest project score to the team that first finds and fixes this bug.