Home | History | Annotate | Download | only in dist

Lines Matching refs:the

13 # THE SOFTWARE is provided on an "AS IS" basis and without warranty.
14 # To the maximum extent permitted by applicable law,
18 # regard to the SOFTWARE (INCLUDING ANY MODIFIED VERSIONS THEREOF)
21 # To the maximum extent permitted by applicable law,
25 # ARISING OF THE USE OR INABILITY TO USE THE SOFTWARE.
27 # Motorola assumes no responsibility for the maintenance and support
28 # of the SOFTWARE.  
30 # You are hereby granted a copyright license to use, modify, and distribute the
41 The files itest.sa and ftest.sa contain simple tests to check
42 the state of the 68060ISP and 68060FPSP once they have been installed.
46 The release files itest.sa and ftest.sa are essentially
47 hexadecimal images of the actual tests. This format is the
48 ONLY format that will be supported. The hex images were created
49 by assembling the source code and then converting the resulting
50 binary output images into ASCII text files. The hexadecimal
51 numbers are listed using the Motorola Assembly syntax assembler
52 directive "dc.l" (define constant longword). The files can be
57 the instaler should add symbolic labels to the top of the files.
58 This will allow the calling routines to access the entry points
61 The source code itest.s and ftest.s have been included but only
83 The first section of this module is the "Call-out" section. This section
85 the end of this file). The purpose of this section is to allow the test
87 by the host operating system. This section MUST be exactly 128 bytes in 
89 to a function required by the test packages (these functions and their
91 entry should contain the address of the corresponding function RELATIVE to
92 the starting address of the "call-out" section. The "Call-out" section must
93 sit adjacent to the {i,f}test.sa image in memory. Since itest.sa and ftest.sa
96 The second section, the "Entry-point" section, is used by external routines
97 to access the test routines. Since the {i,f}test.sa hex files contain
99 with respect to the top of the package. The currently defined entry-points
101 routine would simply execute a "bsr" or "jsr" that jumped to the selected
104 For example, to run the 060ISP test, write a program that includes the
109 (_060ISP_TEST is the starting address of the "Call-out" section; the "Call-out"
110 section is 128 bytes long; and the 68060ISP test entry point is located
111 0 bytes from the top of the "Entry-point" section.)
113 The third section is the code section. After entering through an "Entry-point",
114 the entry code jumps to the appropriate test code within the code section.
126 The test packages call _print_string() and _print_number()
127 as subroutines and expect the main program to print a string
128 or a number to a file or to the screen.
129 In "C"-like fashion, the test program calls:
137 For _print_string(), the test programs pass a longword address
138 of the string on the stack. For _print_number(), the test programs pass
141 For debugging purposes, after the main program performs a "print"
142 for a test package, it should flush the output so that it's not
143 buffered. In this way, if the test program crashes, at least the previous
156 The floating-point unit test has 3 entry points which will require
157 3 different calls to the package if each of the three following tests
165 		  separate from the previous tests for systems that don't
172 	    _real_{snan,operr,ovfl,unfl,dz,inex}(). the test expects
173 	    _real_XXXX() to do nothing except clear the exception
175 	    alternate result, the test will print "failed" but this
183 will be system-implemented several different ways and the test packages