Prepare for your exams
Get points
Guidelines and tips
Sell on Docsity
Docsity AI

Prepare for your exams

Study with the several resources on Docsity

Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips

Sell on Docsity

Docsity AI

Log in Sign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents

20 Points

For each uploaded document

Answer questions

5 Points

For each given answer (max 1 per day)

All the ways to get free points

Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Assembly Language Programming - Lab 2 | EECS 373, Lab Reports of Electrical and Electronics Engineering

University of Michigan (UM) - Ann Arbor Electrical and Electronics Engineering

Material Type: Lab; Class: Des Microproc Syst; Subject: Electrical Engineering And Computer Science; University: University of Michigan - Ann Arbor; Term: Fall 1998;

Typology: Lab Reports

Pre 2010

Uploaded on 09/02/2009

koofers-user-mws 🇺🇸

10 documents

1 / 5

This page cannot be seen from the preview

Don't miss anything!

1

EECS 373 Fall 1998

Lab 2: Assembly-Language Programming

Note: Prelab questions must be done individually and handed in at the start of your lab section.

You must also, with your partner, write an initial version of the required program before

you come to your lab section. You must bring a printed listing file (see instructions

below) to your lab section to show the TA or you will not be allowed to work in the lab.

Your program does not need to be completely debugged, but obviously the more

debugging you do on the CAEN simulator the less time you will spend in the lab.

Introduction:

In this lab, you will write an assembly-language program that flashes an LED on

the target board.

Goals:

1. To develop and debug an assembly-language program from scratch given a

high-level specification.

2. To experience and understand the differences between debugging on the

simulator and on the target hardware.

3. To provide basic experience with a very simple device control register.

Prelab questions:

1. For each of the following data types, write the instruction or instruction sequence that

reads a value of that type from memory and places it in a register. Assume that the

memory address is in r3 and load the value into r4.

a. Signed 32-bit integer

b. Unsigned 32-bit integer

c. Signed 16-bit integer

d. Unsigned 16-bit integer

e. Signed 8-bit integer

f. Unsigned 8-bit integer

2. Consider the following program fragment. Recall that .align 2 aligns the

following location to the next 22-byte (i.e. 4-byte) boundary. The .byte directive

allocates initialized byte memory values, just as the .word and .half directives

used in Lab 1 allocate word and halfword values.

.align 2

data: .byte 0x99, 0x88, 0x77, 0x66, 0x55, 0x44

Discover Lab Reports of Electrical and Electronics Engineering University of Michigan (UM) - Ann Arbor

Partial preview of the text

Download Assembly Language Programming - Lab 2 | EECS 373 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!

EECS 373 Fall 1998

Lab 2: Assembly-Language Programming

Note: Prelab questions must be done individually and handed in at the start of your lab section. You must also , with your partner, write an initial version of the required program before you come to your lab section. You must bring a printed listing file (see instructions below) to your lab section to show the TA or you will not be allowed to work in the lab. Your program does not need to be completely debugged, but obviously the more debugging you do on the CAEN simulator the less time you will spend in the lab.

Introduction:

In this lab, you will write an assembly-language program that flashes an LED on the target board.

Goals:

To develop and debug an assembly-language program from scratch given a high-level specification.
To experience and understand the differences between debugging on the simulator and on the target hardware.
To provide basic experience with a very simple device control register.

Prelab questions:

For each of the following data types, write the instruction or instruction sequence that reads a value of that type from memory and places it in a register. Assume that the memory address is in r3 and load the value into r4. a. Signed 32-bit integer b. Unsigned 32-bit integer c. Signed 16-bit integer d. Unsigned 16-bit integer e. Signed 8-bit integer f. Unsigned 8-bit integer
Consider the following program fragment. Recall that .align 2 aligns the following location to the next 2^2 -byte (i.e. 4-byte) boundary. The .byte directive allocates initialized byte memory values, just as the .word and .half directives used in Lab 1 allocate word and halfword values.

.align 2 data: .byte 0x99, 0x88, 0x77, 0x66, 0x55, 0x

lis r3, data@h ori r3, r3, data@l lbz r4, 0(r3) lbz r5, 3(r3) lhz r6, 0(r3) lhz r7, 1(r3) lhz r8, 2(r3) lwz r9, 0(r3) lwz r10, 1(r3)

a. List the values of registers r4 through r10 after executing the fragment. b. Which (if any) of these instructions cause unaligned accesses?

Write an instruction or instruction sequence that will perform each of the following single-bit operations on the value in register r4. All other bits in r4 should remain unchanged. (Recall that, in the PowerPC world, bit 0 is the most significant bit.) In this problem and in all your programs , use the C arithmetic operators (for example, +, <<, >>, ~, |, &) to derive the constant values you may need. Your code will be much clearer and (as long as all the operands are constants) the assembler will evaluate these expressions for you, eliminating potential calculation errors. a. Set bit 31. b. Set bit 20. c. Set bit 5. d. Toggle (complement) bit 18. e. Toggle bit 8. f. Clear bit 20. g. Set the bit indicated by the value in r5.
Give an instruction sequence that will execute the lwz if and only if bit 20 of r4 is 1.

(your code goes here) lwz r5, 0(r6) skipload: (more code)

Write out a high-level description of how your entire program will work before you begin writing any assembly language. Use C, pseudocode, flowcharts, or whatever you're comfortable with. Otherwise you will get bogged down in details before you know what you're really doing

Program specification:

You are to write a program that flashes an LED on the target board. A null-terminated ASCII text string specifies the timing pattern used to flash the LED. The string consists of decimal numbers separated by spaces. Each number represents the amount of time the LED should be on or off in tenths of a second. For example, the string “10 15 20 30” should cause the LED to go on for one second, off for one and a half seconds, on for two

The SDS simulator can be accessed from the start menu, under “Programs’ Engineering & Science’ SingleStep 7.3”.

The assembler will warn you when you provide an immediate operand that’s outside the proper range. Unfortunately, it’s not smart enough to realize that shifted immediate operands (as for ‘lis’) should be treated as unsigned (since there’s really no sign extension involved). If you get a “Value out of range” warning on an ‘lis’, you can safely ignore it.
All program constants should be given symbolic labels using the .equ directive. All derived constants should be calculated using assembler-supported C operators.
Comment your program thoroughly!
Define a test pattern string in your program using the .ascii or .asciz directives. These directives allocate initialized bytes (like .byte), but the initial values are the ASCII codes of the argument string. The .asciz directive automatically adds a null character on the end of the string; if you use .ascii you have to explicitly add the null byte yourself (e.g., "test\0").

Procedure (in the lab):

If you have not thoroughly tested your program under the simulator, do so before trying to run the code on the target board. You can run the simulator version of SingleStep on the 373 lab machines via the Start menu, at “Programs’ SingleStep 7.3’ SingleStep Simulator (PowerPC)”. Since the simulator does not have to communicate data back and forth across the wiggler cable, it is faster for generic code debugging than the “on-chip” version. You should verify that your program is parsing the ASCII string correctly, accessing the control register at the right location and with the right value, etc. before you try to use the target board.
After you have verified the operation as completely as possible on the simulator, start the SingleStep OnChip debugger and download your program to the target board. Place breakpoints at the instruction(s) that read BCSR4, and at the instruction(s) that write a new value to BCSR4.
Run the program until it hits the first breakpoint (which should be a BCSR4 load). Verify that the effective address of the BCSR4 load will be 0xF0000010. If it is not, do not continue. Debug and fix this error, using either the on-chip or simulator debuggers.
If the effective address is correct, single-step the load and make note of the loaded value.
Run the program until it hits the breakpoint at the (first) BCSR4 store. Verify that the effective address of the store will be 0xF0000010, and that the value in the source register (the data to be stored) differs from the data that was loaded only in bit position 3 (that’s 0x10000000). If this is not the case, do not continue … go back and debug your problem.

Single-step the store. If you have changed the value in bit position 3, the LED should change state.
Repeat steps 3-6 until you have observed all of the BCSR4 loads and stores at least twice.
Delete or disable the breakpoints and continue running your program. If it does not meet the specification, debug and correct the problem.
Test your program on the following strings:

“5 5 5 5 10 10” “2 8 4 6 8 2 4 6” “10 5 10” and any other strings you might like to try.

Print a listing file of your complete program and demonstrate it to the TA. The TA will sign your listing. Turn the signed copy in with your lab report.

Lab report: (due at the beginning of your next lab section)

Briefly summarize the function of your program.
Describe how your program operates: the individual steps and algorithms involved. Be thorough but not verbose; two or three paragraphs should be sufficient.
Include a well-commented listing of your program. Comments should include register usage (i.e. which variables are kept in which registers), descriptions of all symbols, and explanation of all derived expressions. If you add comments after you demonstrate to the TA, be sure to include both the commented listing and the signed listing.
Discuss any difficulties you may have had in getting your program to work correctly: what parts of the program were hard to write initially, what types of bugs did you have to fix, etc.
Discuss the differences you observed between debugging your code on the simulator and debugging on the target hardware.
Discuss any limitations your program may have. What is the largest number that could be put in the input string without causing an error? Why?