Topic2d High-Level languages and System Software (Toolchain) Introduction to Computer Systems Engineering (CPEG 323) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Reading List Slides: Topic2d Operating System and Compiler Books 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain toolchain A collection of system softwares used to develop for a particular hardware target If you designed a new processor, what is the basic system software tool set you need? 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

A Typical Toolchain and its Translation Hierarchy C program Compiler Assembly language program Assembler Object: Machine language module Object: Library routine (machine language) Linker Utility tools Executable: Machine language program Debugger Loader Memory A Typical Toolchain and its Translation Hierarchy 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain Two good examples SimpleScalar GNUPro www.simplescalar.com www.intel.com (Search GNUPro) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain Basic Set: • Compilers: C, C++, Fortran, and etc. • Binary utilities: assembler, linker, objdump, ar, nm • Debugger • Simulator (functional / cycle-accurate) • Others: performance monitor (VTune of Intel) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain gcc –v –O0 –o foo foo.c (old Step 0: cpp) foo.i Step 1: cc1 - compiler foo.s Step 2: as - assembler foo.o Step 3: ld - linker foo 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain - Preprocessor Functionality Header files Definitions Conditional compilation Pragma(Preprocessor Directives ) Delete the comments 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain - Compiler Transform a program from high level language to assembly language (or machine language) Optimizations 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Parameter Passing Caller save. The calling procedure (caller) is responsible for saving and restoring any registers that must be preserved across the call. The called procedure (callee) can then modify any register without constraint. Callee save. The callee is responsible for saving and restoring any registers that it might use. The caller uses registers without worrying about restoring them after a call. 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Saving Registers If you call a function, whatever you have in $s0 to $s7 is guaranteed to be there when the function gets back to you But registers $t0 - $t9 are fair game to be reused by the function What are the alternatives? - Save nothing? - Save everything? Why caller/callee save ? 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Why caller save / callee save? If all caller save ? Even callee doesn’t kill any of the saved registers – waste of cycles and memory resource If all callee save ? Callee has to save all the register (which will be used by callee), even caller doesn’t use them 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Caller save Function A Function B How to save ? - save to stack Add $10, $11,$12 Save $10, $12, $13 Jal B Restore $10, $12, $13 Sub $11, $2, $12 Mul $12, $10, $13 Add $2, $4, $5 Br $31 How to save ? - save to stack sw $10, 20(sp) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Callee Save Function A Function B Add $10, $11,$12 Save $10, $11, $12 Jal B Sub $11, $2, $12 Mul $12, $10, $13 Save $10, $11, $12 (if they are used in B) Lw $10, 4(sp) Add $11, $8, $9 Sub $12, $11, $10 Mul $2, $12, $11 Restore $10, $11, $12 Br $31 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Caller Save / Callee Save When to use caller save register ? TEMPORARY VARIABLE Also called Scratch Register When to use callee save register ? GLOBAL VARIABLE 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain - Assembler Transform assembly code into binary (machine code) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain - Linker Linking – resolve symbols Relocation – assign memory address 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain - loader Cannot see by user Done by Shell and OS kernel 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain – Library Libc/Libm 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Tool Chain Objdump See the memory layout and sections Symbol table Disassembly code Relocation information 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Creating an Executable File(User view) C program Compiler Assembly language program Assembler Object: Machine language module Object: Library routine (machine language) Linker Executable: Machine language program Loader Memory 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Compiling/Assembling a Program Code converted from high-level to machine language (binary) Each source file converted to a separate “object file” in Unix, object files have extension .o This is not executable (yet)! Intended to be combined with other modules, not stand-alone May not have everything we need (e.g., a main () function) Functions not assigned specific locations in memory Each function given a “relocation table” - This table tells exactly which addresses need to be resolved 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Relocation Table Suppose function f() in module a.c calls g() in b.c a.c should declare g with extern (directly or in .h file) Relocation table in a.o says something like: ”the jal at the 52nd instruction in f calls g, but I don’t know where g is.” Relocation table in b.o says something like: “I have a function g, which starts at location 628 in my file.” g unresolved even if local (why?) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Linking a program Linker combines one or more object files into a proper executable Linker determines which functions needed, discards the rest All needed functions put one after the other in text segment Linker resolves all labels; for instance Function f() in a.o calls g() in b.o Linker knows where it put g(), so it fixes the jal in f() Linker includes extra code: Initialization code before call to main() “Cleanup” code after main() returns 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Loading A program that links without an error can be run. Before being run, the program resides in a file on secondary storage, such as a disk. On Unix system, the operating system kernel brings a program into memory and starts running. 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Libraries Libraries contain functions intended to be shared & reused, e.g., C library: printf(), malloc(), strcmp(), sin(), cos() STL (Standard Template Library) in C++ Big software projects may make their own libraries Static libraries (* .a in Unix) made part of the executable by linker Dynamic libraries (* .so in Unix, * .dll in Windows) combined at runtime Executable still has relocation table of unresolved function calls Loader does the final resolution when you execute the program 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Dynamic vs. Static Library Dynamic library: processes share one copy of the code Static library: each process has its own copy of the code Why? 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Dynamic Shared Library ? Also called dynamic linked library Program A Program B Call printf Call printf Printf: DSO( dynamic shared object )Table 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Static Library Program B Program A Call printf Printf: Call printf 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Comparison Dynamic Static Less memory space Less disk space Most of the case: Slower Static More memory size More disk size Most of the case: faster 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Debugger Instruction level debugger Source level debugger Major techniques Ptrace (POSIX API. on Linux/Unix system) Embedded or raw machine Software trap Single step mode 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Debugger “Source-level” debugger lets you step through your source code Requires extra information attached to executable Location and type of every function and variable First instruction address corresponding to each line of source Usually requires extra switches to compiler and linker, e.g., -g Two popular graphical debuggers are ddd and xxgdb (on ECE/CIS machines) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Run a Executable File (OS View) The operating system performs the following steps: 1. Reads the executable file’s header to determine the size of the text and data segments. 2. “Establish” a new address space (e.g. via the creation of a new page table) for the program. This address space is large enough to hold the text and data segments, along with a stack segment 3. Copies instructions and data from the executable file into the new address space 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

4. Copies arguments passed to the program onto the stack. (cont’d) 4. Copies arguments passed to the program onto the stack. 5. Initializes the machine registers. In general, most registers are cleared but the stack pointer must be assigned the address of the first free stack location 6. Jumps to a start-up routine that copies the program’s arguments from the stack to registers and calls the program’s main routine. If the main routine returns, the start-up routine terminates the program with the exit system call. 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Typical Layout of an Executable File stack Dynamic date Reserved Text Static data $sp 7fff ffff hex $gp 1000 8000 1000 8000 pc 0040 0000 (From Patterson and Hennessy, p. 152; COPYRIGHT 1988 MORGAN KAUFMANN PUBLISHERS, INC. ALL RRIGHTS RESERVED) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

The Role of the OS Kernel The OS “kernel” performs the following essential functions: Manages resources (memory, disks, I/O) – mostly via “drivers” Switches between users (in a multi-user system such as copland) Provides convenient functions for applications to access resources Protects users from one another Provides essential “glue”, e.g., support for loaders For this to work efficiently, the CPU must have some support for the kernel. 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Processor Support for the OS kernel Most processors have at least 2 distinct levels or “modes”: “Supervisor” (or “privileged” or “kernel”) mode “User” level (including “root” or “administrator”) Lower levels can’t do some things, e.g., access the disk drive CPU boots in kernel mode; drops to user mode to run user code Early micros (such as 8086) lacked such modes 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Traps So once we’re in user mode, how do we get back to the privileged mode? Through “traps” – exceptional or unusual conditions requiring intervention by the kernel: Hardware error (divide by 0 or access to illegal memory address) Hardware “interrupt” (Ethernet card got data; mouse clicked) Clock signal telling multi-user OS to switch to another user “Software trap” when user code requests something from kernel PC reaches value stored in special “breakpoint” register 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Trap Handlers When a trap occurs, the CPU: Sets bits in special “status” reg., indicating the cause of the trap Switches to privileged mode Jumps to a “trap handler” (installed at boot time) at fixed location Handler reads status bits and takes appropriate action Return address saved, like jal instruction * When kernel is done, a special instruction return to the user code, dropping into user mode automatically 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Software Traps To do just about anything on the system involving shared resources (such as write to a file), the user code must ask the kernel to do it! User code gets access to the kernel through “trap” instructions “System calls” provided for operations such as writing files A function call to a system call converted to a software trap Args passed in the usual way (e.g., $a0-$a3 in MIPS) In MIPS, use the “syscall” instruction No operands in assemble-language instruction Specify which system call you want by putting a value in $v0 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

System Calls POSIX standard defines system calls and their numbers For instance, call no. 4 is the write() function: #include <unistd.h> ssize_t write(int fildes, cost void *buf, size_t nbyte); Every open file is identified by a unique “file descriptor” (int) This function writes nbyte bytes, starting at address buf, to the file 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Example: Call to printf() User code a.c calls printf (“Answer is %d\n”, i); printf() declared as an extern function in stdio.h Compiler generates a.o with printf unresolved in relocation table Data segment of a.o has string “Answer is %dl_” (NUL at end) 14 bytes, with local label (e.g., L314) in relocation table Reference resolved when linked with libc (C library): By linker if statically (e.g., -Bstatic in Sun CC) B y loader if dynamically 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Calling printf() Program sets args to printf (L314 and i)’ does jal printf printf (still in user mode) does the following: Creates new stack frame (as any non-leaf function should) Processes args; makes new string “Answer is 42l” in heap Creates args to write() function: Constant 1 in $a0 (file descriptor 1 is stdout) Address of heap string in $a1 Constant 13 in $a2 - Puts constant 4 in $v0 and does a syscall instruction 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Processing the Trap The CPU executes the syscall (trap) instruction: Switches to privileged mode Sets bits in status regs indicating trap caused by syscall Jumps to trap handler Trap handler checks status bits; sees trap came from syscall Checks call # in $v0; fetches 4th entry in function table and jumps System call transfers 13 bytes to low-level driver - Driver writes them to graphics display (if normal stdout) 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Toolchain Review Caller save /Callee save register Caller save register. The registers that the calling procedure (caller) is responsible for saving and restoring across the call. The called procedure (callee) can then modify the registers without constraint. Callee save register. The registers that the callee is responsible for saving and restoring if it might use. The caller uses the registers without worrying about restoring them after a call. 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Program Translates a.c a.o compile a.s assembly a.o- relocation table Int I; … Printf(“Answer is %d”, i) a.o compile a.s 323: Parameter pass 444: Jal reloc add.<printf> assembly … .text Parameter pass Jal printf .data a.o- relocation table Ref: <printf> 444 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Program Translates(cont.) printf.o printf.o- relocation table Executable file 555: Create stack Process args $a0 <- file ID $a1 <- adds. Of heap $a2 <- length of string $v0 <- 4 (write) Syscall ret __main: jal main jal exit Def: <printf> 555 Start-up routine L323: Parameter pass L444: Jal L555 a.o L555: Create stack Process args $a0 <- 1 $a1 <- adds. Of heap $a2 <- 13 $v0 <- 4 Syscall ret 323: Parameter pass 444: Jal reloc add.<printf> ret linker a.o- relocation table Ref: <printf> 444 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt

Program Translates (Cont.) Executable file user mode privileged mode __main: jal main jal exit main: Set status register Jal trap(4) handler (software trap) 323: Parameter pass 444: J reloc 555 trap(4) handler what trap -- syscall $v0 ? ------- 4 Jal 4th function driver 555: Create stack Process args $a0 <- 1 $a1 <- adds. Of heap $a2 <- 13 $v0 <- 4 Syscall ret. 4th function driver Transfer 13 bytes to graphic display 2/27/2019 \course\cpeg323-05F\Topic2d-323.ppt