RapUp

• Dynamic Allocation of Memory in C

• Last HW Exercise

• Review for Final

•Final Exam Next Thursday – Same Time / Same Place

Dynamic Storage Allocation from the Heap

In Java, memory is allocated only to Objects, and freeing of memory is done automatically by the “garbage collector” when an Object is no longer accessible.

This was to eliminates memory leaks in Java, BUT if links to stale Objects remain, the garbage collector can never act on them.

Last Homework (HW12)

C Program Organization:

Pre Main Code – Establish Stack, Init R4 & R5

Main Function { }

Scanf Function { } - Replace this Physical Space with: Your Scanf Function (which accepts a pointer) Your Interrupt Service Routine Printf Function { }

Global Data Area R4 . . . . . . . . . . . .

Stack R6 (and R5)

Note: Remember that your Scanf Function must: Create the return space, Push R7 & R5, and create the Local Variables

Load the return space and Pop the Local variables, R5, & R7

Note: You must either load the Interrupt Vector Address and Arm the Interrupt by hand,

or create another Function to do it.

LC-3 Architecture

Data paths & Control Signals

PSW (Program Status Word): Bits: 15 10 9 8 2 1 0 | S| |Priority| | N| Z| P|

LC-3 Instructions Addressing Modes

• Register (Operand is in one of the 8 registers)

• PC-relative (Operand is “offset” from where the PC points

- offsets are sign extended to 16 bits)

• Base + Offset (Base relative) (Operand is “offset” from the contents of a register)

• Immediate (Operand is in the instruction)

• Indirect (The “Operand” points to the real address of Operand

– rather than being the operand)

Note: The LC-3 has No Direct Addressing Mode

LC-3 Simulator Screen

Traps

1) Execute TRAP “vector number” - Service Routine Address

Trap Vectors are at memory locations [0000:00FF]

Trap Vectors contain addresses of “Pre written (?)” Service Routines

2) [PC] is stored in R7 (save the return address)

3) Address of Trap Service Routine loaded into PC (addr of service routine)

4) Service Routine Program executed

7) Trap service routine program ends with an RET (to return to calling prog)

[R7] loaded into PC

Subroutines

1) Execute JSR offset or JSRR rn - Call Subroutine or Method Location of Subroutine is specified in the Instruction

2) [PC] stored in R7 (store return address)

3) Address from JSR offset or JSRR rn is loaded into PC (beginning of subr)

4) Subroutine is executed R0 likely contains passed parameter (or address)R5 may be used to return error messageR0 likely contains return parameter (or address)

5) Subroutine program ends with an RET ( [R7] loaded into PC)

Can you pass (return) two parameters ?Can a subroutine call another subroutine ?

How does this mechanism support recursion?

StackR6 is the Stack Ptr

Push:Push ADD R6, R6, #-1 ; Decrement Stack Ptr STR R0, R6, #0 ; “Push” [R0] onto Stack

Pop:Pop LDR R0, R6, #0 ; “Pop” Data off of Stack (into R0)

ADD R6, R6, #1 ; Increment Stack Ptr

What do we need to do to facilitate nested subroutines ? Push R7 (containing the return PC) onto the Stack

Allocating Space for Variables

• Global data section– All global variables stored here

(actually all static variables)– R4 points to Global Variables

• Run-time stack– Used for local variables (among other things)– R6 points to top of stack– R5 points to top frame on stack– New frame created for each “block”

or scope (goes away when block exited)

• Accessing a variable:

– Global: LDR R1, R4, #x– Local: LDR R2, R5, #-yOffset = distance from beginning of storage area

instructions

global data

run-timestack

Device Registers

x0200

xFFFF

PC

R4

R6R5

x0000

xFE00

Trap Vectors

Op Sys x3000

Heap

Intr Vectorsx0100

Context Frame (Activation Record) Format(Note: you will see that there is some inconsistency as to where the

Frame begins)

Function stacked stuff

……..

……..

Local Variables

Caller’s Frame Pointer (R5)

Caller’s R7 (contains caller’s PC)

Function Return Value

Function Pass Value 1

……..

Function Pass Value n

R6

R5

……..Local Variables“Previous R5”

- - - - - - - -

- - - - - - - -

Frame

Caller pushes arguments (last to first).Caller invokes subroutine (JSR).

Callee allocates return value, pushes R7 and R5.Callee allocates space for local variables.

Callee executes function code.

Callee stores result into return value slot.Callee pops local variables, pops R5, pops R7.Callee returns RET (or JMP R7).

Caller loads return value and pops arguments.Caller resumes computation…

Stack Snapshot

Stk in Func4:xEFE2xEFE3xEFE4xEFE5 (Func4 local var) <- FramePtr (Func4)xEFE6 R5 FramePtr (xEFEA)xEFE7 R7 Saved PC (x3071)xEFE8 return value from Func4xEFE9 pass value to Func4 (C = 8)xEFEA (Func3 local var) <- FramePtr

(Func3) xEFEB R5 FramePtr (xEFEF)xEFEC R7 Saved PC (x3059)xEFED return value from Func3 spacexEFEE pass value to Func3 (C = 8)xEFEF (Func2 local var) <- FramePtr

(Func2)xEFF0 R5 FramePtr (xEFF4)xEFF1 R7 Saved PC (x3041)xEFF2 return value from Func2 spacexEFF3 pass value to Func2 (C = 8) xEFF4 (Func1 local var) <- FramePtr

(Func1)xEFF5 R5 FramePtr (xEFFB)xEFF6 R7 Saved PC (x3024)xEFF7 return value from Func1 spacexEFF8 pass value to Func1 (C = 8)xEFF9 B = 5xEFFA A = 3xEFFB C = 8 (main local var) <- FramePtr (main)xEFFC R5 FramePtr (xEFFF)xEFFD R7 Saved PC (x300B)xEFFE return value from main spacexEFFF <- StkPtr <-

FramePtr

Program Context Implications

What are the Program Context implications of:– Executing a Trap Routine ?

• The PC must be saved and restored (Done by TRAP & RET) (Registers must be restored by Trap Routine - It is assumed all other “state” values effectively remain unchanged)

– Executing a Subroutine (or Function, or Method) ?• The PC must be saved and restored (Done by JSR or JSRR, & RET) (Registers must be restored by Trap Routine - It is assumed all other “state” values effectively remain unchanged)

– Executing an Interrupt ?• The PC, SP, & PSW must be saved and restored (Done by Supervisor &

RTI) (Registers must be restored by Interrupt Service Routine - It is assumed all other “state” values effectively remain unchanged)

Program Context Includes: PC, PSW (PSR), & SP (R6)

Program Status Word: (in the Program Status Register) PSW (PSR): PSR[15] – Privilege Bit - 0 for Privileged (Supervisor) State

1 for User State

PSR[10:8] – Priority Bits - Eight Levels (7 is the highest)

PSR[2:0] – Condition codes - N, Z, P

Stack Pointer: ( [R6] = USP or [R6] = SSP ) USP & SSP: User Stack Pointer & Supervisor Stack Pointer

USP.saved & SSP.saved: Two auxiliary registers that are used to

store the value of the Stack Pointer (User or Supervisor) that is not

in use. This is done automatically when the PSR[15] bit is switched.

- When in User Mode (PSR[15] = 1), R6 is the User Stack Pointer

and SSP.Saved contains the Supervisor Stack Pointer.

- When in Supervisor Mode (PSR[15] = 0), R6 is the Supervisor Stack

Pointer and USP.Saved contains the User Stack Pointer.

Interrupt ComponentsDevice (Keyboard shown here as example) Memory Keyboard Status Register:

Keyboard Data Register:

Keyboard Priority: 0 to 7

Device Interrupt Vector #: 180 to 1FF

(Note: device actually sends 00-FF to CPU)

CPUPC (Program Counter)

R6 (Stack Pointer)

PSR (Program Status Word) Bits: 15 10 9 8 2 1 0 | S| |Priority| | N| Z| P|

USP.saved (User Stack Pointer Storage)

SSP.saved (Supervisor Stack Pointer Storage)

Interrupt Example

Intr Vectors

Program flow

Supervisor Stack

Interrupt Process This is important to understand !

1) Programmer Action: Loads a Service Routine for the Device, and enters its Entry Addr in the Interrupt Vector Table Enables Interrupts by setting “intr enable” bit in Device Status Reg

2) Device Action to Request an Interrupt: When device needs service, (done or ready bit set, and interrupt enable bit set) and - its priority is higher than the priority of the Presently Running Program, and - execution of the present instruction is complete, then The Device submits an “Interrupt Request”, and when granted, supplies CPU with Interrupt

Vector #

3) CPU Action to Initiate Service of the Interrupt: When the CPU accepts the Interrupt Request (Priority higher than the present program Priority) - The CPU goes into Privileged Mode (PSR bit 15 cleared) - [R6] USP.saved register and [SSP.saved] R6, the stack pointer - The Processor saves the “state” (context) of the program (must be able to return) The [PC] and the [PSR] are PUSHED onto the Supervisor Stack (Other regs are not. Why?) - Priority level is set (established by the interrupting device) and the CC’s are cleared Then, the PC is loaded with the service routine address (between 180 and 1FF). (Based upon the Device supplied Interrupt Vector #: 00 to 7F)

5) Interrupt Service Routine is Executed: - Done or Ready bit is reset in the Device SR (Likely, it reads from or writes to the Device DR) (This is done so that another interrupt is not generated before the present one is

serviced) - Ends with an RTI

6) RTI Initiates Return of Control to the Interrupted Program: - The stored User PSW is POPed into the PSR, and the User PC is POPed into PC), - (R6)SSP.saved, (USP.savedR6), - and then the next instruction in the interrupted program is fetched.

An interrupt can occur “anywhere” in a computer program, unlike Trap Calls or Subroutine Calls which occur exactly where you place them !

Example: Parameter Passing by Reference

#include <stdio.h>

void NewSwap(int *firstVal, int *secondVal);

int main(){ int valueA = 3; int valueB = 4; NewSwap(&valueA, &valueB); return valueA; /* returns 4 */}

void NewSwap(int *firstVal, int *secondVal){ int tempVal; /* Holds firstVal when swapping */ tempVal = *firstVal; *firstVal = *secondVal; *secondVal = tempVal; return; }

Snapshots During the Exchange

What happened differently using pass by reference, rather than pass by value ?

?

Initially After *firstVal=*SecondVal At the end