Lab Report > CEG3136 Computer Architecture II Lab 1 Introduction to Microprocessor Programming

downloaded from

Scholarfriends

https://scholarfriends.com Downloaded by: writerforacademic@gmail.com | https://scholarfriends.com/singlePaper/273543/lab-report-ceg3136-computer-architecture-iilab-1-introduction-to-microprocessor-programming Distribution of this document is illegal.

CEG3136 Computer Architecture II Lab 1

Introduction to Microprocessor Programming

Group Members:

Experiment Performed: September 24, 2015 Experiment Due date: October 2, 2015 Part One: Step 1 - Problem During this section of the lab, we were tasked with compiling the code using the recommended MiniIDE software and also running the code on the Dragon-12 board. This part also included modifying the given code to the different specifications given in the lab manual.

Step 2: Input/Outputs of Problem The inputs to this section of the lab was an ASCII character. At runtime, the program would prompt us for a character. This output after examining the code is the character being printed on the console three times. Later on during the section the code was modified to print the character fifteen times.

Step 3: Algorithm To help understand the code that was provided, we had translated the code to C. This allowed us to have a higher more abstract view of what the code does. The C code can be seen as follows:

Step 4: Implementation Tasked with changing the code the initial code was as seen in the table.

Table 1.1: Original assembled assembly code with addressing.

Address

Content

Instruction

2000

CC003A

LDD #$3A

2003

FEEE86

LDX $EE86

2006

1500

JSR 0,X

2008

FEEE84

LDX $EE84

200B

1500

JSR 0,X

200D

8603

LDAA #3

200F

36

PSHA

2010

37

PSHB

2011

CC0020

LDD #$20

2014

FEEE86

LDX $EE86

2017

1500

JSR 0,X

2019

33

PULB

201A

FEEE86

LDX $EE86

201D

1500

JSR 0,X

201F

32

PULA

2020

43

DECA

2021

26EC

BNE $200F

2023

3F

SW1

Changes to assembly code is shown in red on table 1.2.

Table 1.2: Modified assembled assembly code with addressing.

Address

Content

Instruction

Comment

2000

CC003E

LDD #$3E

Change prompt to ascii „>‟

2003

FEEE86

LDX $EE86

2006

1500

JSR 0,X

2008

FEEE84

LDX $EE84

200B

1500

JSR 0,X

200D

860F

LDAA #15

200F

36

PSHA

2010

37

PSHB

2011

CC002C

LDD #$2C

Changed counter to 15

Change separator to ascii „,‟

In the table below we answer the question that was raised in part 1b in the lab manual of the addressing mode of LDX, JSR, and BNE. Table 1.3: Assembly analysis of select operations Instruction Code

Machine Code

OP Code

Operand

Addressing Mode

LDX $EE86

FEEE86

FE

EE86

Extended Memory Addressing

JSR 0,X

1500

15

00

Indexed Addressing

BNE $200F

26EC

26

EC

Relative Addressing

For the first instruction it is extended memory addressing due to the size of the parameter being 16 bits which is equivalent to 2 bytes which occupies 1 memory words. As for the second address it is indexed since of the syntax that shows that the address is at register X with offset 0 equating to X + 0 = X. For the last instruction it is relative addressing since as the assembler replaces $200F with the signed 8-bit address difference of $200F and the instruction after BNE, illustrated below.

(200F)16 - (2023)16 = -(14)16 = -(00010100)2 = (11101100)2 = (EC)16

Step 5: Testing and Validation To test and validate the code that we had modified, we ran the program with a known input and expected output. We then compared the expected output to the actual output and since they were the same it was concluded that the modifications were a success. We had also demonstrated the code to the teaching assistant and his approval was given.

Part Two: Step 1 - Problem The main problem faced in this section of the lab was finding and debugging the code.

The first is that the delay is nonexistent since the delay module has not been implemented yet.

The program currently accepts any code as a valid for for arming and disarming the alarm. The causes were not known until after the debug process.

Step 2: Input/Outputs of Problem The inputs into this program were the codes to configure or arm the alarm simulator. This program would accept a character, a or c, as input to determine the next action to take and when needed would also take a code which would be decimal numbers to arm and disarm the alarm.

Step 3: Algorithm We did not use an algorithm for this section as it did not require one. Instead we had used the built in tracing tool to allow us a better view at each line of the program. We had also used the breakpoint tool to allow us to directly start tracing from where we suspected the bug to be located. The tool that was used was the Bug12 Monitor.

Step 4: Implementation A - Bug Fix After tracing through the program we realized that the bug occurred when the program would check the alarm code. It was initially “beq CDE_endif”. This meant that it would not branch if the were incorrect, preseeding to flagging the code as valid. In other words, if the given code does not match one of the actual codes, it will be incorrectly marked as valid.

To fix this, the line was changed to “bne CDE_endif” so that if the code is not equal it does not disarm the alarm and continues properly.

B - Addressing Modes The red line in table 2.1 indicates where the line of code which causes the system to hang “BCLR Clksel,x,%10000000”. The line directly below it are the two MOVW instructions. The only register that changed in this case was the PC register which is to be expected since MOVW only affects data in memory. The last line is the “rts” instruction. With this instruction the registers that change are the SP register and the PC register. This is to be expected as the rts instruction will pull the return address pointed to by the SP register and was then decremented

by 2 as addresses are stored as 2 bytes. The stack pointer change can be seen in the third line of table 2.1.

The addressing modes for the two MOVW instructions are as follows, for the MOVW #0, alarmCode it is immediate (#0) followed by extended-direct for the alarmCode, while for MOVW #1000, mult it is immediate followed by extended-direct.

Table 2.1: Program tracing of AlarmSimul from PC $400 to $405 A

B

X

Y

SP

PC

CCR

00

00

0000

0000

3C00

0400

90

00

00

0000

0000

2000

0403

90

00

00

0000

0000

1FFE

0427

90

00

00

0000

0000

1FFE

0429

90

00

00

0000

0000

1FFE

042C

90

0C

9C

0000

0000

1FFE

0450

90

0C

9C

0000

0000

1FFE

0456

90

0C

9C

0000

0000

1FFE

045C

90

0C

9C

0000

0000

2000

0405

90

Step 5: Testing and Validation To test the code after we finished debugging involved us running the program again. This time checking to see if the problem of the program accepting any code as a valid code was still present. After numerous different code inputs we concluded that the bug was no longer present and demonstrated our newly changed program to the teaching assistant where he agreed that it was now correct.

Part Three: Step 1 - Problem We were tasked to creating a delay module for the system. This involved implementing the body of several subroutines. The main implementation involved writing assembly code to delay for 1 ms or 24,000 clock cycles.

Step 2: Input/Outputs of Problem The only input to the code was a delayCount. This delayCount was used to indicate how many calls to polldelay are needed. Where each call to polldelay would delay for 1 ms and decrease the delayCount. Once the delayCount was 0, polldelay would return true. The important output of the subroutine was the time delay it caused, and the indication of weather it has delayed enough.

Step 3: Algorithm

Step 4: Implementation See the attached delay.asm file for implementation of the subroutine pollDelay and setDelay.

Step 5: Testing and Validation To test the delay module after writing up the assembly code, we would set the delayCount to a value and have an expected output for the value which in this case would be the expected delay. We would then have a rough estimate of how much the delay should be and deduce whether or not it was accurate enough from the result.

Conclusion From this lab, it was concluded that: 1) MiniIDE can be used to generate both the binaries for execution and .lst files for viewing both assembly source and machine code. This aided the debugging processes and the determination of memory addressing, instruction size, and address locations.

2) Hardware breakpoints and other built in tools to the Dragon-12 board can be used to effectively debug a running program. This can be done by viewing the contents of the registers and memory.

3) The use of assembly code can create a program with a very deterministic run speed by knowing cycle per instruction and clock speed.