SOII_Materia_Parte01

Prévia do material em texto

SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 1 
 
Email Professor: galucio@ime.uerj.br 
 
 Gerência de Memória 
 Entrada/Saída 
 Disco Magnético 
 Gerência de Arquivos 
 Conceitos 
 Chamadas ao SO 
 Organização interna 
 Desempenho do uso de arquivos 
 
1) FAMÍLIAS DE SO 
 
WINDONS UNIX 
MS-DOS -AT&T (Fabricante original) 
3.0 NT - SCO (fornecedor atual) 
3.1 3.0 - BSD – universidade de Berkley (capacidade de Ter um protocolo de rede TCP/IP 
95 3.5 - Linux gratuito 
98 4.0 - Free BSD gratuito 
ME 2000 - SOLARIS (SUN) 
 XP - AIX (IBM) 
 - HP/UX (HP) 
 
MS DOS (Windows Antigo) 
Disk Operating System / SO Textual, IBM PC (8086 - 16 bits), Hardware não proprietário, Processador 
Intel Versionado de 1.0 a 6.0 (década de 80). Um processo por vez inicialmente. 
 
SO simples feito em linguagem de programação de máquina da Intel. Hoje em dia isto não é mais assim, 
pois é feito em C e é portátil para outras máquinas. 
 
A IBM pediu para MS criar o SO para sua máquina. Elas fizeram uma parceria. 
 
OS/2 
Desenvolvido por Microsoft+IBM. Não obteve sucesso porque a maioria das máquinas não suportava. 
Existia interface gráfica. A IBM continuou sozinha o desenvolvimento desse SO após a quebra da parceria 
com a MS. 
 
WINDOWS 3.0 
Movimento das pessoas comuns usando PC. Era vendido separado do PC (+ caro) 
Lançado programas que funcionassem nele, como editores de texto, planilhas,... (Switch Desktop) 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 2 
 
 
WINDOWS 95 
Interface mais nova. Permitia executar processos múltiplos. 
 
WINDOWS 98 
Windows ME. Toda essa família era executada em CPU Intel, feita em linguagem de máquina. 
 
WINDOWS NT (NEW TECHNOLOGY – SO de Servidor) 
Linguagem de Alto nível. API (Application Program Interface – Conjunto de métodos que posso chamar) 
- Usar para mudar o componente de software sem mudar quem o usa. Exemplo: Word = API = SO. Ou 
seja, é o conjunto de chamadas ao SO que um programa pode fazer (criar um processo novo, abrir um 
arquivo, fecha-lo, etc.). 
 
A Microsoft conseguiu fazer a transição das famílias e garantir que os programas continuariam sendo 
executados devido a API. 
 
WINDOWS NT 
3, 4, 2000 (Mudança de nomenclatura de SO Desktop e Servidor), XP, Vista, 7 (Modo XP para funcionar 
os programas que não funcionam no 7), 8 (Retirada do Modo XP). Família após o NT, feita em linguagem 
C. 
 
LINUX (Baseado no Minix) 
POSIX – Padrão Unix 
AT ET  Linguagem de Programação criada em C para fazer o UNIX. Não podia vender o SO então deu. 
Depois passou a cobrar o uso quando pode vender o SO. 
Código fonte aberto em C, sucesso em máquina servidor (grátis). 
Padrão OSI  Não é implementado, mas é importante na teoria. 
BSD (Berkeley) Unix – Paga pelo governo, versão do Unix. Forma de comunicação entre as máquinas 
com o SO Linux a linguagem C e o TCP/IP sugiram por causa do Linux. 
Camadas OSI, padrão que não foi seguido para comunicação entre BSD’s Unix. OSI – 7 camadas; TCP/IP 
– 4 camadas. BSD programaram TCP/IP. Microsoft passou a usar a partir do Windows 95. 
 
MVS (Z/OS - Mainframe IBM) 
Softwares de mainframe importantes para processamento massivo de dados (Banco, serviços públicos). 
“Aluguel” de mainframe. Algumas empresas ainda usam por segurança e risco. Por um tempo, 
mainframes processavam mais rápido e faziam E/S mais rápido. CPU específica E/S. Hoje em dia existe 
multi-core. Primeiro a trazer benefícios para informática. Linguagem de máquina e não em C. Não é 
melhor do que os Pcs atuais e por comodidade as empresas mantem hoje em dia. Devido o insucesso do 
MVS sugiram as boas praticas e o padrão MPS.BR, CMI, CMMI. 
 
Líder de projeto da IBM criou o CMM CMMI: Boas práticas para entrega de produtos. Testes, 
versionamento, requisitos, controle de alteração de requisitos. Na UFRJ surgiu o similar MPS.BR Criado 
devido ao insucesso no projeto do MVS. 
 
 
 
 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 3 
 
 
2) PROGRAMA  PROCESSO 
 
Programa  Arquivo executável. 
Processo  Programa carregado na memória p/ execução. 
 
Dentro de um processo existe: Código e Dados (variáveis etc.). Há 3 tipos de variáveis: Globais: variáveis 
que podem ser usadas por qualquer rotina. Locais: variáveis que só podem ser usadas por rotinas que a 
criaram. Dinâmicas: variáveis criadas pelo programador. Dá para calcular o espaço a ser usado pelas 
variáveis globais antes do processo começar a executar. 
FUNCTION FAT (N: INTEGER): INTEGER 
 BEGIN 
 IF N = 1 THEN 
 FAT:= 1; 
 ELSE 
 FAT:= N * FAT (N-1); 
 END; 
END. 
Quando há recursão, os vários valores da variável N utilizada no exemplo da função FAT acima devem 
ser guardados na memória, pois eles são necessários no cálculo do fatorial. Uma parte da área de dados é 
utilizada pelas variáveis locais (pilha). Um exemplo de uso da pilha é dado para mostrar a solução da 
função recursiva anterior. 
4 4 4 24 
3 3 6 
2 2 
1 
No exemplo acima, o valor da FAT é colocado num registrador com o valor 1 e é retirado da pilha. Depois 
multiplica - se o seu valor com o valor da próxima posição da pilha e assim sucessivamente, até esvaziar a 
pilha. 
 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 4 
 
3) GERÊNCIA DE MEMÓRIA 
O problema da amarração de endereço está em como será feita a localização de um endereço dentro da 
memória, pois um processo nem sempre é carregado na posição zero da memória. 
As soluções para este problema são: Amarração em tempo de carga, Endereços Relativos à Base, 
Endereços Relativos à Instrução corrente, Segmentação e Paginação. 
 
3.1) SOLUÇÕES PARA O PROBLEMA DE CARREGAMENTO DE PROGRAMAS EM 
QUALQUER ENDEREÇO DE MEMÓRIA 
3.1.1) AMARRAÇÃO DE ENDEREÇOS (ADRESS BINDING) 
 
Um Sistema Operacional pouco sofisticado executa um programa por vez e assim teremos um único 
programa na memória conforme Figura 1.1. Na Figura 1.2 temos uma amostra de um Sistema operacional 
um pouco mais sofisticado. Ele controla a execução de mais de um programa por vez. Assim, estão na 
memória dois ou mais processos sendo executado segundo controle do Sistema Operacional. 
 
Ainda na Figura 1.2 podemos observar dois processos ocupando áreas diferentes na memória: o processo 
1 começa no endereço 0 até o endereço 9999, ocupando um tamanho de 10000; o processo 2 começa no 
endereço 10000, ocupando um tamanho de 10000 também. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
O problema é que não é tão simples para o Sistema Operacional controlar um programa na memória, veja 
o exemplo abaixo: 
 
Exemplo em Assembly: 
ADD AX, BX => Adicionar um registrador com outro (de BX para AX) 
MOV AX, CX => Mover o conteúdo de um registrador para outro (de CX para AX) 
MOV AX, [1000] => Mover o conteúdo do endereço 1000 para o registrador AX. 
JNZ 2000 => Desvia a execução para o endereço 2000 
CALL 3000 => Chamada de Sub-rotina. 
Memória 
 
SO 
 
Proc1 
 
Memória 
 
SO 
 
Proc2 
Proc1 
 Fig. 1.2 
 
 
 
 
 
 
 
10000 
9999 
0 
Fig. 1.1 
 
(1.1) 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 5 
 
A partir do exemplo acima verificamos que o programa acima só vai servir para o processo 1, para o 
processo 2 não servirá, pois este último começa na posição 10000, e o endereço 1000 não faz parte do 
processo 2. Porém, o arquivo executável não sabe onde será armazenado na memória depende da ordem 
em que os processos foram chamados pelo usuário. Então o código acima não serviria para o processo 2. 
 
Este problema faz parte de um problema chamado de amarração de endereços (adressbinding), é a 
amarração entre um nome e um endereço. Geralmente, o programa tem nomes, veja exemplo abaixo: 
 
 SubRot: . 
 . 
 . 
 Ret 
 CALL SubRot 
 
A CPU não entende esta instrução “CALL SubRot”. Ela só entende endereços de memória, um array de 
byte. O montador de Assembly transforma o label “SubRot” em endereço, em um valor da posição de 
memória. 
 
Porém, isto não é tudo existe um problema anterior que é o carregamento do programa na memória. O 
programa pode ser carregado na posição 0 ou 10000. Se o programa (1.1) for carregado na posição 10000 
ele não vai funcionar. Isto pode ser resolvido no seu carregamento na memória. 
 
 memória memória 
 
 } 
 
1003 
Variável "j" 
 
1002 
 19.999 
 } 
Processo 2 
1001 19.900 
1000 
 
 10.000 
 9.999 
 
 } 
 
 } 
 
 
Código de rotina 
verificar consistência 
 
 
 
500 
Processo 1 
 
 
 
4 
3 
2 
1 0 
0 
 
(1.2) 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 6 
 
3.1.2) CORREÇÃO DE ENDEREÇOS EM TEMPO DE CARGA 
 
À medida que o programa é carregado na memória, o SO corrige as posições de memória indicadas nas 
instruções que fazem referência a endereços da memória, somando o valor do endereço-base antes de 
executar o processo. Com isso, o processo fica com dados consistentes. 
O processo começa no endereço de memória 10000. 
Antes da carga Depois da carga 
MOV AX, [1000] 
JNZ 2000 
MOV AX, [11000] 
JNZ 12000 
 
Como saber quais instruções serão alteradas? Os arquivos “.EXE” têm dados de controle (que estão no 
PCB) que dizem quais instruções e rotinas deverão ser alteradas. Programas “.EXE” no MS-DOS utilizam 
essa técnica. 
 Tabela adicional gerada pelo compilador, que diz qual (is) endereço (s) sofreu (RAM) correção. 
 Altera o valor na instrução. Soma a cada instrução, vezes únicas, feita pelo SO. 
 Ex.: Arquivos executáveis (Programa .exe) do MS-DOS. 
 
 memória 
 
 
. SO coloca o valor no reg. De base. 
HW faz o resto (somas) 
MOV EAX 
[1000] 
 
 
ADD EAX, 
10 19.900 
 } 
Processo 2 
 . Soma feita pelo HW (mais rápido) 
MOV [1000], 
EAX 
 
 .Perde desempenho 
(imperceptivelmente) 10.000 
Reg. de base 9.999 
[1000] 
} 
Processo 1 
Ex. MSDOS, programas .com (por 
limitações de HW) 
 
 
 0 
 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 7 
 
O montador ou compilador gera código imaginando que o programa vai ser colocado em certo lugar na 
memória, supondo no endereço 0, por exemplo. Com isso, é simplificado o trabalho do montador ou 
compilador. 
 
O sistema operacional antes de colocar o arquivo na memória corrige o endereço. O sistema operacional 
sabe onde será carregado o arquivo que sai do disco e será colocado na memória para execução. Ele vai a 
todos os endereços do programa e soma o endereço inicial daquele programa, segundo exemplo abaixo: 
 
Endereço Inicial do programa = 10000 
. 
. 
. 
MOV AX, [11000] => 10000 + 1000 = 11000 
JNZ 12000 => 10000 + 2000 = 12000 
CALL 3000 => 10000 + 3000 = 13000 
 
Agora o programa (1.1) pode ser carregado na posição 10000 que irá funcionar. 
 
O programa executável é formado por código mais informações de controle que o sistema operacional usa 
para a correção de endereço. Pois, o sistema operacional precisa de uma referência de quais instruções ele 
precisa alterar, essas informações de controle dizem quais são as rotinas que precisam ser alteradas. Um 
exemplo de sistema operacional que usa este tipo de solução é o MS-DOS e Windows 16 bits para 
arquivos executáveis (.exe). As versões do Windows 32 bits e superiores não são mais assim. 
 
Digamos que o programa esteja dividido na memória, como mostra a figura abaixo, em três pedaços. 
Podemos observar que na memória temos o pedaço 1 começando na posição 0, o pedaço 2 na posição 
20000 e o pedaço 3 na posição 30000: 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 8 
 
 Memória 
 
 
 
 
 
 
 
O sistema operacional ao carregar o programa na memória irá somar a cada pedaço o valor do endereço 
inicial do pedaço com o endereço da instrução. 
 
Implementada pelo DOS para arquivos .com. Este mecanismo consiste em fazer o acerto de todos os 
endereços do processo somando cada um deles com o endereço inicial de onde está sendo carregado o 
processo na memória. Suporte apenas do sistema operacional. 
 
3.1.3) USO DE ENDEREÇOS RELATIVOS 
 
Ao invés do programa usar endereços absolutos, por exemplo, endereço 0. Ele usa endereços relativos a 
alguma coisa. O que acontece é que a CPU durante a execução ela soma o que a instrução tem mais certo 
valor, este valor é o endereço relativo. Então esta correção não é feita mais na carga. A correção é feita 
pelo hardware, pela CPU. Tem dois casos, veja abaixo: 
 
3.1.3.1) ENDEREÇOS RELATIVOS A UMA BASE FIXA 
 
Nesta solução é utilizado um registrador de base fixa, localizado na CPU. Quando o registrador de base 
fixa tiver como conteúdo o valor 0 então será usado o valor absoluto. 
 
No caso, se o sistema operacional carregar o programa (1.1) na posição 10000 este registrador conterá o 
valor 10000, por exemplo, será somado a cada instrução que contenha valor de endereço absoluto o valor 
relativo à base (10000). 
 
Exemplo: Registrador de Base: 
 
 
 
 
 
 
 
0 Proc 1 
10000 Proc 2 
SO 
 
PEDAÇO 3 
 
PEDAÇO 2 
 
PEDAÇO 1 
 
PEDAÇO 3 
PEDAÇO 2 
PEDAÇO 1 
 
 
30000 
 
20000 
Programa 
SO soma 30000 
SO soma 20000 
SO soma 0 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 9 
 
 Proc 1: 
 . 
 . 
 . 
 MOV AX, [1000] 
 JNZ 2000 
 CALL 3000 
 
O sistema operacional não faz nada com relação à correção de endereço, mas a cada instrução executada a 
CPU soma o valor do endereço absoluto da instrução mais o endereço contido no registrador de base. Por 
exemplo, se o processo 2 foi bloqueado e o escalonador elege o processo 1 para execução, o valor do 
registrador de base passará de 10000 para 0. O responsável pela alteração do endereço do registrador de 
base é o sistema operacional. 
 
A vantagem desta solução para a solução anterior é que o executável não precisa ter nenhuma informação 
de controle de endereço, simplificando a carga. 
 
Quanto ao tempo de execução em teoria seria mais lento devido a cada instrução que faça referência a 
endereços absolutos ter uma soma, porém esta soma é feita pelo hardware, um hardware dedicado a fazer 
isto. Com isso o tempo que leva esta soma é irrelevante, não contribuí para que a CPU que use registrador 
de base seja mais lenta que a CPU que não use registrador de base. Se fosse uma operação feita por 
software poderia ficar mais lento, mas não é o caso. 
 
Exemplos de sistemas operacionais que usam esta solução: MS-DOS para programas (.COM. e .EXE). O 
programa “.EXE” do MS-DOS é uma mistura da solução 1 e 2.1, ou seja, têm endereços que são 
resolvidos em tempo de carga e têm endereços relativos à base. 
 
A CPU Intel tinha um problema que a distância em relação à base não podia ser muito grande, a limitação 
era 64kbytes, à distância do endereço da base. Se o programa “.EXE” tivesse menos que 64kbytes então 
podia usar apenas a solução 2.1. Caso o programa tivesse mais que 64kbytes então tinha que usar uma 
solução mista. 
 
A CPU Intel (até 80186) tem quatro registradores de base que para cada tipo de instrução é reservado um 
registrador de base diferente, veja abaixo, os registradores existentes: 
 cs – code (instruçõescom endereços relativos a código) 
 ds – data (instruções com endereços relativos à memória, variável global) 
 ss – stack (instruções com endereços relativos a variáveis locais, pilha) 
 es – extra 
 
Observação: 
 A Intel chamou estes registradores de base de segmento que não tem haver com a terceira solução 
que é a segmentação. 
 Depois da CPU Intel 80186 que passou para a segmentação também. 
 Esta solução precisa de um suporte por hardware. 
 
Proc 2: 
. 
. 
. 
MOV AX, [11000] 
JNZ 12000 
CALL 13000 
SISTEMA OPERACIONAL II – PARTE 1 
 
Elaborado por Luciana Amancio merge com material da Soraia – 2013/01 Página 10 
 
A CPU calcula a nova posição utilizada na instrução antes da execução da instrução, somando o endereço-
base contido no registrador-base com o endereço contido na instrução. Registrador-base: registrador da 
CPU que guarda o endereço da 1ª instrução do processo a ser executado. 
 
Teoricamente, essa técnica aumentaria o tempo de execução do processo, uma vez que, a CPU tem que 
fazer uma nova soma para cada instrução que tenha referência a um endereço de memória, mas como há 
um hardware dedicado a esse tipo de operação, o tempo extra gasto é irrelevante. Essa técnica simplifica a 
carga do processo na memória. Programas “.COM” e “.EXE” no MS-DOS utilizam essa técnica. 
O SO muda o valor do registrador-base quando o SO muda o processo a ser executado pela CPU. 
Neste mecanismo tem-se um registrador base no chip da CPU que contém o endereço inicial do processo. 
E esta informação do endereço inicial é adicionada a cada endereço referenciado no processo. Possui 
suporte de hardware e software (sistema operacional). Utilizado para arquivos.exe e .com. 
3.1.3.2) ENDEREÇOS RELATIVOS À INSTRUÇÃO CORRENTE 
 
A CPU tem que ter instruções cujo endereço não é endereço que conta a partir do 0, a partir da base. São 
endereços que contam a partir da própria instrução. Por exemplo, se quiser fazer um loop o que conterá na 
instrução é a distância entre a instrução de loop e o endereço para onde se quer desviar, como é mostrado 
abaixo: 
 ADD AX, BX 
 MOV AX, CX 
 MOV AX, [1000] 
 JNZ -20 
CALL 3000 
 
Isto é um endereçamento relativo à instrução corrente. Nesta solução não importa onde o programa foi 
carregado na memória, pois a distância de uma instrução desvia para o seu destino, como mostra o 
exemplo acima, não se altera. 
 
O código que só usa este tipo de endereço é chamado código realocável porque ele pode ser mudado de 
posição na memória e continuar executando sem precisar fazer mais nada. A Intel tem tipo de instruções 
que fazem isto, por exemplo, JNZ relativo e o absoluto, o compilador escolhe um ou outro. 
 
Os endereços contidos nas instruções são gerados em tempo de carga. Essa técnica não pode ser utilizada 
em processos que estejam fragmentados na memória. O código é realocável. 
 
Antes da carga Depois da carga 
Endereço de memória Endereço de memória 
64 ADD AX, BX 64 ADD AX, BX 
80 JNZ 1000 80 JNZ -16 
 
Neste mecanismo o montador da linguagem de programação substitui o endereço pela distância da 
instrução corrente para o endereço que se deseja desviar. 
 
20 bytes