What if -- Minimizing the time spent in testing the code |
In Task 1, to test the operation C <- [A] + [B] on the 68K, we deliberately made use of the sample numbers 639 and -215 given in the HVZ text. This choice meant we could follow through what was happening in the simulator with the explanation in the text.
However, using these specific numbers meant that the (hexadecimal) values that appeared in the SDS Source, Memory and Register windows did not correspond to the (decimal) numbers we had placed in our source file, or had "expected". For example we had to translate the hexadecimal answer, 0x1A8, in the Memory and Register windows back to decimal, 424, to see if the code fragment had actually worked.
This translation between hexadecimal and decimal numbers is fair enough if the purpose of the task C <- [A] + [B] is for me to get familiar with such translations. However, before I get involved in using an algorithm "for something useful", such as the intricacies of hexadecimal to decimal translation, I want to assure myself that the code "works for this task in the way that I expect for something I already understand".
When I am testing a code fragment to check that it works, or debugging the fragment when it does not, I want to find an approach that enables me to spend the minimum amount of time in this phase of the code development. To minimize the effect I follow one of three approaches I have become comfortable in using for debugging. Read through the approaches and, like other software practices that I suggest, decide which of them you feel comfortable using. You may find that one technique is appropriate for the simple Laboratory 1 exercise for testing
C <- [A] + [B]
and the others are better for more complicated coding problems. You may find you like none of them at all and with the help of your instructor develop your own debugging philosophy!
The SDS simulator environment has been designed for the debugging of code for "embedded systems". You can simulate and debug the code within the SDS tool, or (with the Full kit) debug your code while it is actually running on a development or evaluation board.
A frequent requirement is the interpretation of the bit patterns stored in memory. After all a given bit pattern may mean, in a given context within your program code,
When you are debugging your code, you want to be able to "instantly" know what a given bit pattern "means". For example "what does 0x1A4 mean in decimal"? The Source and Register windows do not have an option to provide you this information, you are stuck with their hexadecimal representation of the binary bit pattern. However, the Memory window is far more flexible!
Down load either your 68K or PowerPC executable into a simulator and run your code. Activate a Memory window and point it to memory location 0x7200. Right click in the Memory window and select the Options option. You will find that you can cause the Memory window values (not the addresses) to display in any of the following SDS 68K formats
We need the signed, word, decimal setting in order to correctly display the numbers we used during Task 1 on the 68K processor. Note that although the unsigned, word, decimal setting will show the same result for SUM (424), it will not show the value of SECOND correctly. Try it yourself.
Have you ever coded the following sequence in "C" and got some strange printed answers?
float x = 6; int y = 7; printf("%d %d %f %f", x, y, x, y)
With the SDS Memory window options, you can put the values into memory as floats and translate them as integers with the Memory window Options command and explain those strange results.
This flexibility of the Memory option has many personal advantages for me in my own research on digital signal processing techniques
In a number of the software engineering management courses I have taken, I have heard one of the following horror stories many times.
This section will show you how to avoid these problem in a straight forward way.
To find out whether a code segment works, I have to choose values for the variables used in the test. It is obviously impossible to make the test with all possible values to determine if the program works for all these values. Instead, in real life, you only have time to test using a few of the possible values.
However, if you choose the wrong values to use when testing, you are wasting your time.You can choose 200 different sets of values, and although you worked hard at the testing, you are actually no further ahead than if you had just tested using one set. For example, equating A and B in your code to all of the following sets of values will give you no more confidence that your algorithm works than if you had only used the first set of values or the last.
When testing, there is an approach called equivalence partitioning that provides you with the minimum number of sets of values to use to test an algorithm to give you high confidence that it works. If you really wanted to thoroughly test your code for Task 1, this approach indicates that the values suggested for use in the test are in 4 partitions.
In industry, where you are under pressure to release the product, or at university under pressure with all the course assignments, you may not have the time to complete the last partition. But making a test on the first three will at least give you some confidence.
Doing partitioning on Task 1 is over-kill. We just want to demonstrate the simulator working with any set of values at this point. Later we may want to explore and gain experience with decimal and hexadecimal number conversions, but initially, we want to see if the code segment works and spend the minimum amount of time checking it.
Since the partitioning approach says start with any typical set of values, I would personally have started with the values 291 and 1110. However, I would not place them in my source code as
A DC.W 291 B DC.W 1110
but as the values
A DC.W 0x123 B DC.W 0x456
Why would I personally choose the values 0x123 and 0x456 (SUM = 0x579) rather than values suggested by HVZ of 639 and -215? One set of values is no more or less typical of the values we would use in the task C <- [A] + [B], especially as we are familiar with the necessary hexadecimal to decimal translations needed for the HVZ sample numbers already.
In trying to complete Task 1 on the 68K, it is not now worth swapping. But in later laboratories, I would consider it far easier to debug code when the intermediate values from operations (stored in registers and displayed in hex by the SDS simulator) are simple (trivial ) hexadecimal values that I can directly compare to the values I work out in my head. I like to have my source code and the simulator values look the same -- hexadecimal notation.
When we go to the PowerPC simulator code for Task 1, we will try this approach and you can see for yourself whether this approach is easier for the initial testing of a code segment. If your code segment does not pass this test, you know you're in trouble. If the algorithm does pass, then we need to proceed to test more extensively using a wide range of sets of numbers, properly selected for maximum testing in the minimum amount of time -- equivalence partitioning.
For the task C <- [A] + [B], there are 65336 possible values for both A and B variables, given a total range of possible values for C of close to 4 billion. There is obviously no time to test all possible outcomes for all possible inputs. Instead we need to break the input into a series of groups, or paritions, where each number in a partition has the same properties as the other numbers in the parition. Testing one number in a partition is therefore equivalent to testing all values.
These are the partitions I would use in order to first test, and then study, the task C <- [A] + [B] when using 16-bit variables. As mentioned earlier, this is over kill for Task 1, but it does demonstrate the concept behind equivalence partitioning
Thus out of the 4 billion possible combinations of signed numbers that could be used in task C <- [A] + [B], equivalence testing says that the following seven number groupings would, with high confidence, test all possible scenarios that could occur
For the 4 billion possible combinations of unsigned numbers in the same task, equivalence partitioning says that only 3 scenarios need to be considered
You should make a "test" bank of these groups of numbers and store them. Then if you changed the algorithm, you could quickly recall the "test" bank and reuse the numbers to ensure the algorithm still worked.
More detailed information on the efficient and time saving approach of equivalence partitioning is beyond the scope of the "Companion". If you need ideas of how to partition test values for complex algorithms, follow the topic up in a software engineering text.
![]() |
Last modified: July 08, 1996 03:36 PM by M. Smith.
Copyright -- M. R. Smith