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  R 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: | 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 message R0 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?

Stack R6 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, #-y Offset = distance from beginning of storage area instructions global data run-time stack Device Registers x0200 xFFFF PC R4 R6 R5 x0000 xFE00 Trap Vectors Op Sys x3000 Heap Intr Vectors x0100

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: xEFE2 xEFE3 xEFE4 xEFE5 (Func4 local var) <- FramePtr (Func4) xEFE6 R5 FramePtr (xEFEA) xEFE7 R7 Saved PC (x3071) xEFE8 return value from Func4 xEFE9 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 space xEFEE 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 space xEFF3 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 space xEFF8 pass value to Func1 (C = 8) xEFF9 B = 5 xEFFA A = 3 xEFFB C = 8 (main local var)<- FramePtr (main) xEFFC R5 FramePtr (xEFFF) xEFFD R7 Saved PC (x300B) xEFFE return value from main space xEFFF <- 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 Components Device (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) CPU PC (Program Counter) R6 (Stack Pointer) PSR (Program Status Word) Bits: | 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.saved  R6), - 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 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