my_notes_111

.pdf

School

University of California, Los Angeles *

*We aren’t endorsed by this school

Course

111

Subject

Computer Science

Date

Oct 30, 2023

Type

pdf

Pages

Uploaded by GrandLeopardPerson487

CS111 1 CS111 AD Notes SK Notes Lecture 1 - April 4 For Thursday, April 6 read the following: AD: $1-2, 36 SK: $1, 2-2.3 MK: interfaces What is a System? A set of interconnected components that have a specified behavior observed at the interface with its environment. What is an Operating System? American Heritage Dictionary (2000) obsolete Software designed to control the hardware of a specific data processing system in order to allow users and application programs to make use of it. Encarta(2007) Master Control program in a computer Wikipedia: system software that manages computer hardware, software resources and provides common services for computer programs OS Goals Protection: security Robustness: don’t fall over with unusual input Utilization: use your hardware! Performance: from the end users’ point of view Utilization and Performance can sometimes be competing goals Flexibility: general purpose, any application that you’d like. Not just able to run anything, but easy to run anything. Easy to configure for lots of different kinds of applications. Simplicity: If its simple, then it will have a number of technical advantages. Also relates to the OS being slim. Compatibility Portability: easy to switch from other OS inspectability: be able to peer into the OS to see what’s going on. Too often, things are busted! Also Open Source. OS Tools Abstraction - Managing Complexity. + Modularity. Interface vs implementation . Can change the implementation as we like as long as we keep the interface change. This is an important part of mantaining modularity.

CS111 2 Policy vs Mechanism : Policy, for example seasnet has the policy to process A vs a background B. Mechanism is the way we implement this policy. It’s crucial to keep the mechanism and policy separate, however. Measurement + Monitoring Performance + Correctness Need to monitor our system for bugs properly. AD - Main Problems Virtualization Concurrency Persistence SK Systems Problems 1. Incommensurate Scaling. Economies of Scale. Pin-factory. A good approach if we need a very large number of pins. Diseconomies of Scale. Star Network https://excalidraw.com/#room=02f18a5297e80871c4a6,Gnp2lxJ4D1JfK2zTxHpoEw 2. Emergent Properties. New Problem - Unanticipation of Larger Scales. 3. Propagation of Effects → Unanticipated module boundary crossings. Example Module 1: File Name Interpretation Module 2: Internationalization in Japan, i18n. Microsoft uses ShiftJis, which is a 2 byte system to interpret shift Jis internationally. The problem here is that can’t use your file names as actual names - can do some research about this here. 4. Tradeoffs - Waterbed effect. Focusing on one problem makes other problems worse. Moore’s law: Number of transistors/ chips doubles every 2 years 5. Complexity Kryder’s Law. Disk Drive capacity. AD - Chapter 2 - Virtualization

CS111 3 Lecture 2 - April 6 Write a program to count words in a file. ASCII text 1 byte/char terminated by ‘\0’ [A-Za-z] → starting at sector x86-64 50000 void main() { long long int nwords = 0; bool inword = false; char buf[512]; long long s = 50000; //first sector we read is 50000, but we increment the value while we're at it. while (true) { read_ide_sector(s++ , &buf[0]); for (int i = 0; i < 512; i++) { if (buf[i] == 0) { "answer is" nwords; return; } bool a = isalpha(buf[i]); nwords += a & ~inword; //get the same answer either way ! or ~ //bitwise operations are fast. Bitwise operations. inword = a; //check from previous letter } }

CS111 4 } IDE disk drive interface: 512-byte sectors. Therefore a part in drive with 512 bytes of data. Read sector and where to read sector into. void read_ide_sector(long long s: sector, char buf[512]); isalpha(a); //check whether it's an alphabet void answer_is(long long n) { short *p = (short *) 0xB800 + 1000;//position ourselves at the middle // of the screen do *--p = (n%10 + '0') + (7<<8) //7 is for grey text on a black background // The last 8 bits in the 16 bit are where it's incremented to. // Therefore, we left-shift 7 by 8, to place into the first 8 bits. // And then the last 8 bits have the numbers. // We're decrementing p, because we're starting from the rightmost // digit for the number that we're printing while (n /= 10) } Memory mapped I/O - popular IO method . Contains an appropriate array for display. Input Process for the Numbers X86-64 Instructions: inb - IOaddr, byte outb insl 1f0, %ebx, 128 Looking for a specific pattern to adjudge whether the data is ready for a read command from the disk drive into the RAM - for example the 01 pattern. → Is the disk controller ready? The data reading process We need to output 32 bits, 8 bits at a time to get the ide sector that we want to read from. In the ide_sector code given above. Hardware manual from a disk controller, then this will give us the exact registers this is 0x1f2, 0x1f3, 0x1f4, 0x1, which contain the sector that we want to read from. void read_ide_sector(long long s: sector, char buf[512]) { wait_for_ready(); //is the disk controller busy? outb(0x1f2, 1) //number of sectors //--------------// These are the 4 registers with the sector address. outb(0x1f3, s & 0xff); outb(0x1f4, s >> 0 & 0xff); outb(0x1f5, s >> 16 && 0xff); outb(0x1f6, s >> 24 && 0xff); //--------------// outb(0x1f7, 0x20); //This is the control/status register for the read command wait_for_ready(); insl(0x1f0, buf, 128) } Insl → single instruction from the POV of Kernel, transfer of sector data from disk via to the RAM (via the CPU). How does our program run in the first place? CPU Physical Memory [——RAM——|ROM] → size = 1MB

CS111 5 ROM is actually EEPROM Program goes into the ROM. We have 16 bytes of instruction available there In the ROM we put a jump instruction that jumps to executing our code. i.e. to gcc. Before doing a jump operation straight away, we actually need to stack pointer to jump example: lea 0x20000, %eip. Chain Loading - load another program from ROM that will load another program that does the work you need it to do. in ROM: main: read sectors 1000...2000 at location 0x6000 chain loading Booters actually use chain loading to boot: It’s called UEFI booting. What the ROM will do sometimes is: [ | | ROM ] → Flash (a kind of firmware - mix of software and hardware). What the UEFI is that it’s a standard for this kind of firmware. Flash drive in UEFI format. We can put a copy of a program in this format. Lecture 3 - April 11 Performance issues are prevalent. One idea to improve performance: Double Buffering . While we’re counting the number of words in one sector (from CPU), we can issue a read command for another sector (from disk) This uses more memory because we’re processing one sector while reading in another sector. However, 512 bytes * 2, therefore not much. However, x2 throughput. If we balance I/O power and CPU power, then double buffering will be good. Tripple Buffering isn’t necessarily useful, we can only keep CPU and disk busy at one time. DMA - Direct Memory Access → alternative to the insl command (research) void wait_for_ready( ): while (inb(0x1f7) & 0xc0 ≠ 0x40): yield( ); → let’s give the CPU to some other program while we’re waiting for ready The basic performance idea here is multiprogramming . Simpliyfing the job of doing some kind of performance improvement. For the read_ide_sector() code let’s have one copy of this machine code. All Apps share this copy. The main reason here is sort of maintenance. Where do we keep the one copy of this function though? boot: [————-RAM———-|——-ROM——] ← Put it in a well known location within ROM. Therefore, any one can call it. Any improvements that we make can be picked up by the system automatically. Programs are chained in RAM, and each chained program within RAM can call this program that’s within ROM. Alternative way : read_ide_sector( ) is within a well known location of RAM. As long as there’s a convention present there where each module can identify that the read_ide_sector( ) is where in the RAM. downside? Maintenance issues to rebuild the structure around read_ide_sector( ) Too much of a pain to change our library functions Too much of a pain to reuse code in other programs. We’re going to take some of our code and burn it onto RAM, for example? No Too much of a pain to run programs simultaneously. What if we forget to mention the yield command. Too much of a pain to run buggy program. CPU takes too much time, for example.

CS111 6 Improvements for read_ide_sector( ) function void read_ide_sector(long → sector no. , char* → buf) But what if we have multiple sectors? void read_ide_sector(int → drive no. , long, chat* ) → drive that contains multiple sectors Make it better → we can’t just assume the size of the sector? void read_ide_sector-buf(int, long, char*, size_t → number of bytes, should be a multiple of the sector size) ssize_t ← success indication, size of the sector that’s been read | read_end_buf(long long, char* , size_t) → problems: no protection here. What if we give a size that spans greater than one drive → so we read 2 drives. solution : side note: void* v is a convention in C, that reads the bytes from the file into the memory location. Also there this doesn’t have to be of specific data type, for example char* buf, which is conventionally used. ssize_t read(int, void* v, size_t). The int is a file descriptor index Another process to read and the problem with it: char* readline(int fd, char delimiter); while((p == readline((null, ‘\n’)): process_line(p); need to define -> free(); // free up memory What’s the problems with this: what we’re reading is unbounded! vs when we’re giving a specific byte size. It can also cross sectors. Memory allocation: Programmers will have to free up pointers, for example if freed up early then dangling pointers.r Later run the following linux command: man readline Can see possible implementations of readline here The functions that we’ve discussed above achieve. modularity Modularity: breaking our program into different pieces. This has a lot of advantages: assign each piece into a separate problem. decrease our total work #bugs of size of program cost to fix bugs O(N^2) because dependent on size and pieces However, with modularity, we can fix it in O(N^2/k) Abstraction through modularity: implement an interface between your module and the rest of the application. Implementing Modularity through function call: gcc -o1 -S long fact(long n){ if (n==0) { return 1; } return n*fact(n-1); } In Machine Code:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version