Topic 2e High-Level languages and Systems Software - PowerPoint PPT Presentation

ann
topic 2e high level languages and systems software n.
Skip this Video
Loading SlideShow in 5 Seconds..
Topic 2e High-Level languages and Systems Software PowerPoint Presentation
Download Presentation
Topic 2e High-Level languages and Systems Software

play fullscreen
1 / 37
Download Presentation
Topic 2e High-Level languages and Systems Software
109 Views
Download Presentation

Topic 2e High-Level languages and Systems Software

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Topic 2eHigh-Level languages and Systems Software (Memory Layout) Introduction to Computer Systems Engineering (CPEG 323) \course\cpeg323-05F\Topic2e-323.ppt

  2. Reading List • Slides: Topic2e • Operating System and Compiler Books • Other papers as assigned in class or homeworks \course\cpeg323-05F\Topic2e-323.ppt

  3. Several Topics • Object File Format • GP register and GP area • Run-time Stack • Virtual / Physical memory \course\cpeg323-05F\Topic2e-323.ppt

  4. Object File Format Compiler or assembler translates the program into an object file, which is consequently linked into a executable file. These "object" files and "executable" files have a specific format. Several common formats are: • a.out: assembler and linker output format • COFF: Common Object File Format • ECOFF: Extended Common Object File Format • ELF: Executable and Linking Format \course\cpeg323-05F\Topic2e-323.ppt

  5. Object File Format(Cont.) • a.out: assembler and linker output format A fairly primitive format, lacking some key features to enable easy shared libraries, etc. On UNIX boxes, a.out is the default output format of the system assembler and the linker. The linker makes a.out executable files. A file in a.out format consists of: a header, the program text, program data, text and data relocation information, a symbol table, and a string table (in that order). \course\cpeg323-05F\Topic2e-323.ppt

  6. Object File Format(Cont.) • Common Object File Format (COFF) binary files • COFF is a portable format for binary applications on UNIX System V • Extended Common Object File Format (ECOFF) binary files • Under Windows, Visual C, C++ and every Windows compiler generates ECOFF files. • MIPS \course\cpeg323-05F\Topic2e-323.ppt

  7. Object File Format(Cont.) • ELF: Executable and Linking Format • ELF and COFF formats are very similar but ELF has greater power and flexibility • Become the standard in file format • ELF representation is platform independent \course\cpeg323-05F\Topic2e-323.ppt

  8. Object File Format(Cont.) • Three main types of ELF files • executable file supplies information necessary for the operating system to create a process image. • relocatable file describes how it should be linked with other object files to create an executable file or shared library. • shared object file contains information needed in both static and dynamic linking. \course\cpeg323-05F\Topic2e-323.ppt

  9. ELF Object File Format ELF Format Linking and Execution Views \course\cpeg323-05F\Topic2e-323.ppt

  10. ELF Object File Format(Cont.) The ELF Header • ELF Header is always the first section of the file(The other sections can be in any order) • What does the ELF Header describe? ● the type of the object file ● target architecture ● The location of the Program Header table, Section Header table, and String table ● number and size of entries for each table the ELF ● the location of the first executable instruction \course\cpeg323-05F\Topic2e-323.ppt

  11. ELF Object File Format(Cont.) The Program Header Table • only important in executable and shared object files • It is an array of entries • each entry is a structure describing a segment in the object file • The OS copies the segment into memory according to the location and size information \course\cpeg323-05F\Topic2e-323.ppt

  12. ELF Object File Format(Cont.) The Section Header Table • Has pointers to all sections in object files • It is similar to the program header • Each entry correlates to a section in the file. • Each entry provides the name, type, memory image starting address, file offset, the section’s size, alignment, and how the information in the section should be interpreted. \course\cpeg323-05F\Topic2e-323.ppt

  13. ELF Object File Format(Cont.) The ELF Sections • Hold code, data, dynamic linking information, debugging data, symbol tables, relocation information, comments, string tables, and notes. • Sections are treated in different ways ● loaded into the process image ● or provide information needed in the building of a process image ● or are used only in linking object files \course\cpeg323-05F\Topic2e-323.ppt

  14. ELF Object File Format(Cont.) The ELF Segments • Group related sections ● text segment groups executable code, ● data segment groups the program data, ● dynamic segment groups information relevant to dynamic loading. • Each segment consists of one or more sections. • A process image is created by loading and interpreting segments. • The OS logically copies a file’s segment to a virtual memory segment according to the information provided in the program header table. \course\cpeg323-05F\Topic2e-323.ppt

  15. GP Register and GP Area 0xEFFFFFFF Stack Heap BSS positive offset Global data area 64k GP 0x10008000 negative offset Data Text 0x00000000 \course\cpeg323-05F\Topic2e-323.ppt

  16. GP Register and GP Area(Cont.) Why Global Data Area ? Load variable x to r10 Without GP: 3 instructions Li r9, x -- low 16-bit of x Addiu r9, x -- high 16-bit of x Lw r10, 0(r9) -- load With GP: 1 – instruction LW r10, 24(GP) -- load \course\cpeg323-05F\Topic2e-323.ppt

  17. What should be put into Global Data Area ? GP Register and GP Area(Cont.) Most Frequently Access Data How to Use Global Data Area ? •Global Data Area requires linker support • $gp register must be correctly initialized (by the startup routine) • assembly code must not modify the $gp register \course\cpeg323-05F\Topic2e-323.ppt

  18. Runtime Stack Stack organization High memory argumentn …… argument1 Virtual frame Pointer($fp) Frame offset Local & temporaries framesize Saved registers (including returnreg) Procedure call Argument area static Pointer($sp) …… low memory \course\cpeg323-05F\Topic2e-323.ppt

  19. Stack and Frame Example 1: int total; int sum_all(int a1, int a2, int a3, int a4,int a5, int a6, int a7, int a8) { return a1+a2+a3+a4+a5+a6+a7+a8; } Main() { total=sum_all(1,2,3,4,5,6,7,8); printf(“total = %d\n”, total); } \course\cpeg323-05F\Topic2e-323.ppt

  20. Stack and Frame – enter main() $fp=0 0x7fffffff subu $sp, $sp, 40 ? sw $31, 36($sp) sw $fp, 32($sp) move $fp, $sp ? li $2, 0x5 ? sw $2, 16($sp) li $2, 0x6 ? sw $2, 20($sp) li $2, 0x7 sw $2, 24($sp) li $2, 0x8 sw $2, 28($sp) li $4, 0x1 li $5, 0x2 li $6, 0x3 li $7, 0x4 jal sum_all … $sp=0x7ffff7fe8 $31 ($ra) $30 ($fp) 8 7 6 5 $sp=0x7ffff7fc0 $fp=$sp 0x00000000 \course\cpeg323-05F\Topic2e-323.ppt

  21. Stack and Frame – enter sum_all() 0x7fffffff subu $sp, $sp, 8 sw $fp, 0($sp) move $fp, $sp sw $4, 8($sp) sw $5, 12($sp) sw $6, 16($sp) sw $7, 20($sp) … move $sp, $fp lw $fp, 0($sp) addu $sp, $sp, 8 j $31 0x7ffff7fe8 $31 ($ra) $30 ($fp) 8 7 6 5 4 3 2 $sp=0x7ffff7fc0 1 $fp=$sp $30 ($fp) $sp=0x7ffff7fb0 $fp=$sp 0x00000000 \course\cpeg323-05F\Topic2e-323.ppt

  22. Stack and Frame – exit sum_all() 0x7fffffff subu $sp, $sp, 8 sw $fp, 0($sp) move $fp, $sp sw $4, 8($sp) sw $5, 12($sp) sw $6, 16($sp) sw $7, 20($sp) … move $sp, $fp lw $fp, 0($sp) addu $sp, $sp, 8 j $31 0x7ffff7fe8 $31 ($ra) $30 ($fp) 8 7 6 5 4 3 2 1 $sp $fp $30 ($fp) $sp=0x7ffff7fb0 $fp=$sp 0x00000000 \course\cpeg323-05F\Topic2e-323.ppt

  23. Stack and Frame – exit main() 0x7fffffff … move $sp, $fp lw $31, 36($sp) lw $fp, 32($sp) addu $sp, $sp, 40 j $31 $sp $fp =0 $31 ($ra) $30 ($fp) 8 7 6 5 4 3 2 1 $sp $fp $30 ($fp) 0x00000000 \course\cpeg323-05F\Topic2e-323.ppt

  24. Stack and Frame • Do we really need store $4 to $7 onto stack? • An optimized version sum_all: lw $3, 16($sp) lw $8, 20($sp) lw $9, 24($sp) lw $2, 28($sp) addu $4, $4, $5 addu $4, $4, $6, addu $4, $4, $7 addu $4, $4, $3, addu $4, $4, $8 addu $4, $4, $9, addu $2, $4, $2 j $31 \course\cpeg323-05F\Topic2e-323.ppt

  25. Stack and Frame Example 2: where are the local variables (automatic variable) int sum_all(int a1, int a2, int a3, int a4,int a5, int a6, int a7, int a8) { int total; total=a1+a2+a3+a4+a5+a6+a7+a8; return total; } int test() { return sum_all(1,2,3,4,5,6,7,8); } main() { total=test(); printf(“total = %d\n”, total); } \course\cpeg323-05F\Topic2e-323.ppt

  26. Stack and Frame – main() 0x7fffffff $sp total $31 ($ra) $30 ($fp) r7 r6 r5 r4 $sp $fp 0x00000000 \course\cpeg323-05F\Topic2e-323.ppt

  27. Stack and Frame – test() 0x7fffffff total $31 ($ra) $30 ($fp) r7 r6 r5 r4 $sp $fp $31 $fp 8 7 6 5 $sp $fp 0x00000000 \course\cpeg323-05F\Topic2e-323.ppt

  28. Stack and Frame – sum_all() 0x7fffffff total $31 ($ra) $30 ($fp) main r7 r6 r5 r4 $31 $fp 8 7 test 6 5 sum_all $fp total $sp $fp 0x00000000 \course\cpeg323-05F\Topic2e-323.ppt

  29. Run-time Stack Fib: sub $sp, $sp, 12 sw $s0, 4($sp) sw $s1, 8($sp) sw $ra, 0($sp) beq $a0, $0, L1 mov $t0, 1 beq $a0, $t0, L1 mov $s0, $a0 sub $a0, $a0, 1 jal fib mov $s1, $v0 subi $a0, $s0, 2 jal fib add $v0, $v0, $s1 j L2 L1: addi $v0, $0, 1 L2: lw $s1, 8($sp) lw $s0, 4($sp) lw $ra, 0($sp) add $sp, $sp, 12 j $ra Fib(3) SP $s1 - unknown $s0 - unknown $ra – return to main Fib(2) $s1 - unknown $s0 - unknown ret1 $ra – ret1 ret2 Fib(1) \course\cpeg323-05F\Topic2e-323.ppt

  30. Virtual / Physical memory • User memory space • OS memory space \course\cpeg323-05F\Topic2e-323.ppt

  31. 0x7FFF EFFF Stack Heap BSS Text: instructions Data: variables with initial value BSS: variables without initial value HEAP: for malloc/free STACK: for function call Global Data Data Text 0x0040 0000 Layout of Memory (virtual memory - user) \course\cpeg323-05F\Topic2e-323.ppt

  32. Reserved for kernel 800000016 Stack segment Dynamic data Data segment Static data Text segment 40 000016 Reserved For Interrupt vector Firmware Layout of Memory ( OS memory space) \course\cpeg323-05F\Topic2e-323.ppt

  33. Virtual Memory / Physical Memory • Why Virtual Memory • Limited physical memory size • 64MB to 1GB • Unlimited virtual memory size • Each process may have 2GB • Many processes in the system \course\cpeg323-05F\Topic2e-323.ppt

  34. Virtual Memory/Physical Memory • Physical memory as cache of virtual memory (disk) • Physical memory and virtual memory broke into fixed size pages; • Each physical page holds a virtual page (may come from different processes) • Only the active pages of each process reside in physical memory, physical memory works as cache of virtual memory (disk) • Other pages stay on disk P2: pagen Pn: pagem P1: pagek Physical pagei Page table Physical address Virtual address v rwx Physical page Start address Virtual page Disk address Present bit Protection bits \course\cpeg323-05F\Topic2e-323.ppt

  35. Virtual and Physical Memory Physical Memory Process 1 Process 2 OS U1/P0 U2/P0 Page 0 OS U1/P1 U2/P1 Page 1 U1/P0 U1/P2 U2/P2 Page 2 U2/P3 U1/P3 U2/P3 Page 3 U1/P3 U1/P4 U2/P4 Page 4 U1/P7 U1/P5 U2/P5 Page 5 U1/P6 U1/P6 U2/P6 Page 6 U2/P1 U1/P7 U2/P7 Page 7 On Disk \course\cpeg323-05F\Topic2e-323.ppt

  36. Virtual Memory / Physical Memory Why Segmentation Fault ? main() { int *p; *p=12; } Invalid pointer – p points to arbitrary address (address 0?) Page protection will assign “readable/executable” to the pages in this section \course\cpeg323-05F\Topic2e-323.ppt

  37. Physical / Virtual Memory #include <malloc.h> main() { int *p; p=(int *)malloc(sizeof(int)); *p=12; } \course\cpeg323-05F\Topic2e-323.ppt