Особенности операционной системы UNIX курсовая по информатике , Дипломная из Информатика

Скачай Особенности операционной системы UNIX курсовая по информатике и еще Дипломная в формате PDF Информатика только на Docsity! КУРСОВАЯ РАБОТА по дисциплине : «Информатика» тема: «Особенности операционной системы UNIX» 2005 г. Задание: Дать описание основных особенностей операционной системы UNIX. F 0 2 A( ) Организации, получившие права на перепродажу с надбавкой к цене за дополнительные услуги, оснащают вычислительную систему прикладными программами, касающимися конкретных областей применения, стремясь удовлетворить требования рынка. Такие организации чаще продают прикладные программы, нежели операционные системы, под управлением которых эти программы раб тают. F 0 2 A F 0 2 A( ) А что же версия IV ? Модификация внутреннего варианта системы получила название "версия V". F 0 2 A F 0 2 A F 0 2 A( ) В некоторых реализациях системы UNIX операционная система взаимодействует с обствен-ной операционной системой, которая, в свою очередь, взаимодействует с аппаратурой и выполняет необходимые функции по обслуживанию системы. В таких реализациях допускается инсталляция других операционных систем с загрузкой под их управлением прикладных программ параллельно с системой UNIX. Классическим примером подобной реализации явилась система MERT [Lycklama 78a]. Более новым примером могут служить реализации для компьютеров серии IBM 370 [Felton 84] и UNIVAC 100 [Bodenstab 84]. F 0 2 A F 0 2 A F 0 2 A F 0 2 A( )Каталог "/bin" содержит большинство необходимых команд и обычно входит в число каталогов, в которых ведет поиск командный процессор shell. СОДЕРЖАНИЕ ВВЕДЕНИЕ ……………………………………………………………………. 4 ОБЗОР ОСОБЕННОСТЕЙ СИСТЕМЫ ……………………………………4 1. ИСТОРИЯ ………………………………………………………………4 2. СТРУКТУРА СИСТЕМЫ …………………………………………….8 3. ОБЗОР С ТОЧКИ ЗРЕНИЯ ПОЛЬЗОВАТЕЛЯ …………………..10 3.1 Файловая система …………………………………………..10 3.2 Среда выполнения процессов ……………………………..14 3.3 Элементы конструкционных блоков …………………….17 4. ФУНКЦИИ ОПЕРАЦИОННОЙ СИСТЕМЫ ……………………..19 5. ПРЕДПОЛАГАЕМАЯ АППАРАТНАЯ СРЕДА……………………20 5.1 Прерывания и особые ситуации …………………………. 22 5.2 Уровни прерывания процессора …………………………. 22 5.3 Распределение памяти ……………………………………... 23 6. ВЫВОДЫ ………………………………………………………………. 24 ЛИТЕРАТУРА ……………………………………………………………………...25 применение в реальном проекте. Так, для того, чтобы обеспечить функциониро- вание системы обработки текстов для патентного отдела фирмы Bell Laboratories, в 1971 году система UNIX была перенесена на ЭВМ PDP-11. Систе- ма отличалась небольшим объемом: 16 Кбайт для системы, 8 Кбайт для программ пользователей, обслуживала диск объемом 512 Кбайт и отводила под каждый файл не более 64 Кбайт. После своего первого успеха Томпсон собрался было написать для новой системы транслятор с Фортрана, но вместо этого занялся языком Би (B), предшественником которого явился язык BCPL [Richards 69]. Би был интер- претируемым языком со всеми недостатками, присущими подобным языкам, поэ- тому Ричи переделал его в новую разновидность, получившую название Си (C) и разрешающую генерировать машинный код, объявлять типы данных и определять структуру данных. В 1973 году система была написана заново на Си, это был шаг, неслыханный для того времени, но имевший огромный резонанс среди сто- ронних пользователей. Количество машин фирмы Bell Laboratories, на которых была инсталлирована система, возросло до 25, в результате чего была создана группа по системному сопровождению UNIX внутри фирмы. В то время корпорация AT&T не могла заниматься продажей компьютерных продуктов в связи с соответствующим соглашением, подписанным ею с федераль- ным правительством в 1956 году, и распространяла систему UNIX среди универ- ситетов, которым она была нужна в учебных целях. Следуя букве соглашения, корпорация AT&T не рекламировала, не продавала и не сопровождала систему. Несмотря на это, популярность системы устойчиво росла. В 1974 году Томпсон и Ричи опубликовали статью, описывающую систему UNIX, в журнале Communications of the ACM [Thompson 74], что дало еще один импульс к распространению системы. К 1977 году количество машин, на которых функционировала система UNIX, увеличилось до 500, при чем 125 из них работали в университетах. Система UNIX завоевала популярность среди телефонных компаний, поскольку обеспечивала хорошие условия для разработки программ, обслуживала работу в сети в режиме диалога и работу в реальном масштабе времени (с помощью системы MERT [Lycklama 78a]). Помимо университетов, лицензии на систему UNIX были переданы коммерческим организациям. В 1977 году корпорация Interactive Systems стала первой организацией, получившей права на перепродажу системы UNIX с надбавкой8 к цене за дополнительные услуги (�), которые заключались в адаптации системы к функционированию в автоматизированных системах управления учрежденческой деятельностью. 1977 год также был отмечен "переносом" системы UNIX на машину, отличную от PDP (благодаря чему стал возможен запуск системы на другой машине без изменений или с небольшими изменениями), а именно на Interdata 8/32. С ростом популярности микропроцессоров другие компании стали переносить систему UNIX на новые машины, однако ее простота и ясность побудили многих разработчиков к самостоятельному развитию системы, в результате чего было создано несколько вариантов базисной системы. За период между 1977 и 1982 годом фирма Bell Laboratories объединила несколько вариантов, разработанных в корпорации AT&T, в один, получивший коммерческое название UNIX версия III. В дальнейшем фирма Bell Laboratories добавила в версию III несколько новых особенностей, назвав новый продукт UNIX версия V (� F 0 2 A), и эта версия стала официально распространяться корпорацией AT&T с января 1983 года. В то же время сотрудники Калифорнийского университета в Бэркли разработали вариант системы UNIX, получивший название BSD 4.3 для машин серии VAX и отличающийся некоторыми новыми, интересными особенностями. К началу 1984 года система UNIX была уже инсталлирована приблизительно на 100000 машин по всему миру, при чем на машинах с широким диапазоном вы- числительных возможностей - от микропроцессоров до больших ЭВМ - и разных изготовителей. Ни о какой другой операционной системе нельзя было бы сказать того же. Популярность и успех системы UNIX объяснялись несколькими причина- ми: • Система написана на языке высокого уровня, благодаря чему ее легко читать, понимать, изменять и переносить на другие машины. По оценкам, сделанным Ричи, первый вариант системы на Си имел на 20-40 % больший объем и работал медленнее по сравнению с вариантом на ассемблере, однако преимущества ис- пользования языка высокого уровня намного перевешивают недостатки [Ritchie 78b], стр. 1965). • Наличие довольно простого пользовательского интерфейса, в котором имеется возможность предоставлять все необходимые пользователю услуги. • Наличие элементарных средств, позволяющих создавать сложные программы из более простых. • Наличие иерархической файловой системы, легкой в сопровождении и эффектив- ной в работе. • Обеспечение согласования форматов в файлах, работа с последовательным потоком байтов, благодаря чему облегчается чтение прикладных программ. • Наличие простого, последовательного интерфейса с периферийными устройства- ми. • Система является многопользовательской, многозадачной; каждый пользователь может одновременно выполнять несколько процессов. • Архитектура машины скрыта от пользователя, благодаря этому облегчен про- цесс написания программ, работающих на различных конфигурациях аппаратных средств. Простота и последовательность вообще отличают систему UNIX и объясняют большинство из вышеприведенных доводов в ее пользу. Хотя операционная система и большинство команд написаны на Си, система UNIX поддерживает ряд других языков, таких как Фортран, Бейсик, Паскаль, Ада, Кобол, Лисп и Пролог. Система UNIX может поддерживать любой язык прог- раммирования, для которого имеется компилятор или интерпретатор, и обеспечи- вать системный интерфейс, устанавливающий соответствие между пользователь- скими запросами к операционной системе и набором запросов, принятых в UNIX. 2. СТРУКТУРА СИСТЕМЫ На Рисунке 1.1 изображена архитектура верхнего уровня системы UNIX. Тех- нические средства, показанные в центре диаграммы, выполняют функции, обеспе- чивающие функционирование операционной системы. Операционная система взаимодействует с аппаратурой непосредственно(� F 0 2 AF 0 2 A), обеспечивая обслуживание программ и их независимость от деталей аппаратной конфигурации. Если представить систему состоящей из пластов, в нейможно выделить системное ядро, изолированное от пользовательских Рисунок 1.1. Архитектура системы UNIX программ. Поскольку программы не зависят от аппаратуры, их легко переносить из одной системы UNIX в другую, функционирующую на другом комплексе техни- ческих средств, если только в этих программах не подразумевается работа с конкретным оборудованием. Например, программы, расчитанные на определенный размер машинного слова, гораздо труднее переводить на другие машины по срав- нению с программами, не требующими подобных установлений. Программы, подобные командному процессору shell и редакторам (ed и vi) и показанные на внешнем по отношению к ядру слое, взаимодействуют с ядром при помощи хорошо определенного набора обращений к операционной системе. Обращения к операционной системе понуждают ядро к выполнению различных операций, которых требует вызывающая программа, и обеспечивают обмен данны- ми между ядром и программой. Некоторые из программ, приведенных на рисунке, в стандартных конфигурациях системы известны как команды, однако на одном уровне с ними могут располагаться и доступные пользователю программы, такие как программа a.out, стандартное имя для исполняемого файла, созданного компилятором с языка Си. Другие прикладные программы располагаются выше указанных программ, на верхнем уровне, как это показано на рисунке. Например, стандартный компилятор с языка Си, cc, располагается на самом внешнем слое: он вызывает препроцессор для Си, ассемблер и загрузчик (компоновщик), т.е. отдельные программы предыдущего уровня. Хотя на рисунке приведена двухуровневая иерархия прикладных программ, пользователь может расширить иерархическую структуру на столько уровней, сколько необходимо. В самом деле, тема и программы, такие как ls (выводит список имен и атрибутов файлов), могли их обнаружить. Права доступа к файлу регулируются установкой специальных битов разреше- ния доступа, связанных с файлом. Устанавливая биты разрешения доступа, можно независимо управлять выдачей разрешений на чтение, запись и выполнение для трех категорий пользователей: владельца файла, группового пользователя и прочих. Пользователи могут создавать файлы, если разрешен доступ к каталогу. Вновь созданные файлы становятся листьями в древовидной структуре файловой системы. Для пользователя система UNIX трактует устройства так, как если бы они были файлами. Устройства, для которых назначены специальные файлы устройств, становятся вершинами в структуре файловой системы. Обращение программ к уст- ройствам имеет тот же самый синтаксис, что и обращение к обычным файлам; се- мантика операций чтения и записи по отношению к устройствам в большой степе- ни совпадает с семантикой операций чтения и записи обычных файлов. Способ защиты устройств совпадает со способом защиты обычных файлов: путем соответ- ствующей установки битов разрешения доступа к ним (файлам). Поскольку имена устройств выглядят так же, как и имена обычных файлов, и поскольку над устройствами и над обычными файлами выполняются одни и те же операции, большинству программ нет необходимости различать внутри себя типы обрабатываемых файлов. Например, рассмотрим программу на языке Си (Рисунок 1.3), в которой соз- дается новая копия существующего файла. Предположим, что исполняемая версия программы имеет наименование copy. Для запуска программы пользователь вводит с терминала: copy oldfile newfile где oldfile - имя существующего файла, а newfile - имя создаваемого файла. Система выполняет процедуру main, присваивая аргументу argc значение количест- ва параметров в списке argv, а каждому элементу массива argv значение парамет- ра, сообщенного пользователем. В приведенном примере argc имеет значение 3, элемент argv[0] содержит строку символов "copy" (имя программы условно являет- ся нулевым параметром), argv[1] - строку символов "oldfile", а argv[2] - строку символов "newfile". Затем программа проверяет, правильное ли количество параметров было указано при ее запуске. Если это так, запускается операция open (открыть) для файла oldfile с параметром "read-only" (только для чтения), в случае успешного выполнения которой запускается операция creat (открыть) для файла newfile. Режим доступа к вновь созданному файлу описывается числом 0666 (в восьмиричном коде), что означает разрешение доступа к файлу для чтения и записи для всех пользователей. Все обращения к операционной системе в случае неудачи возвращают код -1; если же неудачно завершаются операции open и creat, программа выдает сообщение и запускает операцию exit (выйти) с возвращением кода состояния, равного 1, завершая свою работу и указывая на возникновение ошибки. Операции open и creat возвращают целое значение, являющееся дескриптором файла и используемое программой в последующих ссылках на файлы. После этого программа вызывает подпрограмму copy, выполняющую в цикле операцию read (чи- тать), по которой производится чтение в буфер порции символов из существующего файла, и операцию write (писать) для записи информации в новый файл.Операция read каждый раз возвращает количество прочитанных байтов (0 – если достигнут конец файла). Цикл завершается, если достигнут конец файла или если произошла ошибка при выполнении операции read (отсутствует контроль возникновения ошибок при выполнении операции write). Затем управление из подпрограммы copy возвращается в основную программу и запускается операция exit с кодом состояния 0 в качестве параметра, что указывает на успешное завершение выполнения программы. Программа копирует любые файлы, указанные при ее вызове в качестве аргумен- тов, при условии, что разрешено открытие существующего файла и создание нового файла. Файл может включать в себя как текст, который может быть выведен на печатающее устройство, например, исходный текст программы, так и символы, не выводимые на печать, даже саму программу. Таким образом, оба вызова: copy copy.c newcopy.c copy copy newcopy являются допустимыми. Существующий файл также может быть каталогом. Например, по вызову: copy . dircontents копируется содержимое текущего каталога, обозначенного символом ".", в обыч- ный файл "dircontents"; информация в новом файле совпадает, вплоть до каждо- го байта, с содержимым каталога, только этот файл обычного типа (для созда- ния нового каталога предназначена операция mknod). Наконец, любой из файлов может быть файлом устройства. Например, программа, вызванная следующим обра- зом: #include char buffer[2048]; int version = 1; main(argc,argv) int argc; char *argv[]; { int fdold,fdnew; if (argc != 3) { printf("need 2 arguments for copy program\n); exit(1); } fdold = open(argv[1],O_RDONLY); /* открыть исходный файл только для чтения */ if (fdold == -1) { printf("cannot open file %s\n",argv[1]); exit(1); } fdnew = creat(argv[2],0666); /* создать новый файл с разрешением чтения и записи для всех пользователей */ if (fdnew == -1) { printf("cannot create file %s\n",argv[2]); exit(1); } copy(fdold,fdnew); exit(0); } copy(old,new) int old,new; { int count; while ((count = read(old,buffer,sizeof(buffer))) > 0) write(new,buffer,count); } Рисунок 1.3. Программа копирования файла copy /dev/tty terminalread читает символы, вводимые с терминала (файл /dev/tty соответствует терминалу пользователя), и копирует их в файл terminalread, завершая работу только в том случае, если пользователь нажмет. Похожая форма запуска программы: copy /dev/tty /dev/tty вызывает чтение символов с терминала и их копирование обратно на терминал. 3.2 Среда выполнения процессов полняется, не дожидаясь завершения выполнения предыдущей команды. О коман- дах, выполняемых асинхронно, говорят, что они выполняются на фоне других ко- манд. Например, ввод команды who вызывает выполнение системой программы, хранящейся в файле /bin/who (� F 0 2 AF 0 2 AF 0 2 A) и осуществляющей вывод списка пользователей, которые в настоящий момент работают с системой. Пока команда who выполняется, командный процессор shell ожидает завершения ее выполнения и только затем запрашивает у пользователя следующую команду. Если же ввести команду who & система выполнит программу who на фоне и shell готов немедленно принять сле- дующую команду. В среду выполнения каждого процесса в системе UNIX включается текущий каталог. Текущий для процесса каталог является начальным каталогом, имя ко- торого присоединяется ко всем именам путей поиска, которые не начинаются с наклонной черты. Пользователь может запустить внутреннюю команду shell'а cd (изменить каталог) для перемещения по дереву файловой системы и для смены текущего каталога. Командная строка cd /usr/src/uts делает текущим каталог "/usr/src/uts". Командная строка cd ../.. делает текущим каталог, который на две вершины "ближе" к корню (корневому каталогу): параметр ".." относится к каталогу, являющемуся родительским для текущего. Поскольку shell является пользовательской программой и не входит в состав ядра операционной системы, его легко модифицировать и помещать в конкретные условия эксплуатации. Например, вместо командного процессора Баурна (называемого так по имени его создателя, Стива Баурна), являющегося частью версии V стандартной системы, можно использовать процессор команд Си, обес- печивающий работу механизма ведения истории изменений и позволяющий збегать повторного ввода только что использованных команд. В некоторых случаях при желании можно воспользоваться командным процессором shell с ограниченными возможностями, являющимся предыдущей версией обычного shell'а. Система может работать с несколькими командными процессорами одновременно. Пользователи имеют возможность запускать одновременно множество процессов, процессы же в свою очередь могут динамически порождать новые процессы и синхронизировать их выполнение. Все эти возможности обеспечиваются благодаря наличию мощных программных и аппаратных средств, составляющих среду выполнения процессов. Хотя привлекательность shell'а в наибольшей степени определяется его возможнос- тями как языка программирования и его возможностями в обработке аргументов, в данном разделе основное внимание концентрируется на среде выполнения процес- сов, управление которой в системе возложено на командный процессор Shell. 3.3 Элементы конструкционных блоков Как уже говорилось ранее, концепция разработки системы UNIX заключалась в построении операционной системы из элементов, которые позволили бы пользо- вателю создавать небольшие программные модули, выступающие в качестве конст- рукционных блоков при создании более сложных программ. Одним из таких эле- ментов, с которым часто сталкиваются пользователи при работе с командным процессором shell, является возможность переназначения ввода-вывода. Говоря условно, процессы имеют доступ к трем файлам: они читают из файла стандарт- ного ввода, записывают в файл стандартного вывода и выводят сообщения об ошибках в стандартный файл ошибок. Процессы, запускаемые с терминала, обычно используют терминал вместо всех этих трех файлов, однако каждый файл незави- симо от других может быть "переназначен". Например, команда ls выводит список всех файлов текущего каталога на устройство (в файл) стандар- тного вывода, а команда ls > output переназначает выводной поток со стандартного вывода в файл "output" в теку- щем каталоге, используя вышеупомянутый системный вызов creat. Подобным же образом, команда mail mjb < letter открывает (с помощью системного вызова open) файл "letter" в качестве файла стандартного ввода и пересылает его содержимое пользователю с именем "mjb". Процессы могут переназначать одновременно и ввод, и вывод, как, например, в командной строке: nroff -mm < doc1 > doc1.out 2> errors где программа форматирования nroff читает вводной файл doc1, в качестве фай- ла стандартного вывода задает файл doc1.out и выводит сообщения об ошибках в файл errors ("2>" означает переназначение вывода, предназначавшегося для файла с дескриптором 2, который соответствует стандартному файлу ошибок).Програм- мы ls, mail и nroff не знают, какие файлы выбраны в качестве файлов стандартного ввода, стандартного вывода и записи сообщений об ошибках; командный процессор shell сам распознает символы "<", ">" и "2>" и назначает в соответствии с их указанием файлы для стандартного ввода, стандартного вывода и записи сообщений об ошибках непосредственно перед запуском процессов. Вторым конструкционным элементом является канал, механизм, обеспечиваю- щий информационный обмен между процессами, выполнение которых связано с операциями чтения и записи. Процессы могут переназначать выводной поток со стандартного вывода на канал для чтения с него другими процессами, переназ- начившими на канал свой стандартный ввод. Данные, посылаемые в канал первыми процессами, являются входными для вторых процессов. Вторые процессы так же могут переназначить свой выводной поток и так далее, в зависимости от пожеланий программиста. И снова, так же как и в вышеуказанном случае, процессам нет необходимости знать, какого типа файл используется в качестве файла стандартного вывода; их выполнение не зависит от того, будет ли файлом стан- дартного вывода обычный файл, канал или устройство. В процессе построения больших и сложных программ из конструкционных элементов меньшего размера программисты часто используют каналы и переназначение ввода-вывода при сборке и соединении отдельных частей. И действительно, такой стиль программирования находит поддержку в системе, благодаря чему новые программы могут работать вместе с существующими программами. Например, программа grep производит поиск контекста в наборе файлов (яв- ляющихся параметрами программы) по следующему образцу: grep main a.c b.c c.c где "main" - подстрока, поиск которой производится в файлах a.c, b.c и c.c с выдачей в файл стандартного вывода тех строк, в которых она содержится. Со- держимое выводного файла может быть следующим: a.c: main(argc,argv) c.c: /* here is the main loop in the program */ Некоторые машинные команды являются привилегированными и вызывают возникновение ошибок при попытке их использования в режиме задачи. Например, в машинном языке может быть команда, управляющая регистром состояния процессора; процессам, выполняющимся в режиме задачи, она недоступна. Процессы A B C D Режим ядра Я Я Режим задачи З З Рисунок 1.5. Процессы и режимы их выполнения Проще говоря, любое взаимодействие с аппаратурой описывается в терминах режима ядра и режима задачи и протекает одинаково для всех пользовательских программ, выполняющихся в этих режимах. Операционная система хранит внутренние записи о каждом процессе, выполняющемся в системе. На Рисунке 1.5 показано это разделение: ядро делит процессы A, B, C и D, расположенные вдоль горизонтальной оси, аппаратные средства вводят различия между режимами вы- полнения, расположенными по вертикали. Несмотря на то, что система функционирует в одном из двух режимов, ядро действует от имени пользовательского процесса. Ядро не является какой-то особой совокупностью процессов, выполняющихся параллельно с пользовательски- ми, оно само выступает составной частью любого пользовательского процесса. Сделанный вывод будет скорее относиться к "ядру", распределяющему ресурсы, или к "ядру", производящему различные операции, и это будет означать, что процесс, выполняемый в режиме ядра, распределяет ресурсы и производит соот- ветствующие операции. Например, командный процессор shell считывает вводной поток с терминала с помощью запроса к операционной системе. Ядро операцион- ной системы, выступая от имени процессора shell, управляет функционированием терминала и передает вводимые символы процессору shell. Shell переходит в режим задачи, анализирует поток символов, введенных пользователем и выполняет заданную последовательность действий, которые могут потребовать выполнения и других системных операций. 5.1 Прерывания и особые ситуации Система UNIX позволяет таким устройства, как внешние устройства ввода- вывода и системные часы, асинхронно прерывать работу центрального процес- сора. По получении сигнала прерывания ядро операционной системы сохраняет свой текущий контекст (застывший образ выполняемого процесса), устанавливает причину прерывания и обрабатывает прерывание. После того, как прерывание бу- дет обработано ядром, прерванный контекст восстановится и работа продолжится так, как будто ничего не случилось. Устройствам обычно приписываются приори- теты в соответствии с очередностью обработки прерываний. В процессе обработки прерываний ядро учитывает их приоритеты и блокирует обслуживание прерывания с низким приоритетом на время обработки прерывания с более высоким приорите- том. Особые ситуации связаны с возникновением незапланированных событий, выз- ванных процессом, таких как недопустимая адресация, задание привилегирован- ных команд, деление на ноль и т.д. Они отличаются от прерываний, которые вы- зываются событиями, внешними по отношению к процессу. Особые ситуации возникают прямо "посредине" выполнения команды, и система, обработав особую ситуацию, пытается перезапустить команду; считается, что прерывания возникают между выполнением двух команд, при этом система после обработки прерывания продолжает выполнение процесса уже начиная со следующей команды. Для обра- ботки прерываний и особых ситуаций в системе UNIX используется один и тот же механизм. 5.2 Уровни прерывания процессора Ядро иногда обязано предупреждать возникновение прерываний во время кри- тических действий, могущих в случае прерывания запортить информацию. Напри- мер, во время обработки списка с указателями возникновение прерывания от диска для ядра нежелательно, т.к. при обработке прерывания можно запортить указатели, что можно увидеть на примере в следующей главе. Обычно имеется ряд привилегированных команд, устанавливающих уровень прерывания процессора в слове состояния процессора. Установка уровня прерывания на определенное значение отсекает прерывания этого и более низких уровней, разрешая обработку только прерываний с более высоким приоритетом. На Рисунке 1.6 показана последовательность уровней прерывания. Если ядро игнорирует прерывания от диска, в этом случае игнорируются и все остальные прерывания, кроме прерываний от часов и машинных сбоев. Рисунок 1.6. Стандартные уровни прерываний 5.3 Распределение памяти Ядро постоянно располагается в оперативной памяти, наряду с выполняющимся в данный момент процессом (или частью его, по меньшей мере). В процессе компиляции программа-компилятор генерирует последовательность адресов, явля- ющихся адресами переменных и информационных структур, а также адресами инст- рукций и функций. Компилятор генерирует адреса для виртуальной машины так, словно на физической машине не будет выполняться параллельно с транслируемой ни одна другая программа. Когда программа запускается на выполнение, ядро выделяет для нее место в оперативной памяти, при этом совпадение виртуальных адресов, сгенерированных компилятором, с физическими адресами совсем необязательно. Ядро, взаимодейс- твуя с аппаратными средствами, транслирует виртуальные адреса в физические, т.е. отображает адреса, сгенерированные компилятором, в физические, машинные адреса. Такое отображение опирается на возможности аппаратных средств, поэтому компоненты системы UNIX, занимающиеся им, являются машинно-зависимыми. Например, отдельные вычислительные машины имеют специальное оборудование для подкачки выгруженных страниц памяти. 6. ВЫВОДЫ В работе были описаны полная структура системы UNIX, взаимоотношения между процессами, выполняющимися в режиме задачи и в режиме ядра, а также аппаратная среда функционирования ядра операционной системы. Процессы