Programming Languages - (part 1 of 7)

a computer program ultimately is made up of machine code binary structures which are read and executed by the CPU and the earliest days of computers back in the 1940s these machines structures were input by flipping switches and moving vacuum tube plugs around this of course was extremely clumsy because it required a lot of work by hand every time you wanted to run a program so to fix this computers began to store code on punch cards a punch card is just a thick piece of paper with perforated holes and patterns to denote data and programs can be stored as stacks of punch cards to feed into the machine the process of creating these punch cards was still extremely tedious and it was a huge headache when a stack got out of order but at least now a program could be loaded multiple times without manually inputting each instruction one by one in the 1960s computers began to use terminals devices which combined an electronic keyboard with some kind of text display their earlier terminals printed out text on paper later terminals introduced electronic screens though usually these screens could only display monochromatic text not graphical images also in the 60s computers began to store code and data on electronic mediums most commonly magnetic tape in combination with electronic screen terminals computer users for the first time could read and write text directly on the machine so the question is how does text entry help us write machine code well one answer is to use a hex editor a program which allows us to create and edit a file byte by byte using X notation while feasible this approach is very impractical even if you are extremely familiar with the machine code of the processor for which your writing is just very taxing and cumbersome to write code directly in binary form the better solution is to use what's called an assembly language in an assembly language each binary instruction is expressed in a more human readable way usually as short mnemonics for example an add instruction is commonly denoted with the mnemonic a DD of course the machine can't execute text data so this text has to be translated somehow into binary instructions we call this translation process assembly hence the term assembly language here's the hello world program written in an assembly language hello world program recall simply prints the words hello world on the screen understand that the assembly code is always processor specific because the minor instructions for one processor differ from the binary instructions for another in fact there really is no such thing as the assembly language there are different assembly languages for different processors collectively though they're often called assembly language so there is assembly for x86 processor assembly for ARM processors for mist processors and so forth this particular example is x86 code also understand that system calls our operating system specific so assembly code written to run on one operating system generally won't run on another this code here is written to run on Linux so even though it's x86 code it won't run on Microsoft Windows like in all programming languages the assembly code written as text by the programmer is known as source code the computer of course can't directly execute this code rather the source code must be translated machine code by a program called an assembler for any particular processor they may be multiple assemblers available and the precise assembly language understood by one assembler may differ from the assembly understood by another assembler for that same processor for example one popular x86 assembler is Microsoft's assembler often called NASM code written for the Microsoft assembler won't be understood by other x86 assemblers so assembly code is not only processor and OS specific it's also assembler specific in any case let's say our source code is written in a file called hello dot azzam when we run this file through the assembler what we get out is not an executable file but rather what's called an object file to produce an actual executable file we run the object file through another program called a linker the reason for this extra step is that in practice we usually write the code of a program in multiple source files files which we may wish to assemble independently for example if I've written my code in two files food azam and bar dot Azzam and i want to produce one single executable file here called baz i first run each source file through the assembler independently producing an object file for each and then those two object files are run together through the linker producing the executable a linker is so named because it must resolve the links in code between the object files though we may write our code in separate source files the code of our program is interdependent such that code in one source file may invoke code written in another for example in foo we might invoke a function defined in bar but because the source files are assembled independently the assembler can't know the actual address of the function and bar win assembling foo what the assembly does then is leave a stub address where the function is invoked later the linker will fill in these stubs with actual addresses now we could just combine the linking and the assembly phases together in one single program so that we don't have to run two separate programs however we'd like to keep the processes separate so that we can minimize work when we make code changes by assembling only the source files we've changed then linking those new object files with the other object files by default when the process runs code in this address space comes just from the single executable file which launched the program however modern operating systems like Windows and Linux allow programs to Lincoln code from other files during execution these files of code are called dynamic linking libraries on Windows denoted with a file extension DLL and shared object files on Linux the notable of the file extension dot s Oh more generally they are sometimes called shared libraries to make use of shared libraries requires instructing the linker to leave some stubs in the executable for the operating system to dynamically link at runtime to create a shared library file we simply run the object files we want to include in that library through a linker with the appropriate options so you may be wondering why would we want to use shared libraries and dynamic linking why not just statically link everything into one X Cuba file well one reason is to avoid producing needlessly large executable files the concern these days though is not that the executable files will waste storage space stored space today is very very cheap the real concern is memory usage when multiple programs running simultaneously all make use of the same common code it saves memory to load only one copy of that shared code and this is exactly what modern operating systems allow us to do with shared libraries when multiple processes all use the same shared library the libraries included in each processes address space in their virtual memory but the actual code is stored just once in physical memory

Channel: Brian Will

Views: 84,958

Rating: 4.9542484 out of 5

Keywords:

Id: vjtywpx2SDY

Length: 6min 47sec (407 seconds)

Published: Mon Aug 12 2013