View EXCIMERLABMANUAL_1394050.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

1 m m m m o o o o t t t t o o o o r r r r o o o o l l l l a a a a p p p p o o o o w w w w e e e e r r r r p p p p c c c c e e e e x x x x c c c c i i i i m m m m e e e e r r r r l l l l a a a a b b b b o o o o r r r r a a a a t t t t o o o o r r r r y y y y m m m m a a a a n n n n u u u u a a a a l l l l jose i. qui?ones, noel serrano, walter guiot, luis narvez, eisen montalvo department of electrical and computer engineering university of puerto rico-mayagez chuck corley powerpc applications engineering motorola editor: jos l. cruz rivera department of electrical and computer engineering university of puerto rico-mayagez volume i instructors manual
2 ? motorola inc. 1999 portions hereof ? international business machines corp. 1991C1995. all rights reserved. this document contains information on a new product under development by motorola and ibm. motorola and ibm re- serve the right to change or discontinue this product without notice. information in this document is provided solely to enable system and software implementers to use powerpc m icroprocessors. there are no express or implied copyright or patent licenses granted hereunder by motorola or ibm to design, modify the design of, or fabricate circuits based on the information in this document. the powerpc 60x microprocessors embody the intellectual property of motorola and of ibm. however, neither motorola nor ibm assumes any responsibility or liability as to any aspects of the performance, operation, or other attributes of the microprocessor as marketed by the other party or by any third party. neither motorola nor ibm is to be considered an agent or representative of the other, and neither has assumed, created, or granted hereby any right or authority to the other, or to any third party, to assume or create any express or im plied obligations on its b ehalf. information such as data sheets, as well as sales terms and conditions such as prices, schedules, and support, for the prod- uct may vary as between parties selling the product. accordingly, customers wishing to learn more information about the products as marketed by a given party should contact that party. both motorola and ibm reserve the right to modify this manual and/or any of the products as described herein without further notice. nothing in this manual, nor in any of the errata sheets, data sheets, and other supporting documentation, shall be interpreted as the conveyance by motorola or ibm of an express warranty of any kind or implied warranty, representation, or guarantee regarding the merchantability or fitness of the products for any particular purpose . neither motorola nor ibm assumes any liability or obligation for damages of any kind arising out of the application or use of these materials. any warranty or other obligations as to the products described herein shall be undertaken solely b y the marketing party to the customer, under a separate sale agreement between the marketing party and the customer. in the absence of such an agreement, no liability is assumed by motorola, ibm, or the marketing party for any damages, actual or otherwise. typical parameters can and do vary in different applications. all operating parameters, including typicals, must be validated for each customer application by customers technical experts. neither motorola nor ibm convey any license under their respective intellectual property rights nor the rights of others. neither motorola nor ibm m akes any claim, warranty, or representation, express or implied, that the products described in this manual are designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other ap plications intended to support or sustain life, or for any other application in which the failure of the product could create a situation where personal injury or death may occur. should customer purchase or use the products for any such unintended or unauthor- ized application, customer shall indemnify and hold motorola and ibm and their respective officers, employees, s ubsidi- aries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthor- ized use, even if such claim alleges that motorola or ibm was negligent regarding the design or manufacture of the part. motorola and are registered trademarks of motorola, inc. motorola, inc. is an equal opportunity/affirmative action em- ployer. ibm and ibm logo are registered trademarks, and ibm microelectronics is a trademark of international business machines corp. the powerpc name, powerpc logotype, and powerpc 601 are trademarks of international business ma- chines corp. used by motorola under license from international business machines corp. international business ma- chines corp. is an equal opportunity/affirmative action employer. dis claim ers
3 this laboratory manual contains 13 lab experiments for the powerpc excimer board presented in an increasing order of complexity. the experiments range from memory mapping problems and system benchmarking to integer to floating point number representation conversion. it is as- sumed that the student has a basic understanding of c and assembly languages. there is a natural progression in the lab experiments leading up to the dhrystone and linpack benchmarking of the powerpc603e that forms the basis of the excimer board. specifically, the experiments guide the student through the following topics: code com pilation, code download, dink functions (resi- dent monitor program), keyboard i nput, assembly l anguage programming, and linking assembly language to c code. there are also experiments on memory mapping and flash rom program- ming. each lab experiment is structured as follows: problem statement, objectives, b ackground infor- mation, procedure, questions, and references. the problem statement provides a brief indica- tion as to the tasks that will be performed. the objectives section presents the specific educa- tional objectives that will be met upon successful completion of the lab experiment. the back- ground information section presents a brief description of the theory behind the devices, instruc- tions, functional units, and/or methods to be followed in the conduction of the experiment. the procedure section presents a step-by-step guide to the experiment. the questions section seeks to guide the student through a m eaningful analysis of what he/she has performed as part of the experiment. finally, the references section presents additional references with material that is useful for the experiment at hand. in addition to these sections, the instructors manual contains a results and a troubleshooting section. int roduc t ion
4 this laboratory manual contains experiments designed to familiarize students with the powerpc architecture via the excimer laboratory board. the lab m anual is not meant to serve as a stand- alone text book on the powerpc instruction set architecture (isa), but rather is designed as a companion to any powerpc book or t echnical reference. each experiment is designed so that students will end up with a significant number of useful subroutines that can be used in other more complex programming problems. additional references to the powerpc architecture and the excimer board may be found at http://www.motorola.com/sps/powerpc/teksupport .
5 experiment #1: metaware tutorial write and compile a simple c program. 6 experiment #2: dink tutorial download the program to excimer and use some utilities. 10 experiment #3: useful dink functions write a program that will get input from kb and echo to display. discuss various utilities of interest. 14 experiment #4: excimer memory map compile, download, and execute a c program which blinks the on-board leds 18 experiment #5: led control from pc keyboard write and debug a c program to turn the on-board leds on and off for varying integer counts. 23 experiment #6: a simple scanf function for excimer develop a c function for taking character input from the terminal emulators keyboard attached to excimer through the serial port and converting number characters to decimal values used in other programs. 26 experiment #7: introduction to assembly language programming write a simple assembly language program. 32 experiment #8: linking assembly language and c code link previous code fragments. 41 experiment #9: converting integers to floating point develop an assembly language subroutine to convert the 64 bit integer value read from the powerpc time base facility to a 64 bit (double) floating point number representing seconds. (contributed by chuck cor- ley, motorola) 52 experiment #10: dhrystone benchmarking write and debug a c program to count the integer number of cycles required to execute the dhrystone benchmark. 63 experiment #11: linpack benchmarking write and debug a c program to time in microseconds (floating point) the execution of the linpack bench- mark. 72 experiment #12: cache impact on benchmark metrics write a single program to time the performance of dhrystone and linpack with the caches enabled and dis- abled. 76 experiment #13: flash rom write a program that copies itself into flash rom and begins executing from there. 80 contents
6 metaware tutorial problem statement: ? in this experiment the student will develop and compile a c program that will calculate the first 12 fibonacci numbers using the metaware powerpc compiler. (contributed by noel serrano). objectives: upon completion of this laboratory experience, students will be able to: ? write, debug and compile a c program using the metaware and code warrior compilers ? write a recursive function that will generate the first 12 fibonacci numbers background information: this experiment is designed to take you through the major steps required to implement a simple algorithm for the generation of the first 12 fibonacci numbers using the metaware compilers for the excimer board. the metaware compiler facilitates code writing, debugging, and optimization. more information on the compiler may be obtained from www.metaware.com . the fibonacci sequence represents a series that has as its first two elements 0 and 1. the re- maining elements can be obtained by simply adding the last two numbers to get the next. for ex- ample, the first 12 fibonacci numbers (the first element in the sequence, 0, is not included) are: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 experiment 1
7 the fibonacci numbers arose from the solution to the following problem posed in the year 1225: suppose we have one pair of rabbits that can produce another pair of productive offspring when they reach the age of 1 m onth and that each successive pair of offspring can do the same. fur- thermore, assume the rabbits never die. how m any rabbits will t here be after n months? the solution is as follows: if after n months there are k n pairs of rabbits, the number of pairs in month n+ 1 will be k n plus the number of new pairs born. however, since new pairs are only born to pairs at least 1 month old, there will be k n-1 new pairs, that is k n+1 = k n + k n-1 , which is simply the rule for generating the fibonacci numbers. more information on the fascinating world of fi- bonacci num bers and their applications can be found in http://pass.maths.org.uk/issue3/fibonacci/index.html . procedure: 1. write a c language program that will calculate the first 12 fibonacci numbers. hint: use a recursive function. 2. to be able to print the numbers in the dink32 interface (this will be di scussed in more detail in future experiments) you will need to add the following code to your program to redefine the default printf function with the one provided by dink. also the printf function should contain only one variable. #define printf dink_printf unsigned long (*dink_printf)() = (unsigned long (*)())) 0x6270; 3. type your program to a text file using notepad or edit and save it in the directory you have chosen to contain your code. 4. compile the c code with the hcppc command included with the metaware c compiler using the following command on the dos command prompt : hcppc ?ppc603 ? file.c
8 note: file.c stands for the c code file. you may name your c code file as you wish, but remember to use the chosen name in the hcppc command. the result from this command will be file.o, which is the object file. for m ore information a bout the options of the compiler type hcppc -h . 5. link the object files using ldppcl command to invoke the linker program included with metaware c compiler using the following command on the dos command prompt: ldppc ? start_addr=70000 ?m file.o note : file.o is the object file generated in the last step. the object file will be named exactly as you named the c code file.) the result from this step will be the file a. hex, the file that will be later downloaded to the excimer board. the b start_addr=70000 is an option that speci- fies where does your code is going to be paced in the memory of the excimer board. for more information about the linker type ldppc -h . references: ? metaware high c/c++ compiler C http://www.metaware.com suggested code: int fibonacci(int x); #define printf dink_printf unsigned long (*dink_printf)() = (unsigned long (*)()) 0x6270; main() { int fib_no = 0, index = 0; while (index < 12) { fib_no = fibonacci(index); printf("fibonacci number for index %d is", index);
9 printf(" %d\n", fib_no); index++; } return 0; } int fibonacci(int number) { switch (number) { case 0 : return 1; case 1 : return 1; default : return (fibonacci(number-1) + fibonacci(number-2)); } } troubleshooting: if the student is not able to: ? print to the dink 32 interface: verify that the address of the pointer address matches that of the dink version in use. this can be done through an st command in dink and verifying that the address for printf matches the one provided in this manual.
10 dink tutorial problem statement: ? this experiment is designed to introduce the student to the dink int erface. a tutorial on how to download code to the excimer board and some useful dink debugging u tilities are also presented. (contributed by noel serrano). objectives: upon completion of this laboratory experience, students will be able to: ? download their programs to the excimer board using the dink interface. ? debug the programs using the dink built-in debugging tools. background information: the excimer board contains a debugging interface called dink. this interface enables you to connect to the evaluation board through a serial cable using a terminal program. this enables the developer to have continuous communication with the evaluation board, allowing insight into the boards state at all time. the terminal screen of your program should look like this. experiment 2
11 figure 1. dink32 on terminal client more information on dink can be found at www.mot.com/sps/powerpc/teksupport/teklibrary/index.html . procedure: 1. first make sure you have your evaluation board connected using the serial cable provided to serial port 1 (com1). open your terminal client and configure it to connect through com1 using the following parameters. parameter value protocol serial port com1 baud rate 9600 data bits 8 parity n stop bits 1 rts/cts enabled turn on the evaluation board and press connect on your terminal client. you should be able to see the initialization window with the dink32_603e >> prompt as presented in the figure shown below (see step 4). 2. compile the program you created on experiment number one using the metaware compiler.
12 3. now you are ready to download your program to the excimer board for execution. to do so first go to the terminal client running the dink32 interface and type dl k . this command will expect to receive data from the keyboard serial port (com1). now proceed to send the file from the terminal client. this can be done by selecting a comm and like send text file or send ascii (this can vary from one terminal client to the other). now browse for the a.hex created in the directory where you compiled your program. 4. run your program by typing go 70000 in the dink32 program. if your code is correct and if you have been successful in downloading the code you should get an output like the following. hint: the table below presents some useful commands in case you need to debug your program, view memory or register contents, and/or ser breakpoints for program tracing. for m ore informa- tion type help in the dink prompt. command format description memory display md displays the memory area specified by the hex address registry display regdisp rx displays the register specified by rx disassemble ds disassemble the code starting at the specified address location trace tr begin tracing a program at the specified address. to continue tracing type tr +. breakpoint br sets a breakpoint at the specified address assemble as provides you with the option of changing part of the assembly from the dink interface accessing it through the address of the code line.
13 references: [1] motorola, designing a minimal powerpc system, powerpc application note: an1769/d, 1998. conclusions: students should be able to note that: ? dink works similarly to other evaluation board environments ? dink provides functionality that enables the user to modify the memory, registers, and as- sembly code ? dink provides breakpoint and trace capabilities for debugging purposes troubleshooting: if the student is not able to communicate with the dink: ? verify the connections to com1 port and board ? check for correct settings on terminal client
14 useful dink functions problem statement: ? in this experiment the student is introduced to a set of useful functions that are contained within the dink 32 interface. (contributed by noel serrano). objectives: upon completion of this laboratory experience, students will be able to: ? work with more advanced dink functions and use them on future laboratories. background information: the dink 32 interface provides a set of functions that fac ilitate the development of programs for the excimer board. among the functions included in dink are some that allow the program- mer to capture data from the keyboard and to print to the screen. o ther functions control parts of the excimer board configuration like enabling the timer, cache, etc. this laboratory will give you and overview of a basic set of these functions and will teach you how to access them in your c programs. there is a comm and included in dink that display a list of all these functions with their branch labels and corresponding addresses. the comm and is st and the corresponding output will look like this. dink32_603e >>st experiment 3
15 current list of dink branch labels: keyboard: 0x0 get_char: 0x1e4c4 write_char: 0x5eb4 tbaseinit: 0x39e0 tbasereadlower: 0x3a04 tbasereadupper: 0x3a20 cacheinhibit: 0x3a3c invenl1dcache: 0x3a5c disl1dcache: 0x3aa4 invenl1icache: 0x3ac8 disl1icache: 0x3b00 burstmode: 0x3bfc ramincbk: 0x3c3c raminwthru: 0x3c7c dink_loop: 0x55e8 dink_printf: 0x6270 current list of user branch labels: dink32_603e >> all these functions can be accessed through your c code by casting a function that will point to the address in dink. the code that defines the function would look like the following example for the printf function. #define printf dink_printf unsigned long (*dink_printf)() = (unsigned long (*)()) 0x6270; in the following section we present examples of three dink functions. a) get_char C this function enables the programmer to capture characters from the keyboard through the dink interface. the get_cahr function can be accessed by using the following code: #define getchar dink_get_char unsigned long (*dink_get_char)() = (unsigned long (*)()) 0x1e4c4; this will enable you to capture characters from the keyboard. the syntax for r eading character from the keyboard would be: char led; led = getchar();
16 b) write_char C this function enables the programmer to display characters on the terminal screen that is running dink. the write_char function can be accesed by using the following code. #define writechar dink_write_char unsigned long (*dink_write_char)() = (unsigned long (*)())0x5eb4; this will enable you to output characters to the screen. the sysntax for displaying single charac- ters from the keyboard would be: char led = ?? led = writechar(led); c) dink_printf Cthis functions provide the programmer the option of displaying a string of char- acters on the dink interface and also provide the user the ability of including a runtime variable, either char or integer, on this string. it is done by using the dink_printf function using the same syntax as in c. #define printf dink_printf unsigned long (*dink_printfr)() = (unsigned long (*)())0x6270; this will enable you to print any message on the dink and also include any of the variables in- cluded in your code. the dink printf function can only include one variable per statement not like in c which it can contain any number of variables. printf("fibonacci number for index %d is", index); there are other important functions that can be used to control many aspects of the excimer board. these are briefly described in the table below and explained in details in the included dink manuals. functions address description tbaseinit 0x39e0 initializes the time base register tbasereadlower 0x3a04 reads the lower half of the time base register
17 tbasereadupper 0x3a20 reads the upper half of the time base register. cacheinhibit 0x3a3c turns off the caches. invenl1dcache 0x3a5c invalidate and enable the l1 data cache. disl1dcache 0x3aa4 disable l1 data cache. invenl1icache 0x3ac8 invalidate and enable the l1 instruction cache. disl1icache 0x3b00 disable l1 instruction cache. burstmode 0x3bfc sets up burst mode. references: [1] motorola, designing a minimal powerpc system, powerpc application note: an1769/d, 1998. suggested code: /* this section of code can be used to define any of the dink functions in a c l anguage program. the user will only need to modyfy the address and function name. */ #define function_name dink_function_name unsigned long (*dink_function_name)() = (unsigned long (*)()) hex_addr; troubleshooting: if the student is not able to access the dink functions: ? verify the casting is correct. ? verify that he/she is using the correct hex address.
18 excimer memory map problem statement: ? this experiment requires the compilation, downloading, and execution of a c l anguage pro- gram which blinks the excimer boards status and error light emitting diodes (leds). (contributed by noel serrano, jos i. qui?ones, luis navez, w alter guiot, and gunther costas). objectives: upon completion of this laboratory experience, students will be able to: ? write and compile a c program ? download and execute powerpc assembly object code ? locate the leds within the excimers memory map ? apply the methodology needed to turn on and off the leds background information: the powerpc family of microprocessors is based on a memory m apped input/output scheme. under this scheme, an input port can be thought of as read-only memory location, while an out- put port can be treated like a write-only memory l ocation. the microprocessors address bus is used to select the peripheral device (port location), the data bus is used to transmit or receive data to/from the device, and the transfer type signals are used to convey the directionality of the information transfer. experiment 4
19 the memory map for the excimer board is shown in fi gure 2. the memory map indicates that out of a total of 2 32 = 4gb addressable locations, the excimer board allocates 2 30 = 1gb each to static ram, fast i/o devices, slow i/o devices and fl ash rom [1]. of course, the excimer board only uses a fraction of the memory locations all ocated for each t ype of memory and de- vices. the excimer board is configured with 512 kbs of sram, 4mbs of flash rom, and some led indicators. for example, theres a status led located at 0x40200000, while an error led is specified at 0x40600000. static ram 0x0000_0000 0x3fff_ffff fast i/o 0x4000_0000 0x7fff_ffff ? status led : 0x4020_0000 ? error led: 0x4060_0000 slow i/o 0x8000_0000 0xbfff_ffff flash rom 0xc000_0000 0xffff_ffff figure 1: excimer's memory map. in this experiment you are required to write a c program that will blink (repeatedly turn on and off) the status and error leds alternatively. the leds are turned on/off by clear- ing/setting bit 3 (fourth least signifi cant bit) of these locations. the reason for this negative logic is that the leds are connected in a common anode configuration, as shown in fi gure 2 for the case of a seven segment led display.
20 figure 2: common anode led configuration. leds will turn on when the cathode is at ground level ( excimer output asserted low) to successfully blink an led, you must carefully select the delay timing. remember that the mi- croprocessor may turn the led on and off so quickly that you will not see the blinking effect. since your program will be written in c, a simple for loop instruction may do the job. for (counter=0;counter <= parameter; counter++); note : counter must be declared as unsigned long in the program. the value parameter will define the delay time. there are other ways to accomplish a time delay, for example using the powerpcs internal timer register. these techniques will be demonstrated in the successive experiments. procedure: 1. write a simple c code that alternatively blinks the status and error leds ten times. 2. compile the c code with the hcppc command included with the metaware c compiler using the following command on the dos command prompt : hcppc ?ppc603 ? file.c
21 note: file.c stands for the c code file. you may name your c c ode file as you wish, but remember to use the chosen name in the hcppc command. the result from this command will be file.o, which is the object file. 3. link the object files using ldppcl command to invoke the linker program included with metaware c compiler using the following command on the dos command prompt: ldppc ? start_addr=70000 ?m file.o note : file.o is the object file generated in the last step. the object file will be named ex- actly as you named the c code file.) the result from this step will be the file a.hex. 4. run the dink32 application on your windows 95 or nt terminal. download the a. hex file, which resulted from the last step. to do so, write dl ? on the dink monitor. on the terminal it will appear, ?et to keyboard port . press transfer -> send text file on the communication terminals m enu. find your a. hex file and select it. the file will be downloaded to the excimer board. 5. execute the program by writing go 70000? on the terminal. 6. observe the behavior of the on-board leds. what happens if you decrease/increase the value of parameter in your for loop statement? references: [1] motorola, designing a minimal powerpc system, powerpc application note: an1769/d, 1998. suggested code: /* this program will blink the status and error leds alternatively ten times. after that, both leds will be shut down. 0xfffff will cause a visible delay in a 300mhz powerpc*/
22 main () { unsigned long count; int loop; for (loop = 0 ; loop <= 10; loop++) { *(char *) (0x40200000) = 0x00; //turn on status *(char *) (0x40600000) = 0x08; //turn off error for(count = 0; count <= 0xfffff; count ++); *(char *) (0x40200000) = 0x08; //turn off status *(char *) (0x40600000) = 0x00; //turn on error for(count = 0; count <= 0x1fffff; count ++); } *(char *) (0x40600000) = 0x08; } conclusions: students should be able to note that: ? the speed, which drives the powerpc microprocessor, is very fast and thus a blinking effect might not be perceived. ? for different loop parameters, the led will remain on or off for a different time period. ? the leds are configured as common anode (negative terminal connected together). troubleshooting: if the student is not able to turn on or off the led check that: ? the address being written to is either 0x40600000 or 0x40200000. ? a suitable value for the time delay loop has been defined. ? the student has compiled, linked and downloaded the program correctly.
23 led control from keyboard problem statement: ? this experiment requires the compilation, downloading, and execution of a c l anguage pro- gram which blinks the excimer boards error l ight emitting diode (leds) the number of times specified by the user input. (contributed by noel serrano and jos i. qui?ones). objectives: upon completion of this laboratory experience, students will be able to: ? use the dink functions presented in experiment #3 ? print to the dink 32 interface ? capture single characters from the keyboard and echo them to the dink 32 interface procedure: 1. write a c program that will blink the on board leds based on user i nput. the program should ask the user which led he wants to blink and how many times. hint : to create this program use the program you created in the previous experiment and the useful dink functions. references: [1] motorola, designing a minimal powerpc system, powerpc application note: an1769/d, 1998. experiment 5
24 suggested code: #include #define getchar dink_get_char #define putchar dink_write_char #define printf dink_printf void blink_leds(int addr, int i); unsigned long (*dink_get_char)() = (unsigned long (*)()) 0x1e4c4; unsigned long (*dink_write_char)(char) = (unsigned long (*)(char)) 0x5eb4; unsigned long (*dink_printf)() = (unsigned long (*)()) 0x6270; main() { int decimal_no; char led; char number; do { printf ("\nselect the led you want to blink:\n"); printf ("\ts - press s for the status led\n"); printf ("\te - press e for the error led\n"); printf ("\tq - press q to quit\n"); led = getchar(); /* read typed character */ if (led == 'e' || led == 'e') { printf ("\nenter the number of times (1-9) to blink the er- ror led: "); do{ /* is it a number??? */ number = getchar(); }while ( !((number >= '0') && (number <= '9')) ); putchar(number); /* echo typed character */ decimal_no = number - 48; blink_leds(0x40600000, decimal_no); } else if (led == 's' || led == 's') { printf ("\nenter the number of times (1-9) to blink the status led: "); do{ number = getchar(); }while ( !((number >= '0') && (number <= '9')) ); putchar(number); decimal_no = number -48; blink_leds(0x40200000, decimal_no); } } while ( led != 'q' && led != 'q' ); /* x or x */ return 0; }
25 void blink_leds(int addr, int i) { unsigned long count; int loop; for (loop = 0 ; loop < i; loop++) { *(char *) (addr) = 0x00; //turn on error for(count = 0; count <= 0xfff00; count ++); *(char *) (addr) = 0x08; //turn off error for(count = 0; count <= 0xfff00; count ++); } *(char *) (0x40600000) = 0x08; } conclusions: students should be able to note that: ? a powerpc excimer board program can obtain data from a user via the keyboard. ? the get char function is not useful in cases you need more t han character as i nput, so an im- plementation of a scanf function would be useful. troubleshooting: if the student is not able to: ? access dink 32 interface functions: use the st command to verify that the address for the dink functions matches the ones provided in this manual. ? blink the leds: verify the memory mapping for each of the leds.
26 a simple scanf function for excimer problem statement: ? in this experiment the student will develop a c function for taking character input from the terminal emulators keyboard attached to excimer through the serial port and converting number characters to decimal values used in other programs. (contributed by chuck corley, motorola) objectives: upon completion of this laboratory experience, students will be able to: ? substitute the get char and put char equivalent functions available in dink for the same functions normally found in ? recognize the ascii character values returned from getchar() and echo them back via putchar() ? convert digit characters input through the keyboard into decimal integer values for use in other pro- grams ? utilize dinks print output function to display the resulting decimal value background information: texts on programming describe how to get input for a program. for example, the waite groups new c primer plus [1] says: the c library contains several i nput functions, and scanf() is the most general of them, for it can read a variety of formats. of course, input for the keyboard is text because the keys generate text characters: letters, digits, and punctuation. when you de sire to enter, say, the integer 2002, you type the characters 2 0 0 and 2. if you want to store that as a experiment 6
27 numerical value rather than as a string, your program has to convert the string character- by-character to a numerical value. and that is what scanf() does! it converts a string in- put into various forms: integers floating-point numbers, characters, and c strings. it is the inverse of prin tf(), which converts integers, floating-point numbers, characters, and c strings to text that is to be displayed on the screen. l ike prin tf(), scanf() uses a control string followed by a list of arguments. the control string indicates into which formats the input is to be converted. the dink software on excimer provides input and output functions that save the programmer from having to interact directly with the duart that r eceives i nput and sends output to the terminal. how- ever these functions are not at the level of a com plex f unction like scanf(). nevertherless, many of the c programs that we desire to run on excimer call the scanf() function because of its widespread use. in this experiment, you will write your own function my_scanf() and substitute it (by a #define direc- tive) for any scanf() function that the com piler may encounter in programs intended for excimer. likewise you will define dink_printf() to substitute for printf() and link dink_printf() into your pro- grams. then you will have input and output functions for use in other programs. to keep my_scanf() simple we will assume that the only control string for converting inputs is the %d or decimal format. your m y_scanf() function should accept a control string as an argument but then ignore it and return a decimal value to the second (and last) argument in the functional ca ll. l ater ex- periments may require m ore sophisticated substitute functions for scanf(), but this simple decimal in- put routine will be widely applicable. eximers dink_printf() does accept a control string but it ignores floati ng-point and character formats. it will only print decimal numbers (%d), hexadecimal numbers (%x), and strings (%s) and then only one such format per printf statement.
28 procedure: 1. write a c language program which asks the user to i nput a number through the keyboard and then outputs the number input as a positive decimal number. 2. in a separate file write a c program my_scanf(char, int) which reads characters from the keyboard, echoes those that are digits, and at the carriage return assigns a decimal value to the second argument of my_scanf(). hint: while ignoring non-digit characters may be an acceptable simplification, you may want to check for backspace or delete characters and take the appropriate action if the user attempts to correct his numerical input. 3. write a header file which equates the function name scanf to my_scanf and printf to dink_printf. in the header file equate dink_printf to the address where it is stored in ram as revealed by dinks symtab (symbol table) command. include this header file in your test program. example: /* file - support.h * equates functions used in excimer exercise to equivalent * functions defined in dink or in my_scanf.c * note: if dink function addresses change because dink changes, * addresses here must be changed accordingly. * * modification history: * 19jan99,cjc original */ #define printf dink_printf #define scanf my_scanf extern void my_scanf(const char *, ...); unsigned long (*dink_printf)() = (unsigned long (*)()) 0x6368; 4. your my_scanf() function will use getchar() and putchar(). write a header file equates these to dinks get_char and write_char. write a header file which equates dink_get_char() and dink_write_char() to the addresses where they are stored in ram as revealed by dinks symtab (symbol table) command. . include this header file in the my_scanf.c program. example: /* file - excimer.h * provides the addresses of functions defined in dink on the excimer * board and used by programs. the addresses of the functions are * taken from the xref.txt file generated by the linker. * when a new version of dink is downloaded to the target, make sure * the functions' addresses are changed accordingly to match with the
29 * new addresses being generated. * * modification history: * 21oct98,my created for excdemo * 19jan99,cjc modified to run with my_scanf code. */ #define getchar dink_get_char #define putchar dink_write_char /* addresses of dink functions. */ unsigned long (*dink_get_char)() = (unsigned long (*)()) 0x1e5e4; unsigned long (*dink_write_char)(char) = (unsigned long (*)(char)) 0x5fac; 5. link your input/output test program and my_scanf program. 6. download the resulting s-record file to excimer, execute it, confirm that it echoes only digit charac- ters and returns the correct decimal value to your program at the carriage return. references: [1] the waite groups new c primer plus (1990: howard w. sams & co, carmel, in) suggested code: /* file "testscanf.c" * a test harness for excimer experiment to prove out * my_scanf() function. * modification history: * 990121 cjc original */ #include "support.h" void main(void) { int decimal_no; printf ("enter a decimal number: "); scanf("%d", &decimal_no); printf ("\ndecimal number is: %d \n", decimal_no); /* file "support.c" * defines an alternative to the scanf function provided by * stdio.h for use when running the dhrystone benchmarks on dink. * created: 990119 cjc * modified: */ #include "excimer.h" void my_scanf(char *fmt, int *v) { char ch; int no_runs = 0; while ((ch = getchar()) != 0xd) /* carriage return? */ { if ( (ch == 0x7f) || (ch == 0x8)) /* delete? */
30 { putchar(0x8); /* backspace */ putchar(0x20); /* overprint a space. */ putchar(0x8); /* backspace */ /* assume modulo arithmetic to subtract last digit added. */ no_runs = no_runs / 10; } else if ( (ch >= '0') && (ch <= '9')) /* a digit? */ { putchar(ch); /* echo it and */ /* accumulate the value. */ no_runs = (no_runs * 10) + (ch - 48); /* ascii character - 48 equals the digit. */ } } *v = no_runs; /* assign second arg the value. */ } /* file ?akefile? */ support = supportopt = optlev = -o1 cpu = 603 targflags = -hppc$(cpu) cc = c:\sw\metaware\hcppc\bin\hcppc -ic:\sw\metaware\hcppc\inc \ -hnocopyr -c -nofsoft $(optlev) $(targflags) as = c:\sw\metaware\hcppc\bin\asppc -c -big_si lkopt = -bbase=0x70000 -xm -e main -bnoheader -bhardalign \ -xo=$(@) -q -qn -cglobals -csections -csymbols -ccrossref \ > $(@d)\xref.txt link = c:\sw\metaware\hcppc\bin\ldppc $(lkopt) testscanf.src: testscanf.o my_scanf.o $(link) testscanf.o my_scanf.o \ c:\sw\metaware\hcppc\lib\be\fp\libmw.a testscanf.o: testscanf.c $(cc) testscanf.c -o testscanf.o $(supportopt) my_scanf.o: my_scanf.c $(cc) my_scanf.c -o my_scanf.o $(supportopt) conclusions: students should be able to note that: ? characters are received from the keyboard as bytes of ascii encoded information. ? input/output functions normally available in standard c libraries for a given com puter may not be available or may exist in different, simpler forms on a small, embedded evaluation system like exci- mer . ? programmers can write their own input/output routines or link in routines that are provided in the embedded system.
31 ? hard-coding addresses of embedded routines is a dangerous way of linking c ode if the routines are relocated by dink revisions. troubleshooting: if the student is not able to: ? get started. suggest that the student develop and debug the c program on the host com puter by including before substituting the dink routines and downloading to excimer. this should clarify the ascii encoding of digits and conversion to a decimal number. ? recognize the carriage return character. eximer will be in a continous loop of accepting and echoing input. additional printf() statements which output each character as it is read in will reveal the value provided by the duart for the carriage return character.troubleshooting:
32 introduction to assembly language programming problem statement: ? in this experiment the student is introduced to the powerpc instruction set architecture through the development of an assemblyllanguage routine. (contributed by eisen montalvo-ruiz) objectives: upon completion of this laboratory experience, students will be able to: ? write and compile an assembly language subroutine ? use metaware assembler directives ? understand the instruction set and the register set of the powerpc background information: ? powerpc register set the powerpc architecture has two levels of privileges, the user m ode, and the supervisor m ode. in the supervisor m ode all registers are available to the programmer, while in the user m ode only a subset of the registers are available. we are going to focus on the user mode for this laboratory. tin the user m ode the available pow erpc registers include 32 general pur pose registers ( gprs), 32 floating-point registers ( fprs), a condition register (cr), a floating-point status and condition register (fpscr), the xer reg ister, the link register (lr) and the count r egister experiment 7
33 (ctr). in addition, there are two read-only registers, associated with the time base facility (tbu and tbl). the gprs are used to manipulate integer data. they come in two sizes, according to the implementation of processor. 32-bit gprs for the 32-bit powerpc and 64-bits for the 64-bit powerpc. they are used as source and destination registers in the integer instructions. the fprs are used with floating-point instructions. they are 64 b its wide independently of the implementation, and can manipulate single- and double floating-point data. related to these registers is the fpscr. it contains all floating-point exception si gnal bits, excluding summ ary bits, exception summary bits, exception enable bits, and rounding control bits. the cr is a 32-bit reg ister, divided into eight 4-bit fields. this register contains the results of certain arithmetic operations and provides a way for testing and branching. the xer register indicates overflows and carry conditions for integer operations. the lr register and the ctr register are like the gprs, their size depends on the implementation. the lr supplies the branch target address for the br anch conditional to link registers instructions. the ctr holds a loop count that can be decremented during execution of appropriately coded branch instructions. the time base facility consists of a 64-bit reg ister, divided in two 32-bit registers, time base upper (tbu) and time base lower (tb l). these registers will be used in a future laboratory, where you will learn more about them. ? powerpc instruction set the powerpc instruction set is very powerful and extensive. it contains around 200 in structions, excluding suffices. we dont have the space to cover all of them. for now, we are going to work with the integer arithmetic, load and store, and flow control instructions. a general description
34 of the format of the instructions will be given. more information can be obtained from the powerpc programming references. integer instruction set (a) integer arithmetic instructions you can add, subtract, multiply, and divide integer numbers. you can use imm ediate values and registers. also, register to register instructions are available. a general description of the format of the instructions follows. 1. immediate values opcode rd, ra, simm - where rd is the destination register, ra is the source register and simm is a signed immediate value. 2. register to register opcode rd, ra, rb - where rd is the destination register and ra and rb are the source registers. (b) integer compare instructions these instructions can be used in conjunction with the branch instructions to control the flow of a program. they affect the cr, such that the branch instructions can choose their target address based on what happened in the previous instruction. of course, t hey could be used only for comparing. 1. immediate values opcode ra, simm - where ra is the register you want to compare to a signed immediate value 2. register to register opcode ra, rb - where ra is the register you want to compare to register
35 rb load and store instruction set load and store instructions allow data m ovement between memory and register locations. they have t hree addressing modes. in anyone of them, if you use r0, the address calculation will use zero instead of the value in ra. (a) register indirect with immediate index addressing opcode rd, simm(ra) - if loading t hen rd is the destination reg ister. it will con- tain the value that is stored in the memory address that is the sum of simm and the value in the register ra. if storing then the memory address that is the sum of simm with the value in register ra, will contain the value stored in register rd. (b) register indirect with index addressing opcode rd, ra, rb - if loading then rd is the destination register. it will contain the value that is stored in the memory address that is the sum of the value in register ra and the value in the register rb. if storing then the memory address that is the sum of the value in register ra with the value in register rb, will contain the value st ored in register rd. (c) register indirect addressing opcode rd, ra - if loading t hen rd is the destination reg ister. it will contain the value that is stored in the memory address that is the value in the register ra. if storing then the memory address that is the value in register ra will contain the value stored in register rd.
36 branch instructions set these instructions are commonly used with compare instructions. you place the branch after the com- pare, using the result of it to make the decision. opcode label - where label is the address of the code where you want to branch to. the assembler takes care of translating the label to the address. ? metaware assembler directives the assembler directives are instructions to the assembler on how to configure data and w here to put the code and data in memory. the most useful are: (a) .text C identifies where the code section starts. (b) .data C mark the start of the data section (c) .word C reserves space for a word in memory (d) .org

C starting address of the following code and/or data (e) .global C makes this routine a public one. you can put comments in any line, but they must begin with a !. in addition, you can use l abels for branching. they must end with a semicolon and must be at the beginning of the line, with or without code in the same line. ? metaware assembly compilation for compiling your code using met aware, you must go through two steps. first compile the code using asppc , the metaware assembler. asppc ? filename.o filename.s the extension of yo
37 ur file must be *.s. in this way the assembler recognizes the file. the Co option tells the assembler the name of the object file. if you dont use it, the default name is the same as the code file with *.o as the extension. the second step is to convert the object to m otorola s3 record and to set again the address of the code and data section. elf2hex ? .text:0x70000,.data:0x70100 ? filename.hex ?m filename.o the Cp option is used to tell where the section of the file starts in memory. in this case, .text section will start in address 0x70000 and the .data section in 0x70100. the Co option is the name of the output file. the Cxm tells the program to generate a m otorola s3 record and filename.o is the file of the object file. procedure: 1. write an assembly language routine that multiplies 2 3x3 matrices. remember: = ? ij i i j j ij i i j j ij i i j j c c c c c c c c c b b b b b b b b b a a a a a a a a a ... ... ... ... .. ... ... ... ... ... ... .. ... ... ... ... ... ... .. ... ... 2 1 2 22 21 1 12 11 2 1 2 22 21 1 12 11 2 1 2 22 21 1 12 11 di mens i on. matr i x t h e i s n w h ere , * ... * * 2 2 1 1 nj in j i j i ij b a b a b a c + + + = hint: set the start of the matrices in memory, so you know where the code has to look for the data. also, make it flexible, so you can change the size of the matrices without making changes in your code.
38 references: [1] motorola, powerpc microprocessor family: the p rogramming environments for 32-bit microprocessors, mpcfpe32b/ad, rev 1, 1/97. suggested code: !file "matmult.s" ! assembly language program to multiply 2 3x3 matrices ! emr 990321 ! ! register usage: ! r9 ?pointer to start of data section ! r12 ?miscellaneous ! r5 - i ! r10 ?j ! r11 ?k ! r7 - pointer to row in matrix ! r8 - pointer to column in matrix ! r5 - holds temporary result of calculations !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! code section ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! .org 0x60000 .text .global mat_mult mat_mult: addic r5, r0, 0 !clear r5 lis r9, 6 !load immediate shifted to r9 addi r9, r9, 208 !pointer to data section lwz r12, 108(r9) !load n cmpw r5, r12 !if r5>=r12 then ... bge exit !goto exit, else ... another_i: addi r10, r0, 0 !clear r10 lis r9, 6 !load immediate shifted to r9 addi r9, r9, 208 !pointer to data section lwz r12, 108(r9) !load n cmpwi r12, 0 !if r12<=0 then ... ble incr_i !goto incr_i, else ... another_j: addi r11, r0, 0 !clear r11 lis r9, 6 !load immediate shifted to r9 addi r9, r9, 208 !pointer to data section
39 lwz r12, 108(r9) !load n cmpwi r12, 0 !if r12<=0 then ... ble incr_j !goto incr_j, else ... another_k: mulli r7, r5, 12 !pointer to row of a using i slwi r12, r11, 2 !pointer to col of a using k add r12, r12, r7 !pointer to aik lis r9, 6 !load immediate shifted to r9 addi r9, r9, 208 !pointer to data section lwzx r6, r12, r9 !load aik to r6 mulli r12, r11, 12 !pointer to row of b using k slwi r8, r10, 2 !pointer to col of b using j add r12, r8, r12 !pointer to bkj add r12, r12, r9 !add start address of data section lwz r12, 36(r12) !load bkj mullw r6, r12, r6 !aik*bkj add r12, r8, r7 !r12=i+j add r8, r12, r9 !pointer cij lwz r12, 72(r8) !load cij add r12, r12, r6 !cij+=aik*bkj stw r12, 72(r8) !store cij incr_k: addi r11, r11, 1 !increment k lwz r12, 108(r9) !load n cmpw r12, r11 !if r12>r11 then ... bgt another_k !goto another_k, else ... incr_j: addi r10, r10, 1 !increment j lis r9, 6 !load immediate shifted to r9 addi r9, r9, 208 !pointer to data section lwz r12, 108(r9) !load n cmpw r12, r10 !if r12>r10 then ... bgt another_j !goto another_j, else ... incr_i: addi r5, r5, 1 !increment i lis r9, 6 !load immediate shifted to r9 addi r9, r9, 208 !pointer to data section
40 lwz r12, 108(r9) !load n cmpw r5, r12 !if r5 41 troubleshooting: if the student is not able to: ? get started. suggest that the student code the multiplication in a c program until they have proven their algorithm. if t hey are s till having difficulty, the disassembly of the c program could provide insight.
42 linking assembly language and c code problem statement: ? this experiment introduces the student to linking pow erpc assembly l anguage and c c ode. (contributed by eisen montalvo-ruiz) objectives: upon completion of this laboratory experience, students will be able to: ? call an assembly routine from a c/c++ program ? know the powerpc function-calling sequence background information: the following information is excerpted directly from c hapters 10 and 11 of the high c/c++ programmers guide for powerpc. this document can be obtained from m etware through their website. ? making an assembly routine callable from a c program to be able to call an assembly language routine from a c program you must insert this piece of code before the assembly routine: .text .align 2 .global name name: you are going to use name to call the routine from a c program. experiment 8
43 ? calling an assembly routine from c for each assembly function you want to call, you have to declare it external. then use the pragma directive alias for linking the internal name to the external name. the following code should make it clearer: extern foobar(); #pragma alias(foobar,?ame?; ... void main() { ... foobar(); ... } ? function-calling sequence one of the most difficult parts of assembly language programming is parameter passing in function calls. fortunately, the powerpc function-calling and parameter passing is among the easiest one in the realm of assembly programming. here goes a brief description of this process. if you want more infor- mation, read the books in the reference section. stack-frame layout figure 7.1 shows the memory stack frame organization for the powerpc system. every function needs to establish their stack frame, but the stack frame is only necessary if the function is going to call an- other function.
44 figure 7.1 standard stack frame back-chain word floating-point register save area gene ral register save area c onditional register save area fpscr save area local variable space (padding allowed here only) parameter list area link register save word back-chain word high address low address stack grows down stack pointer stack fr ame header stack frame of the most recently called function the stack frame grows downward from high to low memory address, and is 16-byte aligned. it doesnt have a m aximum size but it has a m inimum. the m inimum st ack frame consists of the stack-frame header, with padding to a 16-byte alignment. any padding must occur w ithin the l ocal variable area. the st ack pointer points to the back-chain word of the most recently called f unction. this forms a linked list of stack frames. the stack frame can include the following areas as required by any function: floating-point register save area C non-volatile floating-point registers modified general register save area C non-volatile general registers modified cr save area C condition register fields modified fpscr save area C floating-point status and control register bits modified local variable space C local variables of function not mapped to registers
45 parameter list area C allocated by the caller of function; must be l arge enough to contain the argu- ments that the caller stores in it lr save word C contents of the link register as they were at the time of entry to a function back-chain word C pointer to the previous stack frames back-chain word the parameter list area is not preserved across function calls and it must follow the stack frame header immediately. register usage table 7.1 contains the usage and status of the registers in the function calling process. non-volatile registers belong to the calling function. if the called function wants to use them, it must save their values before using the registers and restore them before returning. volatile registers are not preserved across function calls, so you can use them without saving them. also you cant use the dedicated and reserved registers. you can corrupt the system if you use them. table 7.1 powerpc register usage register name status usage r0 volatile language-specific purposes r1 dedicated stack frame pointer, always valid r2 dedicated reserved for system use r3-r4 v olatile parameter pa ssing and return values r5-r10 v olatile parameter passing r11-r12 v olatile language-specific purposes r13 reserved small data area pointer r14-r30 non-volatile l ocal variables r31 non-volatile local variables or environment pointer f0 volatile language-specific purposes f1 volatile parameter pa ssing and return values f2-f8 v olatile parameter passing f9-f13 v olatile scratch f14-f31 non-volatile l ocal variables
46 cr0 cr1 cr2 cr3 cr4 cr5 cr6 cr7 volatile volatile non-volatile non-volatile non-volatile volatile volatile volatile condition register fields, each four bits wide (bit 6: floating-point invalid operation excep- tion) lr volatile link register ctr volatile count register xer volatile f ixed-point exception register fpscr0-23 fpscr24-31 volatile modifiable floating-point status and control register (exception-enable and rounding-control bits) parameter passing a maximum of eight integer arguments can be passed in general purpose registers r3 through r10 and a maximum of eight floating-point arguments can be passed in f1 through f8. if the number of parameters is less than the maximum, the unneeded registers contain undefined values. if the parameters passed do not fit in those registers, the function must allocate a stack frame. it should allocate the m inimum space needed for the parameters that do not fit in the registers. if the function wants to return a value, the table 7.2 shows how they can be p assed, according to their type. table 7.2 powerpc function return values function return t yp e return in regis- ter comment float double f1 int long enum short char pointer to any type r3 returned as unsigned or signed int eger (as appro- p riate ) , zero- or si g ned-extended to 32 bits if necessary long long unsigned long r3 and r4 returned with the lower-addressed word in r3 and the higher-addressed word in r4
47 struct ( less than or e q ual to 8 bytes) union ( less than or e q ual to 8 bytes) r3 and r4 it is returned as if the following steps had oc- curred: 1- the struct or union was first stored in an 8-byte aligned memory area. 2- the low -addressed word was loaded into r3 3- the hi g h-addressed word was loaded into r4 long double struct (g reater than 8 bytes) storage buffer the address of this buffer is p assed as a hidden argument in r3 ? metaware compiling when you are combining assembly and c, you cant compile like you did in the last laboratory. this is an example of compiling c and assembly using hcppc, the metaware c/c++ compiler. hcppc -hppc603 -hldopt=-e,main -hldopt=-b,start_addr=70000 -hldopt=-x -hldopt=-m c_code.c assembly_code.s the option Chppc603 tells the com piler to generate pow erpc 603 code. the Chldopt are options passed to the linker. the value after the equal sign is the option and the value after the comma is the value of the option. for example Ce tells the linker what function is the starting point in the code. in this example, the starting point is the main function. the Cb has a lot of values. one of the most use- ful is start_addr. it tells where the code starts in memory. in this example, the code starts at 0x70000. the Cm generates a map list file of the code. the standard output is the screen. you can use redirec- tion to send the output to a file. and finally the Cx tells the linker to generate m otorola s3 records, ready to be downloaded to the excimer board. the last parameters are the filenames of the c and as- sembly code. the output code will be named a.hex. procedure: 1. write an assembly l anguage routine that multiplies two n x n matrices and a c l anguage program that asks the user for the size of the matrices, their initial values and shows the resulting matrix. the c program should call the assembly routine. hint: you can use the assembly routine you m ade in the last laboratory. if you followed the hint in that laboratory, you shouldnt need to make too many changes.
48 references: [1] motorola, powerpc microprocessor family: the p rogramming environments for 32-bit microprocessors, mpcfpe32b/ad, rev 1, 1/97. suggested code: /* file matrixmult.c c program that calls an assembly routine. it asks the user for the size and initial values for the matrices and then shows the results of their multiplication. emr 990407 */ #define scanf my_scanf /* useful functions */ #define getchar dink_get_char #define putchar dink_write_char #define printf dink_printf void my_scanf(char *, int *); /* pointers to functions in dink memory */ unsigned long (*dink_get_char)() = (unsigned long (*)()) 0x1e4c4; unsigned long (*dink_write_char)(char) = (unsigned long (*)(char)) 0x5eb4; unsigned long (*dink_printf)() = (unsigned long (*)()) 0x6270; /* assembly routine */ extern matrixmult(int size, int *result, int *mata, int *matb); /* alias(internal name, external name) #pragma alias (matrixmult,"matmult") int *mata; /* first matrix */ int *matb; /* second matrix */ int *matc; /* resultant matrix */ int size; /* matrices size */ int *malloc(unsigned int); /* memory allocation function proto*/ void main() { int i, l; int temp; /* ask the user for the size */ printf("enter size of matrices > "); scanf("%d",&size); printf("\n"); /* separate memory for the matrices */ mata = malloc(size*size); matb = malloc(size*size); matc = malloc(size*size);
49 /* ask user for initial values */ for(int j=0; j 50 } } /* user input function */ /* by chuck corley */ void my_scanf(char *fmt, int *v) { char ch; int no_runs = 0; while ((ch = getchar()) != 0xd) /* carriage return? */ { if ( (ch == 0x7f) || (ch == 0x8)) /* delete? */ { putchar(0x8); /* backspace */ putchar(0x20); /* overprint a space. */ putchar(0x8); /* backspace */ /* assume modulo arithmetic to subtract last digit added. */ no_runs = no_runs / 10; } else if ( (ch >= '0') && (ch <= '9')) /* a digit? */ { putchar(ch); /* echo it and */ /* accumulate the value. */ no_runs = (no_runs * 10) + (ch - 48); /* ascii character - 48 equals the digit. */ } } *v = no_runs; /* assign second arg the value. */ } /* memory allocation function */ /* by chuck corley */ int *malloc(unsigned int size) { static int buffer[2048]; static int *next = buffer; int *p = next; next += ((size + 7) & ~7); if (next >= buffer + sizeof(buffer)) /* terminate by executing a zero. */ asm(".long 0"); return p; } !file "matmult.s" ! assembly language program to multiply 2 3x3 matrices ! emr 990407 ! ! parameters: ! r3 = size ! r4 = pointer to matrix c ! r5 = pointer to matrix a ! r6 = pointer to matrix b ! ! register usage: ! r14 = i ! r15 = j
51 ! r16 = k ! r17 = temp ! r18 = offset to current value of cell in matrix a ! r19 = offset to current value of cell in matrix b ! r20 = offset to current value of cell in matrix c !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! code section ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! .org 0x60000 .text .align 2 .global matmult matmult: xor r14, r14, r14 !clear r14 xor r17, r17, r17 !clear r23 cmpw r14, r3 !if i>=size then ... bge exit !goto exit, else ... another_i: xor r15, r15, r15 !clear j another_j: xor r16, r16, r16 !clear k another_k: mullw r18, r14, r3 !offset to row of a using i add r18, r18, r16 !offset to col of a using k slwi r18, r18, 2 !multiply by 4, we?e loading words, not bytes lwzx r18, r5, r18 !load aik to r21 mullw r19, r16, r3 !offset to row of b using k add r19, r19, r15 !offset to col of b using j slwi r19, r19, 2 !multiply by 4, we?e loading words, not bytes lwzx r19, r6, r19 !load bkj to r22 mullw r17, r21, r22 !aik*bkj add r23, r23, r17 !cij+=aik*bkj incr_k: addi r16, r16, 1 !increment k cmpw r16, r3 !if k 52 blt another_j !goto another_j, else ... incr_i: addi r14, r14, 1 !increment i cmpw r14, r3 !if i 53 converting integers to floating point problem statement: ? this experiment requires the development of an assembly language subroutine to convert the 64 bit integer value read from the powerpc time base facility to a 64 bit (double) floating point number representing seconds. (contributed by chuck corley, motorola) objectives: upon completion of this laboratory experience, students will be able to: ? write and assemble an assembly language subroutine ? call the assembly language subroutine from a c program and use the values returned ? convert integer numbers to powerpc floating point representation ? convert time base count values to seconds of wall clock time background information: the powerpc architecture requires each microprocessor implementation to provide a time base facility (tb), a 64-bit structure that consists of two 32-bit registers C time base upper (tbu) and time base lower (tbl). user l evel applications are perm itted read-only access to the tb which is useful for timing program execution or providing a time reference. the update frequency of the time base is sys- tem-dependent so the algorithm for converting the current value in the time base to time of day is also system-dependent. the mpc603e microprocessor used on the excimer board increments the tb at one-fourth the sysclk (bus) frequency. excimer does not have a real time clock chip as would be found on most computers. tbu and tbl are cleared at each pow er-up (or they can be set to an initial value in supervisor m ode). the tb facility
54 then counts up at one-fourth of sysclk frequency from this initial value. excimer cannot relate a tb value to real time without user assistance C like setting a watch. sysclk is crystal controlled to 66.6666mhz (see the oscillator on the board at u15), therefore tbl increments 16,666,667 times per second. when tbl exceeds 2 32 , a carry-out bit increments tbu. thus, tbu will increment every 257.7 seconds and the total range of the tb is 1.1x10 12 seconds or approximately 35,000 years. this number is better represented in application programs as a floating point value. the powerpc architecture represents double precision floating point values in the 64-bit format shown in figure 1. figure 1. floating-point double-precision format where ? s (sign bit) ? exp (exponent + bias) ? fraction (fraction) for numeric values, the significand consists of a l eading im plied bit concatenated on the right with the fraction. for normalized numbers (it is unnecessary to deal with denormalized floating point numbers in this excercise) the im plied bit is a one and is the first bit to the left of the binary point. normalized numbers are interpreted as follows: norm = (-1) s x 2 (exp - 1023) x (1.fraction) the range covered by the magnitude (m) of a normalized double-precision floating-point number is ap- proximately: 2.2x10 -308 m 1.8 x 10 308 the double precision exponent is biased by adding 1023 so that positive and negative exponents can be represented without a sign bit for the exponent. example exponents are shown in table 1. s exp fraction 0 1 11 12 63
55 biased exponent (binary) unbiased exponent (double-precision) 111_1111_1111 reserved for infinities and nans 111_1111_1110 +1023 111_1111_1101 +1022 .. 100_0000_0000 1 011_1111_1111 0 111_1111_1110 -1 .. 000_0000_0001 -1022 000_0000_0000 reserved for zeros and denormalized numbers table 1. biased exponent format examples of tb integer values converted to double precision floating point representation are shown in table 2. since it would take 35,000 years to test a conversion program for the upper lim its of the tb, this experiment should include a test program that supplies these example values to an integer-to- floating point assembly-language conversion routine and verifies that the correct floating point value is returned. the last column of table 2 shows the floating point value of the tb converted to seconds given excimers 66mhz bus clock. tb count (decimal) tbu (hex) tbl (hex) s exp biased (dec) fraction (hex) dp floating pt value ( hex) seconds (dec) 0 0000_0000 0000_0000 0 0 0_0000_0000_0000 0000_0000_0000_0000 0.00 1 0000_0000 0000_0001 0 +1023 0_0000_0000_0000 3ff0_0000_0000_0000 6.00e-8 2 0000_0000 0000_0002 0 +1024 0_0000_0000_0000 4000_0000_0000_0000 1.20e-7 524,288 0000_0000 0008_0000 0 +1042 0_0000_0000_0000 4120_0000_0000_0000 3.15e-2 1.57e6 0000_0000 0018_0000 0 +1043 8_0000_0000_0000 4138_0000_0000_0000 9.44e-2 3.67e6 0000_0000 0038_0001 0 +1044 c_0000_8000_0000 414c_0000_8000_0000 2.20e-1
56 1.67e7 0000_0000 00fe_502b 0 +1046 f_ca05_6000_0000 416f_ca05_6000_0000 1.00 3.22e9 0000_0000 c000_0401 0 +1054 8_0000_8020_0000 41e8_0000_8020_0000 1.93e2 1.29e10 0000_0003 4000_5001 0 +1056 a_0002_8008_0000 4208_0002_8008_0000 7.73e2 1.58e16 0038_0001 4001_0005 0 +1076 c_0000_a000_8002 434c_0000_a000_8002 9.46e8 1.84e19 fedc_ba98 7654_3210 0 +1086 f_db97_530e_ca86 43ef_db97_530e_ca86 1.10e12 table 2. example tb to floating point conversions procedure: 1. write an assembly l anguage routine which accepts two unsigned integer arguments tbu and tbl and returns a double float value. suggestion: assembly language routines are used primarily for speed (or access to hardware resources that are ot herwise not available). to make this routine faster, try using static branch prediction. for example, a tb value of zero has to be tested as a special case to form exp but is unlikely. likewise, values over 2 52 are unlikely (why would there be a conditional branch for this value?) hint: you may find the assembly language instructions cntlzw and rlwnm very useful. 2. write a c program which calls the assembly l anguage routine with the example values of table 2 and check that it returns the correct floating point value. reminder: dink version 10.5 provides a dink_printf routine that may be used to print results to the terminal. however, it will not format floating point numbers; results will have to be displ ayed as two unsigned long int values. is there a c construct which will permit viewing two 32- bit memory locations as both unsigned long int and double ? 3. write an assembly language routine that reads excimers tb facility and, using excimers bus clock speed of 66.6666mhz, returns seconds as a double-precision floating point number. caution: tb must be read in two separate instructions. it is unlikely, but possible, that tbu could increment between reading these two registers. consider the sequence tbu = 0x0000_0000, tbl = 0xffff_ffff; tbu = 0x0000_0001, tbl = 0x0000_0000. what would be the error if your as- sembly language routine got the first value of tbu and the second value of tbl? would r eading the registers in reverse order avoid this problem? suggestions: this assembly language routine may be useful in other programs. saving it in a standa- lone file timer.s and t hen linking it with this or other c programs will make it more useful. a header file, e.g. excimer.h, might be a convenient place to define constants like excimer_bus_speed that could change on other powerpc systems.
57 4. write a c program which outputs a zero to twenty second count to the terminal emulator and time it with a stopwatch. (u sing dink_printf to display seconds as integer decimal num bers is ac- ceptable). references: [1] motorola, powerpc microprocessor family: the p rogramming environments for 32-bit m icro- processors, mpcfpe32b/ad, rev 1, 1/97. suggested code: /* file "excimer.h" */ /* header file for excimer-unique constants */ /* excimer oscillator (u15 on pwb) runs at 66.6666mhz */ #define bus_frequency 66666667 /* tb ticks/sec at excimer bus clock. */ double tics_per_sec = bus_frequency/4; /* bus frequency as an integer in mhz. */ int ibus_mhz = bus_frequency/1000000; /* excimer does not support . dink has it's own print routine * called dink_print which supports a limited number of format types (decimal-%d, * hex-%x, string-%s, etc). redefining printf to point to the dink_print * function, enables standard c programs downloaded to excimer to print to the * terminal. the address of dink_print is available from the symbol table command * (symtab) in dink. if the version of dink on excimer is updated from the motorola * website at http:\\www.mot.com\powerpc\teksupport the address of dink_print must * be updated here. */ #define printf dink_print unsigned long (*dink_print)() = (unsigned long (*) ()) 0x6368; /* file "exercise.h" * header file for common typedefs for exercise? chuck corley 981218 */ struct tb_view { unsigned long tbu_view; unsigned long tbl_view; }; union dpfp_view { struct tb_view tb_fpasgpr_view; double tb_fp_view; }; struct test_struct { struct tb_view tb_gpr_view; union dpfp_view tb_fp_test;
58 }; !file "dtime.s" (for metware high c/c++ compiler/assembler) ! assembly language routine to convert 64-bit powerpc tb facility to ! double-precision, floating-point number. (plus additional routines for ! testing.) cjc 981216 ! register usage: ! r3 = fpu (upper 32 bits of floating point value) ! r4 = fpl (lower 32 bits of floating point value) ! r5 = tbu(time base upper - read from spr or loaded for test) ! r6 = tbl(time base lower - read from spr or loaded for test) ! r7 = leading zeroes in a register or shift count of +/-(zeroes - 11) ! r8 = accumulator for final exponent value of dpfp number ! r9 = shift count of 32 - n where n = +/-(zeroes -11) ! r10 = constant register of 11 ! r11 = link register storage #define tbu 269; !special purpose register numbers for tb #define tbl 268; .data local_storage: .double 0 .text .global dtime .global get_hid1 .global conversion_test !for codewarrior: !asm double conversion(double tics) conversion: cntlzw r7,r5 !find leading zeroes in tbu. preserve in r7. addi r9,r0,32 !will need a 32 in several places. create one in r9. addi r10,r0,11 !create a constant in r10 = 11. subf. r8,r7,r9 !r8 will hold exp. currently (32 - leading zeroes) beq+ tbu_is_zero !tbu never got incremented? (zeroes=32?) (most likely) subf. r7,r10,r7 !no. is tb more than 2^^52? (zeroes<11?) r7 = (z-11) add r8,r8,r9 !final exponent will be (64 - 1 - leading zeroes). bge+ tbu_lt_8yrs !if tb>2^^52, shift tbu bits right. (not likely) tbu_gt_8yrs: !for z<11: fpu = tbu>>n=(11-z); !fpl = tbu<>n=(11-z); neg r7,r7 !rlwnm shift count of (11-z) = -(z-11) = n = r7. subf r9,r7,r9 !rlwnm shift count of 32-n = 32 - (11-z) = r9. rlwnm r3,r5,r9,12,31 !shift tbu right n = (11 - z). mask off [0:11]. rlwnm r4,r5,r9,0,10 !shift remaining tbu bits left n = 32-(11-z) rlwnm r6,r6,r9,0,31 !shift tbl right n = (11 - z) or r4,r6,r4 !or rest of tbu shifted left with tbl shifted right. b form_exponent !go bias the exponent and or into fpu. tbu_lt_8yrs: !for z>=11: fpu=tbu<>n=(32-(z-11)); !fpl=tbl< 59 beq- tbl_is_zero !entire tbl count exactly zero? (not likely) subf. r7,r10,r7 !no. is tb less than 2^^20? (zeroes < 11?) bge- tbl_lt_63ms !if not, will have to shift bits right. (most likely) tbl_gt_63ms: !for z<11: fpu = tbl>>n=(11-z); fpl = tbl<=11: fpu = tbl<<(z-11); fpl = 0; rlwnm r3,r6,r7,12,31 !shift tbl left n = (z-11). mask off bits 0-11. xor r4,r4,r4 !fpl = 0. b form_exponent tbl_is_zero: !for z=32 && z=32: fpu = fpl = 0; xor r3,r3,r3 !unlikely result that tb was zero. prepare to xor r4,r4,r4 !return all zeroes for the floating point value. b compute_seconds form_exponent: addi r8,r8,1022 !add dp bias (1023) -1 to the exponent rlwinm r8,r8,20,1,12 !biased dp exp will be (63-(leading zeroes in tb)+1023). or r3,r3,r8 compute_seconds: lis r5, local_storage@h ori r5, r5, local_storage@l stw r3, 0(r5) stw r4, 4(r5) lfd f2, 0(r5) !load back in as 64bit float fdiv f1,f2,f1 !divide by bus clock ticks per second blr !return time in seconds as double in fp1 ! routine passed sample values of tbu and tbl. returns fpu and fpl as ! unsigned long. !for codewarrior: !asm struct tb_view * conversion_test(unsigned long upper, ! unsigned long lower, double tics) conversion_test: or r5,r3,r3 !use test values of tbu and tbl passed in r3 and r4 or r6,r4,r4 !as substitutes for values read from tb. mflr r11 !save the return address. bl conversion !convert tbu and tbl into fpu and fpl mtlr r11 !return in r3 and r4 !for codewarrior: ! la r3,local_pointer(sp)!return a pointer to the fpu storage location. blr ! routine passed sample values of tbu and tbl. returns seconds as double. !for codewarrior: !asm double float_test(unsigned long upper, unsigned long lower, double tics) float_test: or r5,r3,r3 !use test values of tbu and tbl passed in r3 and r4 or r6,r4,r4 !as substitutes for values read from tb. mflr r11 !save the return address. bl conversion !convert tbu and tbl into fpu and fpl mtlr r11 !return as double in fpr1 blr ! routine reads the tbu and tbl. returns seconds as double. !for codewarrior:
60 !asm double dtime(double tics) dtime: read_tb: mfspr r5,tbu !get tbu. mfspr r6,tbl !get tbl. mfspr r7,tbu !get tbu again. subf. r7,r5,r7 !did it increment between reading tbu and tbl? bgt- read_tb !if so, read them again. (not likely) mflr r11 !save the return address. bl conversion !convert tbu and tbl into fpu and fpl mtlr r11 blr ! routine reads the hid1 (pll_cfg) register. returns in r3. get_hid1: mfspr r3,1009 !get hid1 register. blr /* file "test_program.c" * tests the operation of assy language routine to convert powerpc timebase * values from integer to dp floating point values. chuck corley 981214 */ #include #include "excimer.h" /* file of excimer board-specific constants */ #include "exercise.h" /* file of common typedefs for this exercise */ struct tb_view conversion_test(int, int, double); /* given bus freq, returns time in seconds. */ void main(void) { int i, max_examples; struct test_struct example[] = { /* consider - case1: z<11; case2: z>=11; case3: z<11; case4: z>=11; case5: z=z=32; */ /* case5: all leading zeroes. */ { 0x00000000, 0x00000000, 0x00000000, 0x00000000}, /* case4: single one to treat as implied bit. move from tb[32+31] to dpfp[11]. */ { 0x00000000, 0x00000001, 0x3ff00000, 0x00000000}, /* case4: single one to treat as implied bit. move from tb[32+30] to dpfp[11]. */ { 0x00000000, 0x00000002, 0x40000000, 0x00000000}, /* case4: single one to treat as implied bit. move from tb[32+12] to dpfp[11]. */ { 0x00000000, 0x00080000, 0x41200000, 0x00000000}, /* case4: fraction starting in tb[32+12]. move to dpfp[12:31]. */ { 0x00000000, 0x00180000, 0x41380000, 0x00000000}, /* case3: fraction starting in tb[32+11]. move to dpfp[12:32]. check dpfp[32]=1. */ { 0x00000000, 0x00380001, 0x414c0000, 0x80000000}, /* case3: fraction (one sec) starts tb[32+9]. move to dpfp[12:34]. dpfp[32:34]=6? */ { 0x00000000, 0x00fe502b, 0x416fca05, 0x60000000}, /* case3: fraction in tb[33:63]. fpu[12:31]=tbl[1:20]. fpl[0:10]=tbl[21:31]. */ { 0x00000000, 0xc0000401, 0x41e80000, 0x80200000}, /* case2: fraction-tb[31:63]. fpu[12]=tbu[31]. fpu[13:31]=tbl[0:18]. fpl[0:12]=tbl[19:31].*/ { 0x00000003, 0x40005001, 0x420a0002, 0x80080000}, /* case1: fraction-tb[11:63]. fpu[12:31]=tbu[11:30]. fpu[0]=tbu[31]. fpl[1:31]=tbl[0:30].*/ { 0x00380001, 0x40010005, 0x434c0000, 0xa0008002}, /* case1: tb[1:63]. fpu[12:31]=tbu[1:20]. fpl[0:10]=tbu[21:31]. fpl[11:31]=tbl[0:20].*/ { 0xfedcba98, 0x76543210, 0x43efdb97, 0x530eca86}, }; struct test_struct result; max_examples = sizeof(example) / sizeof(example[0]); for (i=0; i< max_examples; i++) { /* these printf formats are for the restrictive dink_print routine. */ printf("tbu= %x ", example[i].tb_gpr_view.tbu_view); printf("tbl= %x ", example[i].tb_gpr_view.tbl_view);
61 result.tb_fp_test.tb_fpasgpr_view = conversion_test (example[i].tb_gpr_view.tbu_view, \ example[i].tb_gpr_view.tbl_view, tics_per_sec); if ((result.tb_fp_test.tb_fpasgpr_view.tbu_view != \ example[i].tb_fp_test.tb_fpasgpr_view.tbu_view) || \ (result.tb_fp_test.tb_fpasgpr_view.tbl_view != \ example[i].tb_fp_test.tb_fpasgpr_view.tbl_view)) \ printf(" error!\n"); printf("fpu= %x ", result.tb_fp_test.tb_fpasgpr_view.tbu_view); printf("fpl= %x\n", result.tb_fp_test.tb_fpasgpr_view.tbl_view); /* this is not useful on excimer because we can't print the floating point result. it is a useful check in codewarrior on the mac. cjc*/ /* result.tb_fp_test.tb_fp_view = float_test(example[i].tb_gpr_view.tbu_view, example[i].tb_gpr_view.tbl_view, tics_per_sec); printf("fpr = %4.2e \n", result.tb_fp_test.tb_fp_view); */ }; return; } /* file "watch.c" * reads the powerpc time base facility on excimer and prints out a twenty * second count to the terminal emulator. chuck corley 981214 */ #include #include "excimer.h" /* file of excimer board-specific constants */ #include "exercise.h" /* file of common typedefs */ double dtime(double); /* given bus freq, returns time in seconds. */ unsigned long get_hid1(); /* returns hid1 register. */ void main(void) { double begin_time, current_time, delta_time = 0.0, seconds = 0.0; int int_seconds; unsigned long hid1_reg; printf("powerpc timer test.\n"); printf("beginning a twenty second count assuming bus speed of 66.67mhz.\n"); printf("please time me.\n"); printf("if your stopwatch time differs significantly from 20 seconds, \n"); printf("we can compute the actual bus speed.\n"); begin_time = dtime(tics_per_sec); for (int_seconds = -1; int_seconds <= 20; int_seconds++) /*countup to start.*/ { while (delta_time < 1.0) { current_time = dtime(tics_per_sec); delta_time = current_time - (int_seconds) - begin_time; } delta_time = 0.0; switch (int_seconds) { case -1 : break; /* delay to get stopwatch ready. */ case 0 : printf("start now!\n"); /* begin timing at zero seconds. */ break; case 1: printf("%d second\n", int_seconds); break;
62 default: printf("%d seconds\n", int_seconds); } /* end of int_seconds switch */ }; printf("if your time was not 20 seconds,\n"); printf("bus speed is (20 / your_time) * 66.67mhz.\n"); /* bonus exercise. given the bus speed, calculate the processor (core) speed.*/ hid1_reg = get_hid1() >> 28; /* move hid1[0:3] to [28:31] */ printf("hid1 indicates pll_cfg=%x.\n", hid1_reg ); printf("if bus=%dmhz, ", ibus_mhz); switch (hid1_reg) { case 0x4: /* pll_cfg = 0b0100 */ printf("core freq(2x)=%dmhz & ", 2*ibus_mhz); printf("vco freq(2x)=%dmhz\n", 2*ibus_mhz); break; case 0x5: /* pll_cfg = 0b0101 */ printf("core freq(2x)=%dmhz & ", 2*ibus_mhz); printf("vco freq(4x)=%dmhz\n", 4*ibus_mhz); break; case 0x6: /* pll_cfg = 0b0110 */ printf("core freq(2.5x)=%dmhz & ", (int)(2.5*(float)ibus_mhz)); printf("vco freq(2x)=%dmhz\n", 5*ibus_mhz); break; case 0x8: /* pll_cfg = 0b1000 */ printf("core freq(3x)=%dmhz & ", 3*ibus_mhz); printf("vco freq(2x)=%dmhz\n", 6*ibus_mhz); break; case 0xe: /* pll_cfg = 0b1110 */ printf("core freq(3.5x)=%dmhz & ",(int)(3.5*(float)ibus_mhz)); printf("vco freq(2x)=%dmhz\n", 7*ibus_mhz); break; case 0xa: /* pll_cfg = 0b1010 */ printf("core freq(4x)=%dmhz & ", 4*ibus_mhz); printf("vco freq(2x)=%dmhz\n", 8*ibus_mhz); break; case 0x7: /* pll_cfg = 0b0111 */ printf("core freq(4.5x)=%dmhz & ",(int)(4.5*(float)ibus_mhz)); printf("vco freq(2x)=%dmhz\n", 9*ibus_mhz); break; case 0xb: /* pll_cfg = 0b1011 */ printf("core freq(5x)=%dmhz & ", 5*ibus_mhz); printf("vco freq(2x)=%dmhz\n", 10*ibus_mhz); break; case 0x9: /* pll_cfg = 0b1001 */ printf("core freq(5.5x)=%dmhz & ",(int)(5.5*(float)ibus_mhz)); printf("vco freq(2x)=%dmhz\n", 11*ibus_mhz); break; case 0xd: /* pll_cfg = 0b1101 */ printf("core freq(6x)=%dmhz & ", 6*ibus_mhz); printf("vco freq(2x)=%dmhz\n", 12*ibus_mhz); break; case 0x3: /* pll_cfg = 0b0011 */ printf("pll in bypass!\n"); break; case 0xf: /* pll_cfg = 0b0011 */ printf("clock off! how can this be???\n"); break; default: printf("error - invalid pll_cfg!"); } /* end of hid1 switch */ return; }
63 conclusions: students should be able to note that: ? a 64-bit rotate instruction would be very useful but has to be synthesized in the 32-bit powerpc architecture. ? the powerpc embedded application binary interface (eabi) specifies how arguments are passed to an assembly language routine and values are returned. ? the syntax for assembly language programs varies widely among compiler/assembler vendors. ? the only way to pass data between the integer registers (gprs) and the floating point registers (fprs) on powerpc is by writing and reading to memory. ? with wise use of the register set, the memory access to pass information from the gprs to the fprs is the only memory access the assembly l anguage routine needs - thus improving perform- ance. troubleshooting: if the student is not able to: ? get started. suggest that the student code the conversion in a c program until t hey have proven their algorithm. if t hey are s till having difficulty, the disassembly of the c program could provide insight. ? get the desired returned values from function calls. this is a good opportunity to use breakpoints and examine the registers to determine how the expected value is being returned.
64 dhrystone benchmarking problem statement: ? in this experiment the student will adapt the popular dhrystone benchmark to execute on the ex- cimer board. objectives: upon completion of this laboratory experience, students will be able to: ? verify a popular industry metric of processor performance in embedded applications, dhrystone version 2.1 vax mips, for the powerpc 603e microprocessor on the excimer board. ? compare processor performance, as measured by d hrystone, to published values for other proces- sors. ? compare code generation and instruction s cheduling, and resulting performance, for several com- peting compilers on the dhrystone benchmark. ? substitute more highly optimized routines for the built-in or library functions provided by compiler vendors to improve performance. ? utilize the dtime function of experiment 4 to measure elapsed time for a benchmarks execution. background information: compararative performance of computers is a popular topic for computer scientists, computer archi- tects, and computer salesmen. many performance measurements, or benchmarks, have been used over experiment 10
65 the last several decades to compare various aspects of computer performance. some benchmarks in- volve running real applications, e.g. com piling the compiler or calculating a spr eadsheet, which are heavily dependent on the resources of a particular operating system. others are small synthetic benchmarks designed to be representative of the workload of a class of larger applications but which do no meaningful work and are easier to run across various operating systems and architectures. the dhrystone benchmark is a synthetic benchmark developed by reinhold p. wei cker of siemens- nixdorf in the early eighties. it was first published in "communications of the acm" vol. 27., no. 10 (oct. 1984), pp. 1013 - 1030. it is easily ported to many different operating environments and results for many computers are w idely published. for em bedded processors, w here operating system and system resources may be limited, it has been the most often quoted performance measure. it is popular because it provides one number C vax mips C that can be com pared quickly with other computers. (vax mips are calculated by dividing the number of times that the d hrystone benchmark completes in a second by the number of d hrystones per second performed by the now-ancient vax 11/780 from digital equipment corporation.) on the other hand, it is widely disparaged because it is so small that it fits entirely within the first l evel cache of most m odern m icroprocessors and compiler vendors soon made a game out of optimizing it to get ever-higher vax mips numbers. motorola publishes dhrystone 2.1 vax mips num bers for the powerpc 603e pr ocessor on the exci- mer board because the number is often requested. after the first loop through the benchmark, it resides entirely in the l1 cache of any powerpc microprocessor. at that point the performance varies linearly with frequency and the results reflect the efficiency of the micro-architecture and the effectiveness of the compiler in generating code to capitalize on it. motorolas published num bers are 1.41 vax mips per mhz. for an excimer board running at 133mhz (to keep it comfortably cool in a s till air environ- ment), that equates to 188 vax mips. the dhrystone benchmark (and numerous others) is available in its official source code via anonymous ftp to 'ftp.nosc.mil' in directory 'pub/aburto'. the ip address is: 128.49.192.51. instructions for exe-
66 cuting the benchmark and rules for execution are available t here as we ll. com parative results for many computers are available from the same site or from various news groups including 'comp.benchmarks'. procedure: 1. download the dhrystone version 2.1 benchmark from the ftp site. r ead the associated instruc- tions for compilation and execution. you will find that the benchmark calls the c library functions strcpy and strcmp inside the measurement loop and printf and scanf outside the measure- ment loop. you will also find that the benchmark calls a timer function dtime() that returns a count of seconds as a double floating point number. you will need to assemble and link the assembly lan- guage code from experiment 4 which reads the powerpc time base facility and converts the 64 bit integer value to time in seconds based on excimers 66mhz bus speed. reminder: function calls such as printf will have to be equated to dink_printf routine to print results to the terminal. dhrystone also queries the user via the scanf function for the number of times to run the benchmark. a scanf function using dinks getchar and writechar will have to be written and sub stituted or the number of times through the benchmark hard coded. if hard- coding the number of runs, be certain to use a variable instead of a constant, as a constant would change the benchmark inside the measurement loop. motorola makes no changes to the benchmark which would unfairly change the result when compared to other results. 2. compile the d hrystone source code files, link in the dtime() function, and execute the benchmark on the excimer board. compare your results to motorolas published numbers. hint: maximum performance will be obtained only when running entirely out of cache. if the sram access led on excimer is not out during execution t hen the program is not running entirely from the internal cache. dinks regmod command may be needed to enable the instruction and data cache (regmod hid0 to new value of 8000c000). a bug in early versions of dink may also r equire modifying the data memory mapping unit ( dmmu) to m ake the data accesses cacheable (regmod rbat1l to new value of 00000012). 3. examine the disassembled code. the strcmp library function offers one opportunity for perform- ance enhancement. many c libraries compare stri ngs one byte at a time. m otorola provides a li- brary of highly optimi zed functions including strcmp on their website at
67 http://www.mot.com/powerpc/teksupport. the assembly language for strcmp from this library is shown below. notice that when possible this function compares strings four bytes C a word C at a time, thus reducing memory (or in this case, cache) accesses by 75%. assemble and link this strcmp function in place of the stdlib function. did performance improve? #------------------------------------------------------------------ # copyright, motorola, inc. all rights reserved. this # software contains proprietary and confidential information of # motorola, inc. use, disclosure or reproduction is prohibited # without the prior express written consent of motorola, inc. #------------------------------------------------------------------ #------------------------------------------------------------------ # int strcmp(const unsigned char* source1, # const unsigned char* source2); # returns: # value < 0 if source1 < source2 # value = 0 if source1 = source2 # value > 0 if source1 > source2 #------------------------------------------------------------------ .set _eq,2 .set _cr0,0 .set _cr1,1 #aix# .toc #aix#t..strcmp: #aix# .tc ..strcmp[tc], strcmp[ds] #aix# .align 2 #aix# .globl strcmp[ds] #aix# .csect strcmp[ds] #aix# .long .strcmp[pr],toc[tc0],0 #aix# .globl .strcmp[pr] #aix# .csect .strcmp[pr] #aix#.strcmp: .sect .text .align 2 .extern strcmp strcmp: #nt# .reldata #nt# .globl strcmp #nt#strcmp: #nt# .long ..strcmp,.toc #nt# .text #nt# .globl ..strcmp #nt#..strcmp: # r0 = temporary # r3 = source1 pointer, result, mask for first words # r4 = source2 pointer # r5 = 0x80808080 # r6 = 0x01010101 # r7 = source2 word # r8 = source1 word # r9 = temporary # r10 = source1 pointer # r11 = temporary # r12 = index
68 # see if the two pointers are both word aligned. xor r0,r3,r4 rlwinm. r0,r0,0,30,31 addis r6,r0,0x0101 mr r10,r3 bne byte_by_byte # generate an initial index so the word containing the first byte # will be loaded. compute a mask to set all bits in the bytes # prior to the first in the words that are loaded. rlwinm r11,r3,3,27,28 li r3,-1 rlwinm r12,r10,0,30,31 subfic r11,r11,32 neg r12,r12 slw r3,r3,r11 # complete the setup for the word aligned loop. ori r6,r6,0x0101 lwzx r8,r12,r10 #le# lwbrx r8,r12,r10 or r8,r8,r3 # mask off unused bytes. slwi r5,r6,7 subfc r0,r6,r8 andc r9,r5,r8 lwzx r7,r12,r4 #le# lwbrx r7,r12,r4 and. r11,r0,r9 addi r4,r4,-4 addi r12,r12,4 or r7,r7,r3 # mask off unused bytes. bne source1_has_null word_loop: subfc. r3,r8,r7 bne words_differ lwzx r8,r12,r10 #le# lwbrx r8,r12,r10 subfc r0,r6,r8 andc r9,r5,r8 and. r11,r0,r9 addi r12,r12,4 lwzx r7,r12,r4 #le# lwbrx r7,r12,r4 beq word_loop source1_has_null: # we terminated the loop because r8 has a null byte. # shift both words right so the null byte is the lsb. # can't do this with cntlzw because of a borrow if the byte # preceeding the null has the value one. rlwinm. r10,r8,0,0,7 li r9,24 beq shift rlwinm. r10,r8,0,8,15 li r9,16 beq shift rlwinm. r10,r8,0,16,23 li r9,8 beq shift li r9,0 shift: srw r7,r7,r9
69 srw r8,r8,r9 subfc r3,r7,r8 blr words_differ: # we terminated the loop because the words differ but # r8 does not have a null byte. return 1 or -1 based # on the unsigned comparison. subfe r3,r3,r3 nand r3,r3,r3 ori r3,r3,1 blr byte_by_byte: # do strcmp a byte at a time. lbz r9,0(r3) lbz r0,0(r4) subfc. r3,r0,r9 bnelr byte_loop: cmpi _cr1,0,r9,0 beq _cr1,null_byte lbzu r9,1(r10) lbzu r0,1(r4) subfc. r3,r0,r9 beq byte_loop blr null_byte: mr r3,r0 blr references: [1] "communications of the acm" vol. 27., no. 10 (oct. 1984), pp. 1013 - 1030. suggested code: /* file - ?ry1.h * defines the functions defined in support.c and used by dhry21a.c */ #define printf my_printf #define fprintf my_fprintf #define fopen my_fopen #define fclose my_fclose #define exit my_exit extern int my_printf(const char *, ...); extern int my_fprintf(const char *, ...); extern file * my_fopen(); extern int my_fclose(); extern void my_exit();
70 /* file ?upport.c * this file provides substitutes for some of the library function calls * used in dhrystone which dink doesn? support. */ /* set the number of dhrystone loops here. */ #define number_of_runs 10000000 #include /* these are the magic addresses for the dink functions. */ unsigned long (*dink_printf)() = (unsigned long (*)()) 0x6638; /* a version of malloc that will only supply up to 2048 bytes total. */ char *malloc(unsigned int size) { static char buffer[2048]; static char *next = buffer; char *p = next; next += ((size + 7) & ~7); if (next >= buffer + sizeof(buffer)) /* terminate by executing a zero. */ asm(".long 0"); return p; } /* scanf is used only to read the number of times through the loop. */ /*argsused*/ void scanf(char *fmt, int *v) { *v = number_of_runs; } /* this only will handle the printf calls in dhrystone. the dink printf doesn't work for floating point, so convert the value here to integer. */ int my_printf(const char *fmt, ...) { int a1, a2, a3, sign; char *neg_zero_fmt; double round, fraction, val; va_list ap; va_start (ap, fmt); if (strcmp(fmt, "%7.1lf \n") == 0) {
71 fmt = "%6d.%1d \n"; neg_zero_fmt = " -%1d.%1d \n"; round = 0.05; fraction = 10.0; goto fake_float; } else if (strcmp(fmt, "%10.1lf \n") == 0) { fmt = "%9d.%1d \n"; neg_zero_fmt = " -%1d.%1d \n"; round = 0.05; fraction = 10.0; goto fake_float; } else if (strcmp(fmt, "vax mips rating = %10.3lf \n") == 0) { fmt = "vax mips rating = %9d.%03d \n"; neg_zero_fmt = "vax mips rating = -%1d.%03d \n"; round = 0.0005; fraction = 1000.0; fake_float: val = va_arg(ap, double); if (val < 0) { sign = -1; val = -val; } else { sign = 1; } /* round the value. */ val += round; a1 = val; a2 = val * fraction - a1 * fraction; if (a1 == 0 && sign == -1) fmt = neg_zero_fmt; a1 *= sign; } else { a1 = va_arg(ap, int); a2 = va_arg(ap, int); a3 = va_arg(ap, int); } dink_printf(fmt, a1, a2, a3); va_end (ap); } /* dummy out the calls to exit, fopen, fprintf, and fclose. */ void my_exit() {} int my_fopen() { return 1; }
72 int my_fprintf() {} int my_fclose() {} conclusions: students should be able to note that: ? there are lies, damn lies, and benchmarks, in that order. ? the dhrystone benchmark is small enough to understand, see opportunities for optimization, and port easily to various computer environments. ? the dhrystone benchmark is string intensive and the resulting performance metric may be m ean- ingless in applications i nvolving other workloads, e.g. extensive mathematical calculations or bit manipulation. ? not all compilers are created equal. the sample compilers shipped in the excimer kit may generate vastly different code, instruction s cheduling, and results on this benchmark. however, the bi ggest impact probably comes from the motorola hand-coded strcmp function. l ike most vendors, mo- torola strives to provide the best benchmark results possible for marketing reasons.. troubleshooting: if the student is not able to: ? get a time function. the suggested code for experiment 4 provides a double dtime(double tics_per_second) function which can be easily modified to provide timing information for this benchmark. ? link with the dink supplied printf or other functions. check the addresses for the respective functions in dink using the symtab command. ? get the results to print from the dhry21a.c program. di nk_printf will not accept floating point formats. the results will have to be typecast as unsigned long or int to print. the loss of accuracy is insignificant.
73 running the linpack benchmark (debugging stage) problem statement: ? in this experiment the student will adapt the popular linpack benchmark to execute on the excimer board. (contributed by walter guiot and luis narvez). objectives: upon completion of this laboratory experience, students will be able to: ? verify a popular industry metric of processor performance in em bedded applications, linpack, for the powerpc 603e microprocessor on the excimer board. ? compare processor performance, as measured by linpack, to published values for other processors. ? compare code generation and instruction s cheduling, and resulting performance, for several com- peting compilers on the linpack benchmark. ? compare processor performance, as measured by linpack, with performance given by the m anufac- turer. experiment 11
74 background information: linpack is a collection of subroutines used to benchmark the performance of computers in the analysis and solving of linear equations and linear least-squares problems. linpack solves linear sys- tems whose matrices are general, banded, symmetric indefinite, symmetric positive definite, triangular, and tridiagonal square. the linpack routines are constructed such that locality of reference is maxi- mized. a c language version can be obtained: http://www.netlib.org/benchmark/ . references: [1] david a. patterson, john l. hennessy, conputer organization & design the hardware / soft- ware interface morgan kaufmann publishers, inc san francisco, california 1994. [2] http://www.netlib.org/linpack/ [3] the linpack benchmark: http://www.netlib.org/benchmark/top500/reports/report93/section2_16_2.html procedure: 1. download the linpack benchmark from ftp sites such as http://www.netlib.org/linpack or ftp://ftp.nosc.mil/pub/aburto . 2. read the included documentation regarding compaling instruction. 3. modify the source code to make it compatible with dink instructions such as dink_printf. remem- ber that dink_printf does not support floating point, a function will have to be developed to handle floating point, refer to experiment #5 for printf function for the dhrystone benchmark. 4. compile the source code and link it with the dtime() function develop in experiment #?. the file dtime.s developed in the experiment may be used. 5. get the powerpc 603e performance information from the manufacturer and compare it with the results obtained with linpack.
75 suggested code: ***this experiment is still in the ebugging phase as it is necessary to send floating point numbers to t h screen.*** !file "dtime.s" (for metware high c/c++ compiler/assembler) ! assembly language routine to convert 64-bit powerpc tb facility to ! double-precision, floating-point number. (plus additional routines for ! testing.) cjc 981216 (contributed by chuck corley, motorola) ! register usage: ! r3 = fpu (upper 32 bits of floating point value) ! r4 = fpl (lower 32 bits of floating point value) ! r5 = tbu(time base upper - read from spr or loaded for test) ! r6 = tbl(time base lower - read from spr or loaded for test) ! r7 = leading zeroes in a register or shift count of +/-(zeroes - 11) ! r8 = accumulator for final exponent value of dpfp number ! r9 = shift count of 32 - n where n = +/-(zeroes -11) ! r10 = constant register of 11 ! r11 = link register storage #define tbu 269; !special purpose register numbers for tb #define tbl 268; .data local_storage: .double 0 .text .global dtime .global get_hid1 .global conversion_test !for codewarrior: !asm double conversion(double tics) conversion: cntlzw r7,r5 !find leading zeroes in tbu. preserve in r7. addi r9,r0,32 !will need a 32 in several places. create one in r9. addi r10,r0,11 !create a constant in r10 = 11. subf. r8,r7,r9 !r8 will hold exp. currently (32 - leading zeroes) beq+ tbu_is_zero !tbu never got incremented? (zeroes=32?) (most likely) subf. r7,r10,r7 !no. is tb more than 2^^52? (zeroes<11?) r7 = (z-11) add r8,r8,r9 !final exponent will be (64 - 1 - leading zeroes). bge+ tbu_lt_8yrs !if tb>2^^52, shift tbu bits right. (not likely) tbu_gt_8yrs: !for z<11: fpu = tbu>>n=(11-z); !fpl = tbu<>n=(11-z); neg r7,r7 !rlwnm shift count of (11-z) = -(z-11) = n = r7. subf r9,r7,r9 !rlwnm shift count of 32-n = 32 - (11-z) = r9. rlwnm r3,r5,r9,12,31 !shift tbu right n = (11 - z). mask off [0:11]. rlwnm r4,r5,r9,0,10 !shift remaining tbu bits left n = 32-(11-z) rlwnm r6,r6,r9,0,31 !shift tbl right n = (11 - z) or r4,r6,r4 !or rest of tbu shifted left with tbl shifted right. b form_exponent !go bias the exponent and or into fpu. tbu_lt_8yrs: !for z>=11: fpu=tbu<>n=(32-(z-11)); !fpl=tbl< 76 b form_exponent !fpl with a mask of all zeroes in bits [32-(z-11):31]. tbu_is_zero: !z= 32 cntlzw r7,r6 !find leading zeroes in tbl. subf. r8,r7,r9 !exp = (32 - leading zeroes). beq- tbl_is_zero !entire tbl count exactly zero? (not likely) subf. r7,r10,r7 !no. is tb less than 2^^20? (zeroes < 11?) bge- tbl_lt_63ms !if not, will have to shift bits right. (most likely) tbl_gt_63ms: !for z<11: fpu = tbl>>n=(11-z); fpl = tbl<=11: fpu = tbl<<(z-11); fpl = 0; rlwnm r3,r6,r7,12,31 !shift tbl left n = (z-11). mask off bits 0-11. xor r4,r4,r4 !fpl = 0. b form_exponent tbl_is_zero: !for z=32 && z=32: fpu = fpl = 0; xor r3,r3,r3 !unlikely result that tb was zero. prepare to xor r4,r4,r4 !return all zeroes for the floating point value. b compute_seconds form_exponent: addi r8,r8,1022 !add dp bias (1023) -1 to the exponent rlwinm r8,r8,20,1,12 !biased dp exp will be (63-(leading zeroes in tb)+1023). or r3,r3,r8 compute_seconds: lis r5, local_storage@h ori r5, r5, local_storage@l stw r3, 0(r5) stw r4, 4(r5) lfd f2, 0(r5) !load back in as 64bit float fdiv f1,f2,f1 !divide by bus clock ticks per second blr !return time in seconds as double in fp1 ! routine passed sample values of tbu and tbl. returns fpu and fpl as ! unsigned long. !for codewarrior: !asm struct tb_view * conversion_test(unsigned long upper, ! unsigned long lower, double tics) conversion_test: or r5,r3,r3 !use test values of tbu and tbl passed in r3 and r4 or r6,r4,r4 !as substitutes for values read from tb. mflr r11 !save the return address. bl conversion !convert tbu and tbl into fpu and fpl mtlr r11 !return in r3 and r4 !for codewarrior: ! la r3,local_pointer(sp)!return a pointer to the fpu storage location. blr ! routine passed sample values of tbu and tbl. returns seconds as double. !for codewarrior: !asm double float_test(unsigned long upper, unsigned long lower, double tics) float_test: or r5,r3,r3 !use test values of tbu and tbl passed in r3 and r4 or r6,r4,r4 !as substitutes for values read from tb. mflr r11 !save the return address. bl conversion !convert tbu and tbl into fpu and fpl
77 mtlr r11 !return as double in fpr1 blr ! routine reads the tbu and tbl. returns seconds as double. !for codewarrior: !asm double dtime(double tics) dtime: read_tb: mfspr r5,tbu !get tbu. mfspr r6,tbl !get tbl. mfspr r7,tbu !get tbu again. subf. r7,r5,r7 !did it increment between reading tbu and tbl? bgt- read_tb !if so, read them again. (not likely) mflr r11 !save the return address. bl conversion !convert tbu and tbl into fpu and fpl mtlr r11 blr ! routine reads the hid1 (pll_cfg) register. returns in r3. get_hid1: mfspr r3,1009 !get hid1 register. blr conclusions: troubleshooting: 1. make sure you are using the correct address for the dink_printf function. 2. make necessary changes to handle floating point. 3. use the timer funciton develop in experiment #?, do not use any of the ones provided with the benchmark.
78 cache impact on benchmark metrics (debugging stage) problem statement: ? in this experiment the student will compare the linpack benchmark results with cache memory dis- abled to the results with cache memory enabled. (contributed by walter guiot and luis narvez). objectives: upon completion of this laboratory experience, students will be able to: ? compare processor performance, as measured by linpack, with and without cache enabled. ? understand the advantages of cache memory in a computer system. background information: cache memory is a special type of random access memory ( ram) that stores the most recently used instructions and/or data from a larger main memory system. cache memory can be accessed faster than regular ram. cache mem ory is categorized in levels. level i (l1) cache mem ory is on the same chip as the m icro- processor. level ii (l2) and later levels are usually separate memory chips. the microprocessor first looks for the instructions in l1 cache, if it is not there (a miss) it goes to the next level, it continues looking from level to level until reaching main memory or in the worst case a m ass storage device, such as disk drives or hard drives. these memory chips are typically static ram (sram) m odules that do experiment 12
79 not need to be electromagnetically refreshed as dram does. these characteristics make cache memory faster and more expensive than regular ram. there is a slight catch with cache memory, if there is a cache miss, then it takes around m ore clocks cy- cle to access data from dram, or rom. for this reason a l2 cache that is too sm all could theoreti- cally decrease performance. the 603e provides independent 16-kbyte, four-way set-associative instruction and data caches. the cache line is 32 bytes in length. the caches use a least recently used (lru) replacement policy. the caches provide a 64-bit interface to the instruction fetch unit and load/store unit. the surrounding logic selects, organizes, and forwards the requested information to the requesting unit. write operations to the cache can be performed on a byte basis, and a complete read-modify-write operation to the cache can occur in each cycle. the load/store and instruction fetch units provide the caches with the address of the data or instruction to be fetched. procedure: 1. develop an assembly program to enable and disable cache memory. refer to the powerpc 603e manual for the registers involve in enabling and disabling the cache. 2. follow the procedure of experiment #? running the linpack benchmark. 3. link the assembly code developed here to the code of experiment #?. 4. run the benchmark with cache enable and note the results. 5. disable cache and run the benchmark again, compare both results and state your conclusions. questions:
80 references: [1] the l2 company: what is cache? http://www.mindspring.com/~l2co/whatisca.html [2] what iscache memory? http://www.whatis.com/cachemem.htm [3] mpc603e & ec603e risc microprocessors users manual suggested code: troubleshooting: 1. make sure you are using the correct registers for enabling and dissabling cache. 2. refer to the troubleshooting to experiment #? running the linpack benchmark.
81 flash rom (debugging stage) problem statement: ? this experiment requires the development of an assembly language program starting on programmer space ram location $70000 that will copy a program which resides on ram location $71000 to a free space flash rom location. program copied into flash rom will auto-execute from its present location. (contributed by jos i. qui?ones and eisen montalvo-ruiz). objectives: upon completion of this laboratory experience, students will be able to: ? write and assemble an assembly language subroutine. ? execute a piece of code that will in turn copy another piece of code to flash rom and execute it. ? write assembly code directly into flash rom space by means of assembly code. background information: any microprocessor-based system needs memory devices to hold data and program in structions. memories can be classified as volatile and non-volatile. the basic difference between both realms of memories is that volatile memories looses its data contents when power is rem oved from the semiconductor chip while non-volatile mem ories holds its data con- tents even when power is rem oved. this has some very interesting implications, which must remain clear to microprocessor based system designers since both types of mem ory have their advantages and disadvantages as well as a typical use. experiment 13
82 non volatile mem ory is used when a system is to execute a dedicated application. take for example your computer. when you turn it on, it executes a self-initialization procedure we call booting. how does the cpu know what to do? the bios (binary input output system) is the dedicated application for initialization and is st ored on a non-volatile t ype of mem ory. if this program is by any m eans erased, the computer will just never be able to restart! once the computer starts, the application to be executed can be anything we decide. it would be quite expensive, and s pace prohibiting, to have all the applications we would like to have on a com puter stored on non-volatile silicon mem ory chips. instead we have found quite useful to store our applica- tions on magnetic or other type of media and then write them to a bank of volatile type of silicon mem- ory, which is fast and can cope with the microprocessor need for instructions to execute. this volatile memory can be written over and over repeatedly. and when power is no longer applied to the memory array, all information is forever lost. typical use of volatile memory, (such as ram) is to load operative systems (os) and any application you may want to execute on the computer. only the necessary instructions reside on ram. the os is responsible of loading the ram with the necessary instructions as they are needed. a disadvantage of non-volatile memory cells is that they have a short life and usually can not be rewrit- ten more than a specified number of times. they are also significantly slower than volatile memories. we have come to accept that there is a need and a use for both types of mem ory. this is why our ex- cimer board is equipped with 1 mb of ram, which is our volatile type of memory and 4mb of flash rom, which is our non-volatile memory. at this time you must be familiar with the fact that the excimer board has an operative system you can use, called the dink32. this monitor program is st ored on the flash rom and is responsible of
83 initializing all peripheral activity within the power pc 603e evaluation board. when you press reset, this dedicated application executes and it takes over the board. this monitor also enables the user to see and use all registers and memory space with commands such as mem ory display (md), register dis- play (rd) and so on. the monitor even has an online assembler and disassembler that enables the user to see code and to enter code manually. the excimer also needs ram to operate. that is, any variable and/or data must be w ritten to ram since this value may change continuously. so the 1 mb of ram provided is needed by the excimer to operate. fortunately for developers, this ram can also be loaded with applications trying to exploit the power em bedded on the 603e cpu. for testing and evaluation purposes, the ram will hold in- structions (which must be downloaded periodically with the help of a pc) that can be traced and watched using the dink32 tools. it is the ultimate goal of any engineer using an evaluation board such as the excimer, to create a free running application capable of self-supporting itself. in other words that an specified application such a control or embedded system may run without the need of a pc computer. this implies that the engi- neer code will always be present on the excimer board but it was only downloaded once. you are currently downloading the code every time you need to execute it. eventually you will reach a time when your code will be totally debugged. it would be really appropriate to make the evaluation board a stand-alone unit with your code as the dedicated application. it is the goal of this laboratory experiment to s how how to write the flash rom area so that a dedi- cated application may be coded in this non-volatile mem ory. the architecture of the suggested proce- dure is to write a simple program that writes another code into the flash rom. as a m ore advanced option, the writer program could set the reset vector to the address where it will begin writing the written code.
84 as a safety feature, so that dink32 is still available after the flash rom is updated, the written code is to ask the user if the application to be executed is dink32 or itself. the true dink32 pointer can be saved from the previous vector table. the program will now have the ability to either jump to the short code (which can be the led blinker code) or to the dink32. how to p rogram the flash rom: the excimer board has 4m bytes of fl ash rom where the dink32 monitor resides. nevertheless, user defined applications can be recorded on this memory space as long as some precautions are t aken. do recall that if the monitor is no l onger working, successive fl ash recording might not be as easy (or possible with existing hardware). the flash rom chips being int erfaced by the power pc 603e on our excimer board are amds am29lv800b 8 mbits memory modules. detailed information on how to erase and program the flash cells can be found in am29lv800b data s heet. some introductory information follows, but it is ad- vised to students to read the proposed application note. the amd flash rom chip already contains a control unit inside of each flash chip. all that is needed to erase, read or program a byte, sector or the entire chip is a set of comm ands which will put the chip into a predefined state. once the state is defined and the corresponding comm ands sent to the chip via the data bus, the internal control logic will do the rest. states which can be entered are: sector protect, sector unprotect, autoselect, erase sector, erase chip, erase suspend, erase resume, pro- gram, reset and unlock bypass device programming occurs by executing the program command sequence. this in itiates the embed- ded program algorithman internal algorithm that automatically times the program pulse widths and verifies proper cell margin. the unlock bypass mode facilitates faster programming times by requiring only two write cycles to program data instead of four. instead of using the common program command
85 (6 step command) you can now use the unlock bypass comm and sequence (refer to table 5 of the am29lv800b data sheet). device erasure occurs by executing the erase command sequence. this in itiates the embedded erase algorithman internal algorithm that automatically preprograms the array (if it is not already pro- grammed) before executing the erase operation. during erase, the device automatically times the erase pulse widths and verifies proper cell margin. the host system can detect whether a program or erase operation is complete by observing the ry/by# pin, or by reading the dq7 (data# polling) and dq6 (toggle) status bits . after a program or erase cycle has been completed, the device is ready to read array data or accept another comm and. the sector erase architecture allows memory sectors to be erased and reprogrammed wit hout affecting the data contents of other sectors. the device is fully erased when shipped from the factory. the am29lv800b data sheet explains all other mentioned states. also how to enter and exit the men- tioned modes of operation can be clearly seen on tables 4 and 5 of said document. but be careful. al- though amd is very specific in telling all addresses where specific data has to be written, the im ple- mentation of the excimer board did changed these parameters. the way the four flash rom chips were assembled on the excimer board (configured as a two mem- ory bank of double 16 bit words) redefines all addresses and expected data to and from the memory chips. first of all is the definition of the power pc 603e m icroprocessor data bus as big-endian while the flash rom data bus is a little-endian device. this m eans that what is the msb to the m icroproc- essor is actually the lsb to the flash rom! data has to be bit reversed (and that is as simple as mir- roring the 16 bit words) so that the flash rom understands. in other words whatever data the am29lv800b data sheet tells you to send to the flash, has to be bit reversed before it is actually sent.
86 note : this is actually the programmers job. programmer could develop a subroutine to mirror the word or else he/she could do it by hand before actually writing the assembly or c code. the other very important fact to have in mind is that the memory mapping suggests a 3 bit left shifting. that is (if observing the excimer im plementation schematic) the 3 less signifi cant b its are not used to select memory space inside the memory device itself (recall that pow erpc address bus is big-endian while amd flash devices are little-endian. that is why address lines a31, a30 and a29 are the ones not connected to the memory device. they are actually the less signifi cant address lines to the power pc 603e). these three address lines are in fact used by the excimer memory control fpga to select one of the four memory chips. that is why on the excimer im plementation schematic there is a differ- ent line for each one of the we* (write enables) control signals while cs* (chip s elect) and oe* (out- put enable) are shared. note: since the three less signifi cant address lines are used only for chip selection while program- ming, every address present on the am29lv800b data sheet (including comm and sequence as well as sector segregation) has to be shifted left by 3. the following are the required rules for the excimer v1 and v2 boards since the address line is shifted by three and the data lines are bit reversed. ? rule for converting from expected address (found on am29lv800b data sheet) to shifted address (excimer memory mapped) left shift address by 3, bit reverse data example: address 0x555 < 3 = 0x2aa8 (0b0101 0101 0101 < 3 = 0b0010 1010 1010 1000) ? rule for converting from bit not reversed (little endian to l ittle endian) to bit reversed (little en- dian to big endian). bit reverse the data line example: data 0xaa = 0x55 (0b1010 1010 = (bit reversed) 0b0101 0101)
87 on the following sequences, address and data has already been shifted as w ell as bit reversed. you should not have trouble if using these examples. do recall that you will need to make reference to the am29lv800b data sheet when trying to search for sectors and specific addresses. entering autoselect mode write address: 0x2aa8 with data: 0x55555555 write address: 0x1550 with data: 0xaaaaaaaa write address: 0x2aa8 with data: 0x09090909 get manufacturer id: read address: 0x0000 get data: 0x80008000 get device id: read address: 0x0008 get data: 0x5b445b44 get sector protect status for each sector: read address: 0x[sa] get data: 0x00000000 for non protected read address: 0x[sa] get data: 0x80008000 for protected reset sequence exit autoselect mode: write address: 0x0000 with data: 0x0f0f0f0f erasing a flash sector sequence: write address: 0x2aa8 with data: 0x55555555 write address: 0x1550 with data: 0xaaaaaaaa write address: 0x2aa8 with data: 0x01010101 write address: 0x2aa8 with data: 0x55555555 write address: 0x1550 with data: 0xaaaaaaaa write address: sector address with data: 0x0c0c0c0c programming flash memory: write address: 0x2aa8 with data: 0x55555555 write address: 0x1550 with data: 0xaaaaaaaa write address: 0x2aa8 with data: 0x05050505 write address: word address with data to be programmed now some notes : the flash rom device can change a one to a zero in any cell bit, but not visa versa. thus, it is a good practice to erase the memory first before writing to it. otherwise after writing, the memory may be corrupted, since a zero cant be changed back to a one. in some cases you can play with the byte to be recorded. if for example a cell has the byte 0x55 programmed on it and you want to
88 write 0x11, it can be done without erasing the cell. this is a good idea when there are only a few bytes to be programmed, but it would not be wise when programming large amounts of data. erasing can only be done one sector at a time or the entire chip, so one can not erase only a portion of a sector. the smallest amount of flash to erase is one complete sector. (refer to table 3 on the am29lv800b data sheet for sector addresses and remember to shift left by 3 any address). be careful when erasing a sector. there might be important code (as os code) on the sector. references: ? am29lv800b data sheet (www.amd.com) ? fl.c source code suggested code: two sets of code are available on this section. the first thing any student should try is to pr operly send comm ands to the flash rom chips. s ince writing or erasing may be hazardous to the excimer health, it is recommended that a few experiments are performed before any erasing or programming is attempted. this will allow the students to practice assembly language p rogramming to interface the ships not by using the data supplied by the am29lv800b data sheet but with the already shifted addresses and inverted data. the first code sni ppet shows how to enter autoselect mode. students will be able to check memory spaces for the specified data. if any method to memory display byte information shows the specified data (note inversion will be noted) the command sequence has been successful. otherwise, one or more steps might not be correct (check troubleshooting section for more information on possible errors). .text .global readflash readflash: xor r12, r12, r12 !clearing registers 12 and 13 xor r13, r13, r13
89 lis r12, 65472 !r12 contains $ffc00000 addi r12, r12, 8 !register12 contains address $ffc00008 !this address is used to request the autoselect mode data as !specified by the flash rom data sheet + a shift by 3. xor r14, r14, r14 !clearing register 14 lis r14, 65472 !register 14 contains $ffc00000 addi r14, r14, 10920 !register 14 contains $ffc02aa8 !this address is used to send the first step into the !autoselect sequence as specified by the flash rom data !sheet + a shift by 3. xor r15, r15, r15 !clearing register 15 lis r15, 65472 !register 15 contains $ffc00000 addi r15, r15, 5456 !register 15 contains address $ffc01550 !this address is used to send the second step into the !autoselect sequence as specified by the flash rom data !sheet + a shift by 3. xor r16, r16, r16 !clearing register 16 addi r16, r16, 170 !through this steps, the data $aaaaaaaa which will be slwi r16, r16, 8 !sent to the flash on the first step of the autoselect addi r16, r16, 170 !sequence, is assembled. note that bit reversal has been slwi r16, r16, 8 !accounted for. addi r16, r16, 170 slwi r16, r16, 8 addi r16, r16, 170 !register 16 contains data $aaaaaaaa xor r17, r17, r17 !clearing register 17 lis r17, 21845 !data $55555555 is assembled through this steps. this is addi r17, r17, 21845 !the data that will be sent on the second step of the !autoselect sequence. bit reversal has been taken care of. xor r18, r18, r18 !clearing register 18 addi r18, r18, 9 !data $09090909 is assembled through this steps. this slwi r18, r18, 8 !word is sent to the flash to differentiate the command addi r18, r18, 9 !sequence from all others. this data is specific to the slwi r18, r18, 8 !autoselect mode. addi r18, r18, 9 slwi r18, r18, 8 addi r18, r18, 9 !register 18 contains data $09090909 stwx r17, r14, r13 !store $55555555 data in $ffc02aa8 addi r14, r14, 4 !first sequence step taken care of. stwx r17, r14, r13 !it has to be written to both memory banks. stwx r16, r15, r13 !store $aaaaaaaa data in $ffc01550 addi r15, r15, 4 !second sequence step taken care of. stwx r16, r15, r13 !it has to be written to both memory banks. subi r14, r14, 4 !subtract 4 from r14 so that the address ffc02aa8 is !once again available. stwx r18, r14, r13 !store $09090909 data in $ffc02aa8 addi r14, r14, 4 !third step into the autoselect sequence taken care of. stwx r18, r14, r13 !it has to be writen to both memory banks. ! at this moment, the flash rom is on the autoselect mode. all memory reads will return !autoselect mode information such as manufacturer id, device id and sector protect !verification status. to exit autoselect mode, the autoselect reset sequence or a hardware !reset must be performed. lwzx r19, r12, r13 !loading into register 19 manufacturer id for the first !memory bank. addi r12, r12, 4
90 lwzx r20, r12, r13 !loading into register 20 manufacturier id for the second !memory bank the second sni ppet of code is actually the subroutine needed to w rite a byte. ex treme care must be taken when writing data to the flash as excimer can easily become corrupt and inoperating. st udents are encouraged to practice on a free sector (preferably sector 16), which will certainly be erased, or else can be erased without fear of damaging the os. check the am29lv800b data sheet for further exci- mer sector division information. refer to the troubleshooting section for problems r egarding difficulty to write data to the flash. .text .global writeflash writeflash: xor r13, r13, r13 !clearing register 13 xor r12, r12, r12 !clearing register 12 lis r12, 65472 !register 12 contains address $ffc00000 addi r12, r12, 10920 !register 12 contains address $ffc02aa8 !xor r14, r14, r14 !clearing register 14 !lis r14, 65472 !register 14 contains address $ffc00000 !addi r14, r14, 10924 !register 14 contains address $ffc02aac xor r15, r15, r15 !clearing register 15 lis r15, 65472 !register 15 contains address $ffc00000 addi r15, r15, 5456 !register 15 contains address $ffc01550 xor r16, r16, r16 !clearing register 16 addi r16, r16, 170 !through this steps, the data $aaaaaaaa which will be slwi r16, r16, 8 !sent to the flash on the first step of the autoselect addi r16, r16, 170 !sequence, is assembled. note that bit reversal has been slwi r16, r16, 8 !accounted for. addi r16, r16, 170 slwi r16, r16, 8 addi r16, r16, 170 !register 16 contains data $aaaaaaaa xor r17, r17, r17 !clearing register 17 lis r17, 21845 !data $55555555 is assembled through this steps. this is addi r17, r17, 21845 !the data that will be sent on the second step of the !autoselect sequence. bit reversal has been taken care of. xor r18, r18, r18 !clearing register 18 addi r18, r18, 5 !data $05050505 is assembled through this steps. this slwi r18, r18, 8 !word is sent to the flash to differentiate the command addi r18, r18, 5 !sequence from all others. this data is specific to the slwi r18, r18, 8 !autoselect mode. addi r18, r18, 5 slwi r18, r18, 8 addi r18, r18, 5 !register 18 contains data $05050505 stwx r17, r12, r13 !store $55555555 data in address $ffc02aa8 addi r12, r12, 4 !first sequence step taken care of. stwx r17, r12, r13 !it has to be written to both memory banks.
91 stwx r16, r15, r13 !store $aaaaaaaa data in $ffc01550 addi r15, r15, 4 !second sequence step taken care of. stwx r16, r15, r13 !it has to be written to both memory banks. subi r12, r12, 4 !subtract 4 from r12 so that the address ffc02aa8 is !once again available. stwx r18, r12, r13 !store $05050505 data in address $ffc02aa8 addi r12, r12, 4 !third sequence step taken care of. stwx r18, r12, r13 ! it has to be written to both memory banks. xor r19, r19, r19 !clearing register 19 lis r19, 65484 !register 19 contains address $ffcc0000 xor r20,r20,r20 !clearing register 20 lis r20, 85 !register 20 contains data $00000055 stwx r20, r19, r13 !program $00000055 data in flash address $ffcc0000 !at this moment, data will have been programmed into $ffcc0000 /*---------------------------------------------------------------------------------------* main.c emr 29/4/99 this code writes a program to flashrom and sets the booting vector to the program written. there's some problem with the flashrom. right now the program is stuck with trying to write cor- rectly to the flashrom. i have tried the same program with two different excimer boards and the results are different. although the second time it write some information correctly. i think the flashrom is damaged. ----------------------------------------------------------------------------------------*/ #include #define getchar dink_get_char #define putchar dink_write_char #define printf dink_printf void blink_leds(int addr, int i); unsigned long (*dink_get_char)() = (unsigned long (*)()) 0x1e4c4; unsigned long (*dink_write_char)(char) = (unsigned long (*)(char)) 0x5eb4; unsigned long (*dink_printf)() = (unsigned long (*)()) 0x6270; #define flash 0xffc00000 #define addr1 0x2aa8 #define addr2 0x1550 #define zerosones 0x01010101 #define allas 0xaaaaaaaa #define allfives 0x55555555 #define zeroscs 0x0c0c0c0c #define zerosfives 0x05050505 #define zerosfours 0x04040404 #define zerosnines 0x09090909 #define allzeros 0x00000000 void erase_sector(int); void program(unsigned int *, unsigned int); void unlock_bypass(); void write_word(unsigned int *, unsigned int); void unlock_bypass_reset(); void leds_main(); void blink_leds(int addr, int i); void blank();
92 void main() { unsigned int *addr = (unsigned int *)0xffd00000; unsigned int *prog = (unsigned int *)0x0; unsigned int size = 0; //borrar sector donde estara el codigo erase_sector(7); //escribir nuestro codigo al flashrom /*unlock_bypass(); size = (unsigned int)blank - (unsigned int)leds_main; for(unsigned int i=0; i18) { return; } else
93 { sect = (unsigned int *)((0x8000<<3)*(sector-3)+flash); } command = (unsigned int *)(flash + addr1); *command = allfives; command +=1; *command = allfives; command = (unsigned int *)(flash + addr2); *command = allas; command +=1; *command = allas; command = (unsigned int *)(flash + addr1); *command = zerosones; command +=1; *command = zerosones; command = (unsigned int *)(flash + addr1); *command = allfives; command +=1; *command = allfives; command = (unsigned int *)(flash + addr2); *command = allas; command +=1; *command = allas; printf("%x ", (unsigned int)sect); *sect = zeroscs; } void program(unsigned int *addr, unsigned int word) { unsigned int *command; command = (unsigned int *)(flash + addr1); *command = allfives; command +=1; *command = allfives; command = (unsigned int *)(flash + addr2); *command = allas; command +=1; *command = allas; command = (unsigned int *)(flash + addr1); *command = zerosfives; command +=1; *command = zerosfives; printf("%x ", (unsigned int)addr); printf("%x\n", word); *addr = word; } void unlock_bypass() { unsigned int *command; command = (unsigned int *)(flash + addr1); *command = allfives;
94 command +=1; *command = allfives; command = (unsigned int *)(flash + addr2); *command = allas; command +=1; *command = allas; command = (unsigned int *)(flash + addr1); *command = zerosfours; command +=1; *command = zerosfours; } void write_word(unsigned int *addr, unsigned int word) { unsigned int *command; command = (unsigned int *)(flash); *command = zerosfives; command +=1; *command = zerosfives; printf("%x ", (unsigned int)addr); printf("%x\n", word); *addr = word; } void unlock_bypass_reset() { unsigned int *command; command = (unsigned int *)(flash); *command = zerosnines; command +=1; *command = zerosnines; command = (unsigned int *)(flash); *command = allzeros; command +=1; *command = allzeros; } void leds_main() { int decimal_no; char led; char number; do { printf ("\nselect the led you want to blink:\n"); printf ("\ts - press s for the status led\n"); printf ("\te - press e for the error led\n"); printf ("\tq - press q to quit\n"); led = getchar(); if (led == 'e' || led == 'e') { printf ("\nenter the number of times (1-9) to blink the error led: "); do{ number = getchar(); }while ( !((number >= '0') && (number <= '9')) ); putchar(number); decimal_no = number - 48;
95 blink_leds(0x40600000, decimal_no); } else if (led == 's' || led == 's') { printf ("\nenter the number of times (1-9) to blink the status led: "); do{ number = getchar(); }while ( !((number >= '0') && (number <= '9')) ); putchar(number); decimal_no = number -48; blink_leds(0x40200000, decimal_no); } } while ( led != 'q' && led != 'q' ); /* x or x */ return; } void blink_leds(int addr, int i) { unsigned long count; int loop; for (loop = 0 ; loop < i; loop++) { *(char *) (addr) = 0x00; //turn on error for(count = 0; count <= 0xfff00; count ++); *(char *) (addr) = 0x08; //turn off error for(count = 0; count <= 0xfff00; count ++); } *(char *) (0x40600000) = 0x08; } void blank(){} troubleshooting: trouble to enter a mode using the specified word sequence tends to occur either because data was not properly reversed or because address was not properly shifted. recall that the memory mapping of the excimer does not have to be that of the amd memory devices as specified on the am29lv800b data sheet. in fact no memory device has to actually be memory mapped as specified by a datasheet. those addresses provided by the manufacturer are offsets and depend greatly on were they were placed. on the excimer board, flash rom was placed on address $ffc00000. every offset has to be added to that base address. but this is not all. since power pc data bus is 64 bits wide and chips are just 16, they must be cascaded to supply the need. if you are using the am29lv800b data sheet as reference, take in m ind that every address presented has to be shifted by three. if you are using the notes pre- sented on this lab section, the addresses are already shifted.
96 as explained earlier, power pc 603e is a big-endian device while amd fl ash chips are little endian. address bus was already fixed so that little address bit were reversed by hardware. data bus does not has to be hardware reversed since it is irrelevant if you programmed a cell backwards. when it is read, it will get backwards again and thus rectified. this leaves programmers with the problem that whatever the flash chip is expecting as a command will have to be reversed by hand. bit reversing is som etimes confused as taking a 1 and changing it to a 0 and viceversa. this will actually not work when w rit- ing commands to the flash device. what we mean by bit reversing is actually a mirror of the word. that what was the msb now becomes the lsb and viceversa. if you are having trouble entering into a specific mode check that you have done this right. another common mistake is to reverse the nibbles in the bytes or the bytes on the word. you actually have to reverse the 16 bit word. an 0a reversed is not a0 but 50. (00001010 m irrored is not 10100000 but it is 01010000).

▲Up To Search▲

Price & Availability of EXCIMERLABMANUAL

	To Download EXCIMERLABMANUAL Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .