【CSS422】Programming Language Design

CSS422 Final Project Thumb-2 Implementation Work of Memory/Time-Related C Standard Library Functions. 1. Objective You’ll understand the following concepts at the ARM assembly language level through this final project that implements memory/time-related C standard library functions in Thumb-2. • CPU operating modes: user and supervisor modes • System-call and interrupt handling procedures • C to assembler argument passing (APCS: ARM Procedure Call Standard) • Stack operations to implement recursions at the assembly language level • Buddy memory allocation This document is quite dense. Please read it as soon as the final project spec. becomes available to you. 2. Project Overview Using the Thumb-2 assembly language, you will implement several functions of the C standard library that will be invoked from a C program named driver.c. See Table 1. These functions must be code in the Thumb- 2 assembly language. Some of them can be implemented in stdlib.s running in the unprivileged thread mode (=user mode), whereas the others need to be implemented as supervisor calls, (i.e., in the handler mode = supervisor mode). For more details, log in one of the CSS Linux servers and type from the Linux shell: man 3 function where function is either bezro, strncpy, malloc, free, signal, or alarm The driver.c we use is shown in listing 1. It tests all the above six stdlib functions. Please note that printf() in the code will be removed when you test your assembly implementation, because we won’t implement the printf( ) standard function. Listing 1: driver.c program to test your implementation #include <strings.h> // bzero, strncpy #include <stdlib.h> // malloc, free #include <signal.h> // signal #include <unistd.h> // alarm #include <stdio.h> // printf int * alarmed ; void sig_handler1 ( int signum ) { *alarmed = 2; } void sig_handler2 ( int signum ) { *alarmed = 3; } int main ( ) { char stringA [40] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabc\0" ; char stringB [40]; bzero( stringB, 40 ); strncpy( stringB, stringA, 40 ); bzero( stringA, 40 ); printf( "%s\n" , stringA ); printf( "%s\n" , stringB ); void * mem1 = malloc( 1024 ); void * mem2 = malloc( 1024 ); void * mem3 = malloc( 8192 ); void * mem4 = malloc( 4096 ); void * mem5 = malloc( 512 ); void * mem6 = malloc( 1024 ); void * mem7 = malloc( 512 ); free( mem6 ); free( mem5 ); free( mem1 ); free( mem7 ); free( mem2 ); void * mem8 = malloc( 4096 ); free( mem4 ); free( mem3 ); free( mem8 ); alarmed = ( int *)malloc( 4 ); *alarmed = 1; printf( "%d\n" , *alarmed); signal( SIGALRM, sig_handler1 ); alarm( 2 ); while ( *alarmed != 2 ) { void * mem9 = malloc( 4 ); free( mem9 ); } printf( "%d\n" , *alarmed); signal( SIGALRM, sig_handler2 ); alarm( 3 ); while ( *alarmed != 3 ) { void * mem9 = malloc( 4 ); free( mem9 ); } printf( "%d\n" , *alarmed); return 0; } This driver program repeats allocating and deallocating memory space and thereafter sets the sig_handler1( ) function to be called upon receiving the first timer interrupt (in 2 seconds) and sig_ahndler2( ) function to be called upon the second timer interrupt (in 3 seconds). 3. System Overview and Execution Sequence 3.1. Memory overview This project maps all code to 0x0000.0000 – 0x1FFF.FFFF in the ARM’s usual ROM space (as the Keil C compiler/ARM assembler does) and defines a heap space; user and SVC stacks; memory control block (MCB) to manage the heap space; and all the SVC-related parameters over 0x2000.1000 – 0x2000.7FFF in the ARM’s usual SRAM space. See table 2. Listing 2: The memory space definition in Thumb-2 Heap_Size EQU 0x00005000 AREA HEAP, NOINIT, READWRITE, ALIGN=3 __heap_base Heap_Mem SPACE Heap_Size __heap_limit Handler_Stack_Size EQU 0x00000800 Thread_Stack_Size EQU 0x00000800 AREA STACK, NOINIT, READWRITE, ALIGN=3 Thread_Stack_Mem SPACE Thread_Stack_Size __initial_user_sp Handler_Stack_Mem SPACE Handler_Stack_Size __initial_sp 3.2. Initialization, system call, and interrupt sequences (1) Initialization: the ARM processor reads the first 8 bytes to set MSP and the next 8 bytes to jump to the Reset_Handler routine (as you studied in the class). You don’t have to change the original vector table. Reset_Handler initializes all the data structures you’ve developed and finally calls __main with listing 3. Listing 3: The last two instructions in Reset_Handler (startup_TM4C129.s) LDR R0, =__main BX R0 These last two statements are from the original startup_TM4C129.s. Then, the main( ) function in driver.c is invoked. (2) System calls: whenever main( ) calls any of stdlib functions including bzero, strncpy, malloc, free, signal, and alarm, the control needs to move to strlib.s. In other words, you need to define these function protocols in strlib.s, as shown in listing 4: Listing 4: The framework of stdlib.s AREA |.text|, CODE, READONLY, ALIGN=2 THUMB EXPORT _bzero _bzero ; Implement the body of bzero( ) MOV pc, lr ; Return to main( ) EXPORT _strncpy _strncpy ; Implement the body of strncpy( ) MOV pc, lr ; Return to main( ) EXPORT _malloc _malloc ; Invoke the SVC_Handler routine in startup_TM4C129.s MOV pc, lr ; Return to main( ) EXPORT _free _free ; Invoke the SVC_Handler routine in startup_TM4C129.s MOV pc, lr ; Return to main( ) EXPORT _signal _signal ; Invoke the SVC_Handler routine in startup_TM4C129.s MOV pc, lr ; Return to main( ) EXPORT _alarm _alarm ; Invoke the SVC_Handler routine in startup_TM4C129.s MOV pc, lr ; Return to main( ) END Among these six stdlib functions, you’ll implement the entire logic of bzero( ) and strncpy( ) as they may be executed in the user mode. However, the other four functions must be handled as a system call. You need to invoke SVC_Handler in startup_TM4C129.s. Based on the Linux system call convention, use R7 to maintain the system call number. Arguments to a system call should follow ARM Procedure Call Standard, as summarized in table 3.