sistemas operativos mod3

El sistemaoperativo: una mquina virtualJosep Llus Marzo i Lzaro

P05/75097/00805Mdulo 2

FUOC P05/75097/00805 Mdulo 2 El sistema operativo: una mquina virtual

ndice

Introduccin............................................................................................. 5

Objetivos .................................................................................................... 6

1. Una introduccin a la mquina virtual....................................... 7

1.1. El concepto de mquina virtual ...................................................... 7

1.2. El concepto de sesin de trabajo ..................................................... 9

1.3. El intrprete de rdenes................................................................... 11

1.4. El sistema operativo desde el punto de vista del programador....... 14

2. Las fases de ejecucin de un programa ........................................ 15

2.1. El concepto de proceso.................................................................... 15

2.2. El lenguaje informtico ................................................................... 16

2.3. Las herramientas para la creacin de una aplicacin informtica ...... 18

2.4. El proceso de creacin de un programa ejecutable ......................... 20

2.4.1. La edicin ............................................................................. 20

2.4.2. La compilacin (ensamblaje) ............................................... 20

2.4.3. El montaje (enlazado) .......................................................... 23

2.4.4. La carga................................................................................. 26

2.4.5. La ejecucin (depuracin).................................................... 27

2.5. Las libreras de sistema .................................................................... 29

3. Los espacios de direcciones de un proceso ................................... 32

3.1. El espacio lgico y el espacio fsico ................................................. 32

3.2. La carga en la memoria: reubicacin............................................... 32

4. Los mecanismos de entrada al sistema operativo:

traps, excepciones e interrupciones .............................................. 34

4.1. Las rutinas de servicio del sistema operativo .................................. 34

4.2. Los mecanismos de acceso a los servicios ....................................... 36

4.3. Los mecanismos bsicos de transferencia ....................................... 38

4.4. El ncleo del sistema operativo....................................................... 39

Resumen..................................................................................................... 42

Actividades................................................................................................ 43

Ejercicios de autoevaluacin ................................................................ 43

Solucionario.............................................................................................. 44

Glosario ...................................................................................................... 45

Bibliografa............................................................................................... 46

FUOC P05/75097/00805 Mdulo 2 5 El sistema operativo: una mquina virtual

Introduccin

En este mdulo didctico aparecen descritos los servicios que ofrece el siste-

ma operativo (SO) a los usuarios. Asimismo, se ampla el concepto de usuario

de un sistema operativo a los procesos que estn en ejecucin y que tambin

utilizan estos servicios.

Encontraremos expuestas las utilidades que ofrece el sistema operativo para

construir aplicaciones informticas y las fases por las cuales tiene que pasar

una aplicacin desde su concepcin hasta que se pueda ejecutar.

Y, para finalizar, definimos el concepto de proceso en ejecucin a partir de

un programa, su desarrollo y, fundamentalmente, su interaccin con el siste-

ma operativo.

Tambin trataremos conceptos como la interrupcin y la rutina de servicio,

los mecanismos de acceso en el rea propia del sistema y las familias de ser-

vicios de mayor uso.


Objetivos

Los materiales didcticos de este mdulo contienen las herramientas para al-

canzar los siguientes objetivos:

1. Adquirir el concepto de proceso informtico en tanto que programa en eje-

cucin y conocer sus caractersticas fundamentales. Tambin es necesario

saber diferenciar con claridad este concepto de otros conceptos que se en-

cuentran relacionados con el mismo, tales como los de programa, lenguaje

informtico, etc.

2. Comprender el mecanismo de transformacin de un programa escrito en un

lenguaje de programacin para poder ejecutarlo en un sistema informtico.

3. Conocer las herramientas de un sistema operativo en relacin con el entor-

no de programacin de aplicaciones.

4. Comprender el entorno necesario que proporciona el sistema operativo

para la ejecucin de una aplicacin informtica.

5. Entender el mecanismo de carga de un programa en la memoria y ver cmo

se diferencia esta memoria de la que se le asigna a otros procesos o de la que

se le asigna al mismo sistema operativo.


1. Una introduccin a la mquina virtual

El sistema operativo define una mquina virtual sobre la cual los usuarios

pueden trabajar con una mayor comodidad de la que lo haran si trabajasen

directamente sobre los elementos que componen el sistema.

Las sesiones de trabajo sobre esta mquina virtual siguen unas pautas y unas

reglas predeterminadas, con un proceso de inicio, una fase de trabajo y un l-

timo proceso de finalizacin de la sesin. Esta sesin de trabajo tambin hace

que el sistema operativo pueda identificar a los diferentes tipos de usuarios y

proporcionarles, de esta manera, un entorno con las herramientas ms apro-

piadas para la tarea que tienen que llevar a cabo. Un administrador, por ejem-

plo, no tiene las mismas necesidades que un programador y, por tanto, no

necesitan el mismo entorno.

El intrprete de rdenes es el programa ms habitual que configura la interfaz

con que dialoga el usuario. Para simplificar, podemos decir que el intrprete de

rdenes es el interlocutor entre los usuarios y el sistema operativo. En funcin

del tipo de usuario, este intrprete puede estar ms o menos especializado, o

puede ser ms o menos restrictivo. As, por ejemplo, un programador que debe

realizar tareas de desarrollo o de gestin del sistema contar con un intrprete

de rdenes genrico que le va a permitir realizar muchas acciones diferentes, sin

embargo, un administrativo puede tener un intrprete de rdenes muy restric-

tivo que slo le permita ejecutar las aplicaciones propias de su tarea.

Para acabar, consideraremos la visin que tienen las aplicaciones del siste-

ma operativo, visin que deben conocer los programadores que tendrn que

llevar a cabo su creacin. En tal caso, la interfaz con que dialoga el programa

tiene que encontrarse al mismo nivel que el de las libreras de programas.

A lo largo de este apartado trataremos de todos estos aspectos, empezando por

el de mquina virtual, pasando por los de sesin de trabajo e intrprete de rde-

nes, y finalizando con la visin que el programador tiene del sistema operativo.

1.1. El concepto de mquina virtual

La finalidad bsica del sistema operativo es esconder el hardware mediante

una capa de software por medio de la cual accedemos para trabajar. Hay muchas

formas de esconder este hardware, as como de agrupar y organizar las funciones

que tendr la nueva mquina, y cada una de estas combinaciones supone un

tipo diferente de sistema operativo. Desde el punto de vista del usuario que ac-


cede a los recursos que ofrece

la mquina, el entorno de

acceso es el ms caracters-

tico y est determinado por

el sistema operativo, no por

el hardware.

El hecho de ocultar el hard-

ware a los usuarios y a los pro-

gramadores tiene, entre otros,

dos objetivos principales, que

son:

1) La abstraccin del sistema

como un hardware determi-

nado para tener una visin global y sencilla de la mquina.

2) Proporcionar un tipo de funcionamiento nuevo y ms seguro cuando se

ejecuta el cdigo que pertenece al sistema operativo. Este aspecto es muy im-

portante para evitar que los usuarios tengan acceso a ciertos elementos del sis-

tema que podran afectar al funcionamiento normal y que, de alguna manera,

tienen que ser supervisados.

En la siguiente figura podemos observar las capas del sistema con ms de-

talle. Distinguimos tres niveles dentro del sistema operativo: el ncleo, las

herramientas del sistema y el intrprete de rdenes. Los tres contienen cdi-

go til y accesible para los usuarios, a pesar de que el acceso es diferente en

cada nivel.

Figura 2

Figura 1


La forma que tiene el sistema operativo de acceder a estos niveles es la

siguiente:

1) Se accede al intrprete de rdenes mediante el interfaz de usuario. En este

nivel, el sistema espera que usuarios reales o programas de grupos de rdenes*

introduzcan rdenes de manera interactiva, las cuales son interpretadas por el

sistema de manera inmediata.

2) En un nivel inferior, ms cerca del hardware, encontraremos las herramien-

tas del sistema operativo y las libreras. Estas herramientas son accesibles para

el usuario directamente mediante el intrprete de rdenes, y tambin para el

programador, que utiliza su interfaz cuando pone en funcionamiento las herra-

mientas de apoyo a la programacin.

3) Para finalizar, el ncleo del sistema operativo es la capa que se encuentra

ms cerca del hardware y contiene las rutinas de gestin del sistema ms rela-

cionadas con sus recursos fsicos. Estas rutinas se pueden utilizar por medio de

las llamadas al sistema. El ncleo tambin tiene la importante tarea de trans-

formar las referencias lgicas (abstractas) en referencias fsicas (concretas). El

cdigo que pertenece al ncleo siempre se ejecuta con privilegios de sistema

(modo supervisor).

Prestad atencin al hecho de que tanto la capa del intrprete de rdenes como

la de las herramientas del sistema trabajan en modo usuario desde el punto de

vista del sistema operativo.

1.2. El concepto de sesin de trabajo

En los sistemas multiusuario, para poder utilizar el sistema se tiene que iniciar

una sesin de trabajo; pues bien, para crear esta sesin de trabajo el sistema

debe identificar al usuario para asignarle su entorno personalizado, es decir,

los recursos para los que est autorizado.

Este proceso de identificacin tambin sirve para evitar que accedan al sistema

usuarios no autorizados para llevarlo a cabo. El acceso al sistema se realiza por

medio de un terminal, ms o menos sofisticado (alfanumrico, de ventanas,

etc.) y, por lo tanto, la primera tarea que se efecta en una sesin de trabajo es

asignarle un terminal a un usuario.

La mquina virtual es la visin que tiene el usuario del sistema opera-

tivo durante una sesin de trabajo desde un terminal.

* Los programas de gruposde rdenes son los ficheros batch

o scripts.

Por ejemplo,...

... mediante las herramientas del sistema se puede crear una aplicacin llamando al compi-lador. Las aplicaciones tambin se suelen crear aadiendo las rutinas de las libreras del siste-ma que sean necesarias.

Daremos ms detalles del ncleo del sistema operativo en el subapartado 4.4. de este mdulo didctico.

Podemos establecer un paralelismo...

... entre el nombre de usuario y la contrasea para acceder a un sistema informtico multiu-suario y una tarjeta de crdito para acceder a una cuenta bancaria. En primer lugar, de-bemos tener una identificacin previa asignada por el sistema, pero adems, necesitamos una segunda autentificacin rela-cionada con la primera, que es la contrasea o el nmero se-creto, en el caso de la tarjeta de crdito. En ambos casos el usuario puede modificar la segunda.


Pero qu es una sesin de trabajo?

En una sesin de trabajo podemos distinguir las tres fases que presentamos a con-

tinuacin:

1) Entrada en el sistema (fase de login): en este punto se pide el nombre del

usuario (username) y la contrasea correspondiente (password).

Tras haber introducido estos datos en el sistema operativo, ste da los siguien-

tes pasos:

a) Para empezar, el sistema operativo tiene que encontrar el nombre en la lista

de usuarios autorizados. De hecho, este paso es un primer grado de seguridad.

b) Si el nombre es correcto y la contrasea se corresponde con la que el orde-

nador tiene registrada, se ha superado el segundo nivel de seguridad.

c) En ltimo lugar, se asigna el entorno propio de este usuario y se inicia la

sesin de trabajo.

Un ejemplo de la utilidad que presenta el hecho de establecer una identificacin de

usuario es la figura del propietario de un fichero y de los permisos asociados para

realizar las operaciones que desee. Si el usuario no estuviese perfectamente identifi-

cado, no sera posible este control del sistema de ficheros.

2) Uso del sistema: en esta fase el usuario interacciona con el intrprete de

rdenes. Es la fase que se corresponde con el uso normal del sistema y, bsica-

mente, es un dilogo interactivo desde un terminal.

3) Salida del sistema, acabar* (fase de logout): en esta fase el usuario tiene

que declarar de manera explcita que ya ha acabado el trabajo y que desea

abandonar la sesin de trabajo. Este paso posee un doble objetivo:

Por una parte, es una cuestin de eficiencia: hay que liberar los recursos que se

tienen asignados.

Por otra parte, es una cuestin de seguridad: hay que cerrar la sesin abierta

para que as ningn otro usuario pueda utilizar la cuenta abierta.

Explicaremos con ms detalle la relacin propietario-fichero en el apartado 4 del mdulo didctico El sistema de ficheros.

* La manera de salir del sistema es diferente en cada SO; en UNIX

se utiliza la orden exit y en VMS, la orden 1o.

Si no cerramos...

... la sesin de trabajo al acabar, es como si cuando finalizamos una operacin bancaria nos dejsemos la tarjeta dentro del cajero automtico.


Cuenta abierta

Para que un usuario pueda trabajar con el sistema operativo, es necesario crearle un entornode trabajo, formado por un directorio de trabajo, y se le tienen que dar unos privilegios, unnombre, etc., para que el sistema operativo lo reconozca.

Este entorno se denomina cuenta de usuario. Un usuario abrir esta cuenta cuando inicie unasesin de trabajo con el sistema operativo.

1.3. El intrprete de rdenes

El intrprete de rdenes es un programa que se encarga de interpretar y comu-

nicar al sistema lo que el usuario desea hacer. Por lo tanto, cuando empezamos

una sesin de trabajo, se carga en la memoria y no se descarga hasta que no se

acaba la sesin, y durante este tiempo se ejecuta continuamente.

El intrprete de rdenes sigue el esquema de funcionamiento que tenemos a

continuacin:

Como se puede observar, el intrprete de rdenes es fundamentalmente un pro-

ceso que solicita de manera cclica, mediante un bucle, una orden para ejecutar

hasta que tenga lugar la de salir. La manera que tiene de decir que est preparado

para aceptar nuevas rdenes es escribir una combinacin de caracteres en la pan-

talla del terminal; se trata del prompt, que significa ahora me encuentro en dispo-

sicin de leer nuevas rdenes.

El intrprete de rdenes rene un nmero limitado de rdenes, mediante las

cuales el usuario puede interaccionar con el sistema.

a) Existe una serie de rdenes que el propio intrprete de rdenes reconoce y

ejecuta; son las rdenes internas, aquellas que forman parte del ncleo del

sistema operativo.

b) Existen rdenes que el intrprete no es capaz de ejecutar de manera direc-

ta. En tal caso, tiene que buscarlas en el sistema de ficheros y cargarlas en la

memoria para que se ejecuten. Son las rdenes externas, que por lo general

sacar_prompt

leer_orden

mientras la orden_no_seasalir hacer

ejecutar_la_ordensacar_prompt

leer_nueva_orden

fin_mientras

El ncleo del sistema operativo se explica con ms detalle en el subapartado 4.4. de este mdulo didctico.


se encuentran en un directorio concreto del sistema de ficheros. Cuando el in-

trprete de rdenes tiene que cargar una orden externa, la bsqueda de la or-

den en el disco sigue una ruta concreta*. Esto significa que en primer lugar

busca en un directorio, despus en otro, y as segn lo especifique el usuario.

El intrprete de rdenes se basa en el siguiente esquema para ejecutar las rdenes:

El intrprete de rdenes en la actualidad

Actualmente, la nocin de intrprete de rdenes ha quedado un poco disimulada por eluso de los entornos grficos basados en ventanas, y tambin porque estos entornos sonmultitarea. En dichos entornos, las rdenes se dan mediante iconos, mens, etc., y lasrespuestas, con las ventanas que se abren y se cierran de manera dinmica. Los sistemasde ventanas Windows de Microsoft, MACOS o Xwindows del entorno UNIX, entreotros, constituyen ejemplos de interfaz de interactuacin grfica con el sistema. La ideade fondo en que se basa su funcionamiento es similar a la de un intrprete de rdenes detexto.

leer_orden

es interna?si hacer ejecutarlano hacer

est en el directorio actual?si hacer ejecutarlano hacer

est en el directorio path? si hacer ejecutarla no mensaje de error: no se puede ejecutarla orden

* La ruta que sigue el intrprete de rdenes para buscar una orden

externo se denomina camino predefinido o path.


Las modalidades de ejecucin del intrprete de rdenes son las siguientes:

1) De primer plano (foreground): el intrprete de rdenes pasa el control al

programa que corresponde a la orden que hay que ejecutar, y no lo recupera

hasta que finaliza por completo la ejecucin.

2) De fondo (background): se inicia la ejecucin de la orden solicitada y el con-

trol vuelve de inmediato al intrprete de rdenes. En este caso, se produce una

ejecucin concurrente entre el intrprete de rdenes y la orden.

3) Diferidas: hay intrpretes de rdenes que admiten la ejecucin de rdenes

en el momento especificado previamente. Un ejemplo de ello es la ejecucin

de aplicaciones de clculo intensivo o de simulaciones largas durante la no-

che. Esta modalidad habilita la ejecucin de programas fuera de una sesin de

trabajo.

El problema de las ejecuciones en background y de las diferidas es la entrada/salida.

Una solucin muy utilizada en muchas ocasiones es el redireccionamiento hacia

ficheros o el redireccionamiento desde ficheros. Las salidas tambin se pueden re-

direccionar hacia el servicio de correo electrnico y que los resultados vuelvan en

un mensaje. Esto resulta til en especial en las ejecuciones diferidas fuera de la se-

sin de trabajo*.

El intrprete de rdenes como lenguaje de programacin

El intrprete de rdenes dispone de un lenguaje de programacin propio que nos

permite hacer pequeos conjuntos de rdenes que se pueden ejecutar de manera

conjunta. Estos programas son ficheros de texto en los que podemos guardar una

secuencia de rdenes. En tanto que lenguaje de programacin, el intrprete de r-

denes incorpora sentencias de control de flujo que permiten realizar condiciona-

mientos, crear bucles, controlar errores, etc.; hay que decir que este lenguaje se

ejecuta de manera interpretada y es independiente de los dispositivos. Todos estos

programas se crean y se modifican utilizando editores de texto estndar.

Pensad qu es lo que tiene que hacer el intrprete de rdenes de cada usuario

cuando diferentes usuarios desean utilizar el mismo programa. Imaginad un con-

junto de programadores trabajando en la misma mquina y utilizando el mismo

editor para crear sus programas. Hay que hacer tantas copias del proceso de edi-

cin? Pueden compartir el mismo cdigo y, en cambio, tener asignados entornos

diferentes? A lo largo de este mdulo didctico iremos presentando algunas solu-

ciones para estos casos.

El intrprete de rdenes como personalizador del entorno de trabajo

Otra caracterstica importante del intrprete de rdenes es que personaliza el

entorno de trabajo del usuario. Cuando se inicia la sesin de trabajo, y como

Recordad que hemos visto la ejecucin concurrente de un programa en el subapartado 2.3. del mdulo didctico Introduccin a los sistemas operativos.

* Encontramos un ejemplo de redireccionamiento de salidas

en el sistema operativo UNIX cuando utilizamos la orden at.

Un lenguaje...

... muy utilizado es el que per-mite crear lotes de rdenes en MS-DOS, los cuales se guardan en ficheros que contienen la extensin .bat de lote de r-denes (o batch). En UNIX se denominan scripts, y las rde-nes que soportan pueden generar autnticas miniaplica-ciones. Son muy utilizadas por los programadores y, en espe-cial, por los administradores del sistema.


consecuencia de la identificacin del usuario, el intrprete de rdenes habilita

por defecto las herramientas que decide el usuario. Algunos atributos tpicos

del entorno de usuario son los siguientes: el editor de texto que prefiera el

usuario, el cliente de correo electrnico, las herramientas de creacin de apli-

caciones, la definicin de su path propio, etc. En los entornos grficos, esta

configuracin cuenta con una presentacin grfica mucho ms rica y permite

personalizar los colores, la dimensin de las ventanas, el tipo de letra, etc.

1.4. El sistema operativo desde el punto de vista del programador

La visin del usuario del sistema operativo se define principalmente por los

programas de sistema y, en concreto, por la interaccin con el intrprete de r-

denes. En cambio, el programador tiene un punto de vista muy diferente: all

donde el usuario ve las facilidades que le ofrece el sistema operativo, el progra-

mador ve los recursos fsicos y, mediante llamadas al sistema operativo, tiene

que conseguir crear un programa que aporte facilidades a un futuro usuario.

El programador dispone de las dos vas siguientes para utilizar los servicios de

sistema operativo:

Las libreras de sistema, que son un conjunto de procedimientos de uso

comn que se pueden aadir a las aplicaciones por simple referencia al pro-

cedimiento en cuestin. Esto hace que el cdigo que necesitamos se enlace

con el nuestro durante el proceso de compilacin.

Las llamadas al sistema, que no incorporan nuevos cdigos a nuestro pro-

grama, sino que hacen que, en tiempo de ejecucin, el control se transfiera

a un cdigo que pertenece al ncleo.

En general, el cdigo de las libreras es de nivel ms alto y ms independiente

del hardware utilizado que el cdigo de las llamadas al sistema.

Podis ver detalles del uso de las libreras de sistema en el subapartado 2.5.2. de este mdulo didctico.

El clculo de un logaritmo...

... puede ser una rutina de librera, pero poner un ca-rcter en un dispositivo de entrada/salida tiene que ser una llamada al sistema.


2. Las fases de ejecucin de un programa

2.1. El concepto de proceso

La nocin de proceso es fundamental para entender el funcionamiento inter-

no de los sistemas de computacin modernos capaces de ejecutar un gran n-

mero de actividades de manera simultnea. Sin embargo, no es fcil establecer

una definicin exacta. A continuacin vamos a apuntar algunas de las que

ms se utilizan:

un programa en ejecucin;

el espritu animado de un procedimiento;

el centro de control de un procedimiento en ejecucin;

la entidad a la que se le asignan los procesadores de un ordenador;

la instanciacin de un programa.

De hecho, un mismo programa puede tener numerosas instanciaciones (co-

pias) que se ejecutan de manera concurrente en el mismo sistema informtico.

Imaginemos que en un sistema multiusuario un conjunto de programadores

est utilizando un mismo editor de texto. Es necesario replicar el mismo c-

digo tantas veces como usuarios haya?

Analoga de proceso

Podramos decir que un programa es a un proceso lo que el ftbol es a un partido. El ft-bol es un deporte en el que se han definido unas normas de funcionamiento, las cualesresuelven todas las posibles incidencias y lo hacen de manera general. Cuando asigna-mos recursos a este concepto (campo, entrenador, jugadores, etc.), instanciamos el con-cepto de ftbol y se inicia un nuevo proceso: el partido. Durante aquella ejecucin,el partido se desarrolla de una manera determinada y da unos resultados concretos, perocuando finaliza deja de existir, y es imposible obtener una nueva ejecucin idntica. Elftbol, en cambio, ha permanecido ajeno a esta ejecucin y permite otras tantas instan-cias del juego como sean necesarias. La misma idea se puede aplicar a la descripcindetallada de una interpretacin musical (la partitura) y la ejecucin (el concierto) co-rrespondiente.

A pesar de que, como ya hemos dicho, no existe acuerdo en la definicin de

proceso, la expresin un programa en ejecucin es una de las definiciones

ms aceptadas. As pues, podemos formular las siguientes afirmaciones:

Un programa es la descripcin detallada para la resolucin de un

problema de manera general, en abstracto.

Un proceso es la aplicacin en concreto del programa a un caso par-

ticular y en un momento determinado, con la asignacin de unos re-

cursos concretos. Un proceso es, por tanto, irrepetible.

El trmino proceso...

... aplicado al mundo de la computacin se utiliz por primera vez para el sistema operativo Multics en los aos sesenta. Desde entonces tam-bin se utiliza el trmino tarea como sinnimo.

Hay sistemas operativos...

... que soportan que se puedan definir diferentes hilos de eje-cucin concurrente (threads) dentro de un proceso. Este aspecto de carcter ms avan-zado no se considerar en este mdulo didctico.

Podis ver la ejecucin concurrente de programas en el subapartado 2.3. del mdulo didctico Introduccin a los sistemas operativos.


2.2. El lenguaje informtico

Los programadores de aplicaciones escriben sus programas en ficheros de texto

que siguen las normas de un lenguaje informtico determinado. Estas normas

determinan la gramtica del lenguaje de programacin, y esto se debe al hecho

de que se intenta utilizar, para describir la solucin del problema, un lenguaje

tan cercano como sea posible al lenguaje natural. Para las personas de habla in-

glesa, los lenguajes de programacin resultan por completo naturales, teniendo

en cuenta que la mayor parte estn escritos en su lengua. El fichero generado es

de texto y, por lo tanto, no se puede ejecutar de manera inmediata.

A la hora de resolver un problema determinado, los programadores de aplica-

ciones informticas tienen que escribir las instrucciones o sentencias de un

programa siguiendo unas normas. El formato que utilizan se denomina len-

guaje informtico.

A continuacin presentamos un ejemplo de uso de lenguaje informtico. El

programa que se representa efecta la manipulacin de dos variables a y b y

deja el resultado en c. Suponemos que las variables a y b estn inicializadas en

los valores correspondientes al clculo deseado.

Un lenguaje de programacin o informtico es una convencin de senten-

cias y estructuras de datos que, mediante un proceso de traduccin o interpre-

tacin, puede convertirse en lenguaje mquina y se puede ejecutar. Con los

lenguajes de programacin se pueden escribir algoritmos.

La idea de los lenguajes de programacin es que los programas sean independien-

tes de la arquitectura fsica del ordenador y del sistema operativo donde finalmen-

te se ejecuten. Es decir, que sean programas portables a otros sistemas y que, al

mismo tiempo, sean tiles sin tener que introducir cambios en los mismos. Orga-

nismos tales como el American National Standards Institute (ANSI) y la International

Standards Organization (ISO) se ocupan de la normalizacin de los diferentes len-

guajes. As pues, el sistema operativo debe proporcionar las herramientas necesa-

rias para llevar a cabo el proceso de creacin de una aplicacin informtica que

pueda ser ejecutada en el propio sistema operativo.

Clasificaremos los diferentes tipos de lenguajes de programacin de la siguien-

te manera:

1) Lenguaje de alto nivel: lo utilizamos cuando escribimos las instrucciones

en un formato texto muy cercano al lenguaje natural, aunque con unas reglas

mucho ms estrictas.

c = 0;

for (i = 0; i < b; i++)c = c + a;

Notad el hecho de que el programa presentado es nicamente

un ejemplo y no contiene todo el cdigo necesario.

Las herramientas que aporta el sistema operativo y su funcionamiento se detallan en el subapartado 2.3. de este mdulo didctico.


El ejemplo anterior est escrito en un lenguaje de alto nivel. La mquina slo pue-

de ejecutar el lenguaje mquina propio y, por lo tanto, es necesario que se d un

proceso que transforme el programa anterior en un formato conocido por la m-

quina. Este proceso es el que conocemos de manera genrica como compilacin.

2) Lenguaje ensamblador: para simplificar el uso directo del lenguaje mqui-

na se han diseado lenguajes en los que cada instruccin mquina se corres-

ponde con una instruccin en un lenguaje mnemotcnico ms inteligible.

Uno de estos lenguajes es el lenguaje ensamblador, que permite escribir un c-

digo muy eficiente por el hecho de que se pueden escribir las instrucciones na-

tivas del procesador controlando la ejecucin a un nivel muy bajo. Sin

embargo, hay que decir que el lenguaje mquina cada da es ms sofisticado y

resulta casi inviable programarlo a mano, de manera que esta tarea tan com-

plicada quedar reservada a los compiladores y optimizadores de cdigo.

3) Cdigo mquina: para finalizar, las nicas instrucciones que reconoce un

procesador son las que se codifican en su cdigo particular. Este cdigo es bi-

nario, en el sentido de que se interpretan de manera directa las secuencias de

ceros y unos. Se puede ejecutar directamente y recibe el nombre de cdigo m-

quina. Por lo general, una sentencia de lenguaje de alto nivel genera diferentes

instrucciones de cdigo mquina.

Podis ver el valor de las posiciones de memoria de cada variable en la tabla

de smbolos.

Estudiamos la compilacin en el subapartado 2.4.2. de este mdulo didctico.

El principal inconveniente...

... del lenguaje ensamblador es que el programa resultante, en formato texto, es muy largo y difcil de escribir y de modifi-car; su uso queda restringido a las partes de una aplicacin que se utilice mucho en tiem-po de ejecucin. Es el caso tpico del ncleo del sistema operativo.

Este ejemplo se basa en la idea de una mquina sencilla con

un juego de instrucciones muy reducido.


El cdigo mquina se ha representado en notacin decimal para cada cam-

po. El cdigo de operacin slo ocupa 2 bits, y los cdigos del operante de

origen y de destino ocupan 7 bits cada uno. Siempre direccionamos de ma-

nera directa la posicin de memoria de la variable, motivo por el cual los

valores constantes cero y uno se tienen que grabar en una posicin de me-

moria.

La mquina no dispone de una operacin de salto incondicional. Para si-

mularla (ir a la etiqueta for:), hacemos que el resultado de la comparacin

previa sea siempre cierto, y esto es algo que conseguimos comparando cual-

quier posicin de memoria consigo misma (la variable i, en el ejemplo).

Podis ver el valor de las posiciones de memoria de cada variable en la tabla

de smbolos.

2.3. Las herramientas para la creacin de una aplicacin

informtica

Dentro de los programas de utilidad del sistema operativo, encontramos un

amplio abanico de los catalogados como programas de apoyo a los lenguajes

de programacin, entre los cuales podemos encontrar las siguientes herra-

mientas:

1) Editores de texto: forman parte de las utilidades del sistema que permi-

ten la edicin de ficheros que contienen informacin en formato texto. Estos

ficheros pueden ser de mensajes, de configuracin del sistema operativo*,

pero tambin pueden ser ficheros de cdigo de alto nivel de una aplicacin

informtica. Recordemos que los programas escritos en alto nivel no son

ms que ficheros de texto escritos con las normas de un lenguaje de alto

nivel.

2) Compiladores-ensambladores: aquellos programas que transforman los

programas editados en formato texto en un formato que la mquina pueda

ejecutar. Los ficheros resultantes se denominan ficheros ejecutables, y su

contenido se representa en el formato binario que el hardware puede ejecutar

de manera directa. Tanto los programas fuente de alto nivel como los editados

en ensamblador se escriben en formato texto. No es nada habitual llevar a

cabo la transformacin de programas de alto nivel a ejecutables y que esta

transformacin se pueda realizar en un nico paso. Ms adelante veremos este

proceso con ms detalle.

3) Libreras: el sistema operativo permite la gestin de libreras para ayudar a

crear programas. stas posibilitan la extensin de las funciones que se pueden

* Recordad que estos pequeos programas tambin reciben la denominacin inglesa scripts.

Veremos la compilacin en el subapartado 2.4.2. del presente mdulo didctico.


utilizar de manera directa y, as, hacen que el programador se ahorre el pesado

trabajo de programar muchos procedimientos de entrada/salida o de gestin

de ficheros que se repiten para cualquier tipo de aplicacin. Mediante el uso

de las libreras aprovecharemos un conjunto de rutinas que ya est muy depu-

rado y experimentado.

4) Montadores* (enlazadores): son aplicaciones que agrupan diferentes m-

dulos objeto y las libreras del sistema con el fin de obtener un programa eje-

cutable nico. Su tarea principal es resolver las referencias cruzadas entre los

diferentes elementos que no han sido resueltas en el transcurso de las prime-

ras fases de compilacin. A pesar de que en algunas ocasiones se encuentran

como aplicaciones separadas de los sistemas operativos, por lo general se eje-

cutan de manera automtica en la fase final de los entornos integrados de

compilacin.

5) Depuradores: estn formados por una serie de aplicaciones que permiten

la ejecucin controlada de un programa que sirva para resolver posibles erro-

res. Con la intencin de hacer viable el uso de un depurador, es necesario rea-

lizar las fases previas en esta modalidad. El compilador y el montador debern

preparar el cdigo resultante para este fin.

6) Ejecutadores-cargadores: constituyen el ltimo paso del proceso y per-

miten la ejecucin de los ficheros ejecutables resultantes de los pasos ante-

riores, despus de asignarles los recursos del sistema. En los sistemas

operativos antiguos, esta orden era explcita*, mientras que en la actualidad,

cuando se indica el nombre de un fichero ejecutable, se interpreta que hay

que iniciar su ejecucin.

* Montador es el equivalente espaol del nombre ingls linker.

* En los antiguos SO, la orden de ejecucin de ficheros se explicitaba con instrucciones como run o load.

El sistema operativo

La figura muestra el sistema operativo en forma de capas donde se ubican las utilidades del programador que se han presentado. Las llamadas al sis-tema operativo son servicios que permiten acceder a las partes ms internas del cdigo del sistema operativo de ma-nera controlada.

Figura 3


2.4. El proceso de creacin de un programa ejecutable

Utlizando las herramientas que hemos descrito podemos crear y ejecutar una

aplicacin. Para ello tenemos que pasar por un conjunto de fases que desarro-

llaremos a continuacin.

2.4.1. La edicin

La herramienta que se utiliza es cualquier procesador de texto, que, de hecho,

puede ser muy sencillo y no necesita grandes prestaciones en cuanto al formato

del texto. En cambio, resulta conveniente que pueda gestionar ms de un fichero

de manera simultnea o que disponga de buenas herramientas de bsqueda y ma-

nipulacin de texto. Hay editores especficos para algunos lenguajes de programa-

cin que pueden resolver ciertos problemas sintcticos del cdigo o pueden

presentar las partes de un programa en diferentes colores.

2.4.2. La compilacin (ensamblaje)

La estructura de un programa objeto ya contiene los cdigos correspondientes a

las instrucciones mquina. No obstante, el programa objeto no puede resolver to-

das las direcciones que incluye a causa de las dos razones que ahora mostramos:

1) En primer lugar, porque los programas de una aplicacin estn escritos por

regla general en diferentes ficheros o mdulos. As, si tenemos que hacer refe-

En esta fase, el programador tiene que transcribir todas las ideas

existentes para solucionar los problemas en un fichero de texto que

se denomina fichero fuente. Las instrucciones del programa deben

escribirse siguiendo las normas estrictas del lenguaje de programa-

cin que se utilice.

En el proceso de traduccin (compilacin) a partir de un programa es-

crito en lenguaje de alto nivel denominado programa fuente, obtene-

mos un equivalente* de ste en lenguaje mquina que se conoce como

programa objeto. Si el programa fuente es el ensamblador, esta fase tam-

bin se denomina ensamblar, y en este caso la traduccin es ms sencilla,

teniendo en cuenta que, como ya hemos dicho, a cada instruccin en en-

samblador le corresponde una instruccin mquina. A partir de esta fase

no se dar ninguna diferencia entre los objetos que provienen de un len-

guaje de alto nivel y los que son de formato ensamblador.

* Este programa equivalente poseer la misma informacin, pero

en un formato diferente.

Por ejemplo,...

... se pueden utilizar los recursos del editor de texto para diferenciar las palabras reservadas, los nombres de las variables, los procedimientos, etc.


rencia a una variable o a un procedimiento que est escrito en otro mdulo,

no la podremos resolver en este paso.

2) En segundo lugar, porque los programas pequeos de uso muy comn,

como pueden ser los clculos matemticos ms o menos complejos, el con-

trol de determinadas operaciones de entrada/salida sobre ficheros o disposi-

tivos y otros procedimientos muy genricos, por lo general ya se encuentran

programados, compilados e incluidos en un conjunto de ficheros denomi-

nados libreras.

Las libreras son un conjunto de mdulos objeto organizados de manera

adecuada. El mismo fabricante del software de apoyo a los lenguajes de pro-

gramacin suele facilitar este fichero. Con las libreras, el programador se

ahorra mucho trabajo, y se reduce de manera considerable el tamao del

programa y el tiempo de programacin. Normalmente el fabricante no fa-

cilita el programa fuente de las libreras, pero s proporciona las instruccio-

nes y los parmetros necesarios para utilizarlas.

Tanto los mdulos objeto como las libreras indican las direcciones de manera

relativa respecto el inicio del programa. Despus de esta primera fase de com-

pilacin, disponemos de un conjunto de mdulos objeto con referencias de

direccionamiento en relacin con el mdulo, as como otras referencias exter-

nas sin resolver. En esta fase se van a crear tres estructuras:

. La tabla de smbolos, que indica para cada smbolo definido en un mdulo

objeto (variable, procedimiento o constante) cul es su ubicacin.

La tabla de reubicacin, donde se indica qu instrucciones hacen referencia

a smbolos no definidos dentro de un mdulo objeto.

La tabla de referencias externas, que indica qu referencias a smbolos ser

necesario modificar en el proceso de montaje.

Sin embargo, no es objeto de esta asignatura establecer con detalle cmo se

tratan estas tablas, ni tampoco cmo se utilizan.

Ejemplo de compilacin

Consideremos que hay dos mdulos: producto.c y principal.c. En prin-

cipal (observad la pgina siguiente) encontramos un bucle que imprime los cua-

drados de los n primeros nmeros; en el ejemplo se ha tomado el valor n = 10.

Este programa realiza una serie de llamadas a un segundo mdulo en el que se


ha escrito el cdigo para efectuar el producto. Recordad que slo se trata de un

ejemplo didctico en el que no se ha resuelto todo.

En primer lugar podemos ver, de manera muy simplificada, cmo es la com-

pilacin de producto.c. Presentamos el cdigo de ensamblador slo para in-

tuir el significado del cdigo mquina.

Las constantes 0 y 1 se han cargado en posiciones de memoria, puesto que la

mquina no dispone de direccionamiento inmediato.

Ahora podemos ver el contenido del programa principal.c:

n = 10;

for (i = 0; i < n; i++) {a = i;b = i;producto ( ) ;printf (i = %d cuadrado = %d \n, i, c) ;}

Nota

En el ejemplo no se ha consi-derado la instruccin mquina para realizar el producto. Re-cordad que utilizamos una m-quina sencilla con un juego de instrucciones extremadamen-te reducido.


A la hora de codificar las instrucciones CALL y RET, se utiliza el mismo cdigo

que para la instruccin BEQ, y se utiliza el campo de origen para distinguir dequ instruccin se trata, 0 para BEQ, 1 para CALL y 2 para RET.

Es importante que veamos que hay una serie de referencias externas no resuel-

tas, como las direcciones de las variables a y b, y las de los procedimientos

producto y printf.

2.4.3. El montaje (enlazado)

El montaje es el proceso que se encarga de agrupar todos los mdulos corres-

pondientes a un programa, as como las libreras si hace falta, para construir

el programa ejecutable. Los programas que utilizan estas funciones se deno-

minan montadores*. De hecho, el trabajo principal del enlazador es resolver las

El proceso de compilacin...

... es irreversible, puesto que no existe ninguna posibilidad de recuperar los ficheros fuente originales a partir de mdulos objeto.

* Los montadores tambin se denominan enlazadores

o linkadores.


direcciones externas entre los mdulos, as como con la librera. El resultado

final del enlazador es el programa ejecutable definitivo con un espacio lgico

de direcciones que est completamente construido.

El encabezamiento de un fichero ejecutable contiene informacin relativa

al procedimiento que hay que seguir para cargarlo en la memoria: tamao de

la pila y de los datos no inicializados o dinmicos, nmero de segmentos (si es

que los hay), especificacin sobre si el cdigo se puede compartir con otros

procesos, etc. Asimismo, indica si se genera cdigo para ser depurado y, en

cada caso, adjunta informacin con el nombre de las variables, los procedi-

mientos y las direcciones que sean necesarias. Es habitual que el encabeza-

miento contenga una marca, que es la signatura del fichero. Con este

identificador el sistema operativo sabe cundo un fichero es realmente ejecu-

table, siempre que la versin del sistema sea correcta, o el cdigo mquina ge-

nerado sea el apropiado.

El enlace de los mdulos del ejemplo propuesto es el que se puede ver en el

grfico de la pgina siguiente.

Podemos ver que a la hora de generar el fichero ejecutable surgen diferen-

tes problemas:

Las direcciones de las tres partes que hay que enlazar empiezan por 0.

Existen dos smbolos locales con el mismo nombre: i.

Hay variables y procedimientos que todava no se han montado.

Las direcciones de los saltos incondicionales (BEQ) pueden cambiar.

Para solucionar estos problemas, el fichero ejecutable podra ser parecido al

que presentamos ms adelante (en la figura 5).

Como podemos ver, las referencias externas se han resuelto. El compilador

no puede simplificar la doble definicin de la constante del cero y la man-

tiene por separado. El orden de los mdulos es irrelevante, de modo que

podramos crear un ejecutable equivalente alterando el orden de los mis-

mos. Tambin hay que subrayar que el cdigo de la librera se ha gestiona-

do como un mdulo ms. Por otra parte, si alteramos un solo mdulo

objeto, est claro que el resto de los objetos son perfectamente vlidos para

montar.


2.4.4. La carga

Cuando una gran cantidad de usuarios llama al mismo programa, si ste permite

su uso en modalidad compartida, el cargador observar si hay alguna copia en la

memoria del programa. En caso de que la respuesta sea afirmativa, har que el

nuevo proceso tenga todo su entorno propio excepto la parte de la memoria don-

de reside el cdigo que ser compartida con el resto de los procesos. Recordemos

el ejemplo de los programadores que utilizan el editor al mismo tiempo.

2.4.5. La ejecucin (depuracin)

Mientras se lleva a cabo el proceso de desarrollo de un programa o de una apli-

cacin informtica, suele ser muy interesante seguir la ejecucin paso a paso,

hecho que es factible gracias a los programas depuradores (debuggers).

De este modo, se pueden detectar y corregir errores que sera difcil encontrar de

otra forma, y se obtiene un programa final ms eficiente (observad la figura 4

que encontraris a continuacin).

El hecho de partir el programa fuente en varios ficheros presenta varias venta-

jas, tanto para el programador como para el sistema:

Por una parte, porque una aplicacin informtica puede tener decenas de

miles de lneas de cdigo, por lo que editar un fichero de estas dimensiones

puede resultar poco prctico.

La principal tarea del cargador es buscar los recursos que solicita el

programa ejecutable, y entre estos recursos se encuentra la memoria. El

cargador tiene que buscar la memoria libre, copiar el cdigo y asignar es-

pacio para datos y pila.

Todo este proceso se realiza adaptando las direcciones lgicas de los pro-

gramas ejecutables a las direcciones fsicas de la memoria real del siste-

ma. Por ltimo, el cargador transfiere el control a la primera instruccin

del programa y marca el proceso como preparado.

Los programas depuradores tienen como nica misin controlar la eje-

cucin de un programa, motivo por el cual permiten que el programador

pueda ver una ejecucin paso a paso (instruccin a instruccin) o por in-

tervalos de programa, visualizando de manera constante el entorno que

se va produciendo. El programador fija los puntos donde se tiene que de-

tener la ejecucin y en cada parada puede comprobar si el entorno es

correcto e, incluso, puede modificarlo.

Explicaremos con ms detalle el proceso de reubicacin en el apartado 3.2. de este mdulo didctico.


Por otro lado, porque cuando se trabaja sobre un programa no hay que mo-

dificar todo el cdigo al mismo tiempo, sino que durante el proceso de

creacin de la aplicacin se trabaja slo en ciertas partes del cdigo.

stas son las razones por las cuales es mejor partir el programa en mdulos que

agrupen funciones homogneas: permiten trabajar en ficheros de menores di-

mensiones y ms manejables.

El proceso de compilacin tambin se beneficia de estas caractersticas, puesto

que en la primera fase slo tiene que traducir los mdulos de cdigo fuente

que se hayan modificado. En la fase final o de enlace s que hay que actuar so-

bre todos los mdulos objeto, tanto los que se han modificado como los anti-

guos.

Proceso de interpretacin

Los interpretadores, slo por el hecho de intentar unificar todo el proceso de creacin deun programa, ya tienen incorporado el editor y el depurador. Cada instruccin del lenguaje

Figura 4


de alto nivel, a medida que se va leyendo, se transforma en el conjunto correspondiente deinstrucciones mquina, que se ejecuta de inmediato. El interpretador controla de manera di-recta la totalidad de las fases de la creacin y ejecucin del programa. Es un paso necesariopara la ejecucin, ya que no se genera ningn otro fichero, sino que se trabaja siempre conel fichero fuente.

La interpretacin de programas fue el primer proceso que apareci, teniendo en cuentaque los ordenadores eran de poca potencia y el proceso de compilacin resultaba dema-siado costoso; era demasiado lento para hacerlo de manera continua durante el procesode creacin y depuracin de la aplicacin. Gracias al aumento progresivo de la potenciade los sistemas informticos, la fase de compilacin cada da es ms rpida y permite tra-bajar continuamente en esta modalidad. En los ltimos tiempos, con la evolucin de lasredes de comunicaciones y la creacin de aplicaciones pensadas para este entorno, se estvolviendo a la ejecucin interpretada. Mediante el uso de intrpretes*, los procedimien-tos se envan en cdigo de alto nivel hasta las mquinas remotas que los ejecutan. Estamodalidad presenta dos grandes ventajas: el cdigo de alto nivel es ms compacto que elde mquina y, adems, es independiente de la plataforma donde se ejecuta.

2.5. Las libreras de sistema

Los lenguajes de alto nivel nos permiten realizar operaciones que el lenguaje

mquina no puede ofrecer directamente, como por ejemplo:

operaciones matemticas (ln, sen, cos, sqrt, etc.),

manipulacin de cadenas de caracteres (strcpy,strcat, etc.),

operaciones de entrada/salida por medio de dispositivos (readln,printf,

open, etc.),

asignacin dinmica de memoria (malloc,mfree, etc.),

creacin y gestin de procesos (fork,exec,exit, etc.).

Figura 5

* El lenguaje Java sobre entornos de visualizadores de Internet

es un ejemplo de lo que acabamos de exponer.


Los lenguajes de alto nivel permiten efectuar operaciones de este estilo de ma-

nera directa, pero para que se puedan ejecutar hay que aadir fragmentos de

cdigo nuevos que las resuelvan: las libreras de sistema.

Los procedimientos de las libreras son muy genricos, y estn pensados para

que muchos programadores de diferentes tipos de aplicaciones puedan utili-

zarlos. Dentro del conjunto de las libreras, por lo general se dispone de herra-

mientas para construir otras nuevas. El programador puede dar formato de

librera a aquellos procedimientos de carcter ms general y ms utilizados y

comprobados por un programador o un equipo de programadores, y utilizar-

los as con una mayor facilidad en diferentes aplicaciones.

Podemos agrupar las libreras en las tres familias que tenemos a continuacin:

1) Libreras estndar: son las ms genricas y, por lo general, estn estanda-

rizadas para cada lenguaje de programacin de alto nivel, por lo menos en un

conjunto de procedimientos. Las reas ms comunes son: la gestin de fiche-

ros y de dispositivos de entrada/salida, las funciones matemticas, el manejo

de ficheros, la manipulacin de cadenas de caracteres, etc.

2) Libreras especializadas: son aquellas que, de manera opcional, se aaden

al sistema para resolver problemas ms especficos que las libreras estndar no

pueden solucionar. Un buen ejemplo son las libreras especializadas en clcu-

los matemticos, pero tambin hay libreras de clculo matricial, estadstico,

etc. Del mismo modo, se suministran para el uso de hardware muy especfico,

como es el caso de los entornos industriales.

3) Libreras de llamadas al sistema operativo: a pesar de que el ncleo de

las llamadas al sistema no forma parte del programa ejecutable y reside en el

ncleo, es necesario aadir algo de cdigo para adaptar el formato de las lla-

madas, el paso de parmetros u otra informacin complementaria. Durante

una llamada al sistema operativo, se transfiere el control al sistema y se con-

muta en el modo de ejecucin del mismo. Desde el lenguaje ensamblador po-

demos realizar llamadas directas al sistema, y no es necesario que lo hagamos

por medio de libreras.

Las libreras de sistema son un conjunto de mdulos objeto organiza-

dos de manera adecuada. Estas libreras son suministradas bien por el fa-

bricante del sistema operativo, bien por la empresa que ha desarrollado

el entorno de compilacin. Las funciones que contienen estn catalo-

gadas y se sabe a la perfeccin cmo hay que utilizarlas: contienen las

denominaciones de los procedimientos, los parmetros necesarios y la

forma como se pasan, as como los posibles ficheros complementarios*.

No es habitual disponer del cdigo fuente de las libreras. * Un ejemplo de ficheroscomplementarios seranlos encabezamientos del C.

Las llamadas a las libreras se explican con ms detalle en el subapartado 2.4.3. del presentemdulo didctico.


Hay que tener en cuenta que desde el cdigo de las libreras estndar y las es-

pecializadas se pueden realizar llamadas al sistema operativo. Las operaciones

que solicitan recursos al sistema, que trabajan con los perifricos, que gestio-

nan los procesos o que piden informacin del sistema o de los recursos que

gestiona son competencia del sistema operativo, ya que ste es el que sabe

cmo acceder y cmo hay que gestionarlas. Por este motivo, las rutinas de li-

brera que llevan a cabo estas funciones acaban por efectuar una llamada al sis-

tema. As pues, un lenguaje informtico de alto nivel slo puede hacer aquello

que le permite el sistema operativo sobre el cual se ejecuta.


3. Los espacios de direcciones de un proceso

En este apartado nos disponemos a analizar el mecanismo de carga de un

programa en la memoria y en qu se diferencia esta memoria de la asignada

a otros procesos o de la asignada al mismo sistema operativo. Una vez se haya

hecho esto, estaremos en disposicin de analizar con ms detalle tanto el en-

torno de ejecucin (proceso) como los mecanismos de comunicacin entre

los procesos y el sistema operativo.

3.1. El espacio lgico y el espacio fsico

Partimos del espacio definido en el fichero ejecutable, el cual puede tener una

estructura de una o dos dimensiones (espacio lineal o segmentado). Estos es-

pacios se tienen que transportar desde los ficheros ejecutables hasta la memo-

ria que gestiona el sistema operativo. La estructura con que cuenta esta

memoria puede ser muy diferente en funcin del modelo que el sistema ope-

rativo haya elegido.

3.2. La carga en la memoria: reubicacin

La propiedad de la reubicacin hace referencia a la capacidad de cargar y des-

pus ejecutar un programa en cualquier posicin de memoria, as que es la

propiedad contraria a la obligatoriedad de conocer todas las direcciones de

manera fija en tiempo de compilacin. Resulta obvio que hay un mecanismo

de traduccin entre las direcciones lgicas y las fsicas. En funcin de cmo se

realice, podemos distinguir dos tipos de reubicacin, que son las siguientes:

Un programa reubicable se puede ejecutar en diferentes direcciones,

que son asignadas por el cargador. Por este motivo, se establece la distin-

cin entre direcciones lgicas y fsicas:

Direcciones lgicas: son las referenciadas por el programador. Sue-

len ser identificadores que reconocen las diferentes partes de un pro-

grama dentro de su espacio de direcciones. Son referencias locales en

el sentido de que el entorno donde se tengan que ejecutar carece de

importancia.

Direcciones fsicas: son las direcciones asignadas en tiempo de car-

ga, es decir, el lugar donde en realidad residir el proceso durante su

ejecucin.

Veremos la reubicacin con ms detalle en el apartado 1 del mdulo didctico La gestin de la memoria.


1) Reubicacin esttica: se realiza antes o durante la carga del programa en

la memoria para ser ejecutado. Durante el proceso de creacin de un programa

ejecutable, por lo general se toma la direccin lgica 0 como la direccin ini-

cial del programa. De esta forma, el resto de las direcciones del programa sern

direcciones lgicas relativas a la direccin final de carga del programa. Cuando

la imagen del programa se carga, todas las direcciones marcadas como reubi-

cables se transforman en la direccin fsica final. La referencia para poder ha-

cer esto es la direccin lgica inicial.

Tras haber modificado todas estas direcciones para reubicarlas, no se pueden

distinguir las direcciones reubicadas de las originales; en otras palabras, no se

puede volver a reubicar durante la ejecucin. Si por alguna razn el proceso

tiene que salir de su espacio fsico asignado, o bien vuelve exactamente al mis-

mo sitio o bien se tiene que iniciar el proceso de reubicacin desde el princi-

pio, es decir, se tiene que volver a cargar.

A causa del problema anterior, la reubicacin esttica se encuentra prctica-

mente limitada a ciertos sistemas operativos en los que el mecanismo de carga

de programas en la memoria es muy determinado y el cdigo se tiene que di-

rigir a particiones de memoria predeterminadas.

2) Reubicacin dinmica: en este caso, la transformacin entre las direccio-

nes fsicas y lgicas se efecta en tiempo de ejecucin. Como antes, los progra-

mas ejecutables resultantes de las compilaciones adoptan la direccin inicial

de referencia 0. Estas imgenes de los programas ejecutables se cargan de ma-

nera directa en cualquier posicin de la memoria, y una parte del hardware es

la que se encarga de hacer el trabajo de reubicacin de direcciones lgicas en

fsicas.

Cuando el proceso se est ejecutando, todos los accesos a la memoria se reubi-

can antes de acceder realmente a la memoria fsica. Este proceso se lleva a cabo

utilizando los registros de base. Para obtener la direccin fsica, cada referencia

que realiza un proceso durante su ejecucin es transformada por la suma de la

direccin lgica ms el registro de base. Este mecanismo resulta transparente

por completo para el programador.

La transformacin de direcciones depender en gran medida del hardware del sis-

tema. Por este motivo, no podemos dar ms detalles sin hablar de una arquitec-

tura de ordenador determinada, aunque este tema no es objeto de esta asignatura.

Podis ver cmo se obtiene la direccin fsica en el mdulo didctico La gestin de la memoria de esta asignatura.


4. Los mecanismos de entrada al sistema operativo: traps, excepciones e interrupciones

Como hemos comentado antes, uno de los caminos para utilizar las llamadas

al sistema es darle rdenes de manera directa al intrprete de rdenes, que des-

pus genera el conjunto de llamadas necesario. Sin embargo, el mtodo ms

interesante una vez llegados a este punto de la materia es la llamada a los ser-

vicios del sistema operativo en tiempo de ejecucin.

Aqu se presentar una serie de problemas que hay que solucionar, como pue-

den ser el tipo de direccin donde encontramos las rutinas de servicio. Si se trata

de direcciones fijas, le quitamos flexibilidad al sistema operativo, puesto que no

podr reubicar o cambiar el tamao de las rutinas que forman el conjunto de

llamadas al sistema, hecho que, por otra parte, comportara cambios en los pun-

tos de entrada al cdigo. Por lo general se hace por medio de tablas de direccio-

nes que contienen la direccin real de la rutina, de manera que las aplicaciones

slo tienen que hacer referencia a un identificador* que no cambia para un de-

terminado sistema. Este identificador es asignado por el compilador.

Desde el punto de vista del proceso, lo nico que ste tiene que hacer es ceder

el control de la ejecucin a una parte de cdigo que se ubica en el ncleo del

sistema. Es un paso similar a la llamada de cualquier subrutina de la aplica-

cin. La primera diferencia es que las rutinas del ncleo se ejecutan en modo

sistema y, por lo tanto, tienen una mayor capacidad para gestionar los recur-

sos del sistema. Otra cuestin prctica que no podemos olvidar es que las ru-

tinas de las llamadas al sistema son comunes a todos los usuarios y, como

consecuencia inmediata de este hecho, el cdigo se encuentra mucho ms depu-

rado y resulta tambin mucho ms fiable que el que pudiesen realizar los progra-

madores para cada aplicacin. A menudo, para operar con recursos compartidos,

no existe otra alternativa que hacerlo mediante estas llamadas.

4.1. Las rutinas de servicio del sistema operativo

Ya hemos apuntado que un sistema operativo proporciona un entorno para la

ejecucin de programas. Pues bien, una parte de este entorno consiste en un con-

junto de servicios que son accesibles para los procesos que se estn ejecutando en

el sistema. Estas funcionalidades son como una extensin de las instrucciones que

puede ejecutar el procesador y se encuentran en la lnea de una concepcin del

sistema en tanto que mquina virtual que puede hacer operaciones ms compli-

cadas que el hardware en s mismo.

Las rutinas de servicio se desarrollan con ms detalle en el subapartado 4.1. de este mdulo.

* El identificador suele ser un nmero.


Los programadores de aplicaciones invocan los servicios del sistema desde sus

programas mediante la invocacin de llamadas al sistema*. Las llamadas desde

el intrprete de rdenes se traducen y se ejecutan como una serie de llamadas al

sistema. Adems de proporcionar la funcionalidad disponible desde el intrpre-

te de rdenes, estas llamadas ofrecen un control ms detallado de las operacio-

nes del sistema y, adems, un acceso ms directo y flexible a los dispositivos de

entrada/salida y, en general, a los recursos del sistema, que al mismo tiempo es

independiente del tipo de hardware.

A pesar de que cada sistema operativo puede ofrecer servicios muy especficos,

podemos agruparlos de manera general en las siguientes clases:

1) Gestin de procesos. En este apartado englobamos las llamadas que hacen

referencia a la creacin y eliminacin de procesos, pero tambin podemos en-

contrar otros servicios como la suspensin y la reanimacin de procesos; asi-

mismo, tenemos la posibilidad de modificar atributos de ejecucin tales como

la prioridad o el tiempo de cuota de CPU asignado. Ya veremos ms adelante

que todas estas llamadas son controladas por el ncleo del sistema operativo,

que determina en ltima instancia si la peticin que realiza el proceso se pue-

de servir de acuerdo con sus privilegios.

2) Sealizacin entre procesos. En un sistema multitarea, el nexo natural de

unin entre las aplicaciones en ejecucin es el sistema operativo. As pues, el

vehculo apropiado para comunicar y sincronizar procesos es el ncleo del sis-

tema operativo. Seales, semforos, regiones crticas y otras funciones sern

ejemplos concretos de esta clase de servicios.

3) Gestin de dispositivos de entrada/salida. Los servicios relacionados con

el sistema de entrada/salida son de los ms completos y tambin de los ms

utilizados. Sus funciones principales son crear, abrir y cerrar canales de entra-

da/salida, as como escribirlos y leerlos. Los sistemas operativos tambin pro-

porcionan un conjunto de llamadas para conocer el estado de un canal o

cambiar sus atributos.

4) Gestin directa de los recursos del sistema. Este grupo de servicios es

muy especfico de cada sistema operativo, pero un ejemplo comn es la ges-

tin de la memoria. Algunas de las operaciones que se efectan con la memo-

ria del sistema son: capturar, liberar, proteger, compartir, etc.

5) Gestin del sistema de archivos. Junto con el bloque de servicios de en-

trada/salida, tambin es un grupo de servicios muy utilizado. La gestin del

sistema de ficheros incluye las funcionalidades ms conocidas por los usuarios

del intrprete de rdenes en relacin con la gestin de archivos y directorios:

crear y eliminar entradas, cambiar de directorio, mostrar el directorio actual,

etc. Del mismo modo, permite llevar a cabo las operaciones tpicas sobre fiche-

ros: crear, eliminar, copiar, cambiar de nombre, etc.

* Estas llamadas al sistema tambin se denominan Application

Programming Interface (API ).

El ncleo del sistema operativo se explica con ms detalleen el subapartado 4.4. de estemdulo didctico.


6) Protecciones. El sistema operativo tiene que combinar los atributos entre el

proceso y el servicio que solicita para determinar si este servicio se puede dar o

no. Es una de las partes ms utilizadas por los administradores de los sistemas,

en especial como llamadas del sistema, pero no lo son tanto por los usuarios.

7) Funciones de tiempo. Todas las referencias temporales de los procesos

provienen de llamadas al sistema operativo, como por ejemplo la fecha, la ho-

ra, etc. Tambin se pueden capturar datos sobre el tiempo de ejecucin de un

proceso, el tiempo de CPU u otras funciones estadsticas de este tipo.

4.2. Los mecanismos de acceso a los servicios

En este subapartado vamos a desarrollar con ms detalle los mecanismos de

transferencia al sistema operativo para hacer llamadas al sistema, es decir, para

solicitar servicios del sistema operativo de manera voluntaria.

Los diseadores del sistema operativo tienen que proporcionar una manera de

acceder a los servicios del sistema desde las aplicaciones de usuario en tiempo

de ejecucin. Las finalidades de este acceso son las siguientes:

Por un lado, hay que ofrecer la facilidad de transferir el control de la CPU

al sistema operativo, hecho que permite ejecutar cdigo en modo supervi-

sor con el consecuente cambio de privilegios.

Por otro lado, tambin es necesario establecer la manera de pasar los par-

metros necesarios para atender la peticin de servicio.

Cambio de modo de ejecucin

Una consecuencia relevante de realizar un cambio a modo de ejecucin sistema es queproporciona otro espacio de direcciones mucho ms poderoso que permite el acceso alvector de interrupciones de las reas de control de dispositivos de entrada/salida y, engeneral, de todo el espacio de la memoria. Por este motivo, los sistemas operativos mini-mizan al mximo el tiempo (de hecho, la cantidad de cdigo) que hay que ejecutar enesta modalidad, y as el sistema permanece ms tiempo en la modalidad usuario, que po-see mucha menos potencia y, en consecuencia, menos poder.

A continuacin describiremos los mtodos de acceso a los servicios ms co-

nocidos:

1) Puntos fijos. En esta modalidad se parte de la premisa de que las rutinas

de servicio se codifican en el sistema operativo como simples procedimientos,

lo cual permitir realizar las llamadas de manera idntica a las de cualquier

procedimiento de usuario. El problema es que cuando se desarrolla la aplica-

cin informtica, el sistema operativo ya est en la memoria y, por lo tanto,

los compiladores pueden tener problemas a la hora de vincular los nombres

Las llamadas al sistema se han introducido en el subapartado 4.1. de este mdulo didctico, en la modalidad de llamadas explcitas al sistema operativo.

Encontraris la ejecucin en modo supervisor en el subapartado 2.1. de este mdulo didctico.


simblicos de los procedimientos con las direcciones reales que encontrarn

los procesos durante el ejercicio. Esto se intentar solucionar de dos formas:

a) En muchas ocasiones se opta por hacer referencia al procedimiento por

medio de la direccin real del procedimiento, pero, como es obvio, esto repre-

senta muchos inconvenientes para mantener estables estas direcciones.

b) Una solucin ms operativa es utilizar nombres simblicos y suministrar

las direcciones para las libreras del sistema, hecho que va a permitir al mon-

tador resolver las referencias a los servicios del sistema operativo que se hayan

llevado a cabo en la aplicacin.

Ambas soluciones son sensibles a los cambios de ubicacin en los puntos de

entrada al sistema operativo, que, por otra parte, son frecuentes durante la

vida de un sistema operativo a lo largo de las diferentes versiones por las cuales

pasa o a causa de las diferentes configuraciones del software.

Este mtodo no garantiza la portabilidad de las aplicaciones, las cuales se tienen

que recompilar en cada sistema en concreto donde se ejecuten. Otro problema

es que si realizamos una transferencia directa del control hacia el rea de siste-

ma, el hardware no puede llevar a cabo un cambio de ejecucin ms controlado,

puesto que no se da cuenta del cambio de modalidad de ejecucin.

2) Llamadas al supervisor o traps. La clave para el uso de los traps es la trans-

ferencia indirecta del control para la utilizacin de una tabla de direcciones de

las rutinas de servicio. El trap realiza la vinculacin con el punto de entrada del

servicio en tiempo de ejecucin. En el momento de carga en la memoria del n-

cleo del sistema operativo, las entradas de la tabla se llenan con las direcciones

reales de las rutinas correspondientes a cada nmero de servicio. Si no varan es-

tos nmeros, estaremos garantizando la portabilidad del cdigo a diferentes ver-

siones del sistema operativo o de diferentes configuraciones hardware.

Las llamadas al supervisor son instrucciones hardware especializadas en trans-

ferir el control de la ejecucin al sistema operativo. De hecho, es una clase

concreta dentro del conjunto general de interrupciones del sistema*.

En principio, podemos resolver la funcionalidad asignando una numeracin

diferente de la interrupcin para cada tipo de llamada. Esto hace que las lla-

madas no tengan la necesidad de conocer las direcciones concretas de cada

rutina de servicio, pero todava se tiene que fijar el nombre de tipos de lla-

madas, ya que esto depende del hardware. La solucin ms abierta consiste

en utilizar un conjunto muy reducido de interrupciones y pasar un par-

metro que permita el redireccionamiento de cada servicio a su lugar corres-

pondiente (observad la figura 6). Estas llamadas admiten como mnimo un

operante, que es la identidad del servicio deseado. As, con un nico punto

Podis consultar la definicin de aplicacin portable en el subapartado 2.2. del presente mdulo.

Para hacer llamadas a un cdigo externo...

... al del proceso en tiempo de ejecucin hay una tcnica: las llamadas a las Dynamic Link Libraries (DLL). Sin embargo, hay que tener en cuenta que no son llamadas al sistema operativo, no se da cambio de modo de ejecucin, sino que continan siendo de usuario.

* Tambin se denominan interrupciones software o SuperVisor

Call (SVC).


de entrada al sistema podemos ofrecer un conjunto de servicios que se dis-

tinguen por este operante.

La siguiente figura presenta un mecanismo tpico para realizar llamadas al sis-

tema por interrupciones de software, y muestra cmo podemos distinguir las

diferentes llamadas utilizando una tabla de servicios inicializada con las direc-

ciones reales de las rutinas. En principio no existe ninguna diferencia entre

una interrupcin de hardware o una de software, puesto que ambas se inician

en los circuitos que pueden transferir la ejecucin del sistema al rea de siste-

ma, o ncleo, de manera controlada. Una vez se ha detectado la situacin, el

mismo hardware transfiere el control a la rutina que se indica en la tabla de

servicios. Cuando finaliza, el control es retornado a proceso de usuario de ma-

nera similar a como lo hacen las subrutinas (observad la figura 6).

4.3. Los mecanismos bsicos de transferencia

En este apartado discutiremos los mtodos ms habituales para transferir el

control de la ejecucin de un cdigo al sistema operativo, ya sea por voluntad

del proceso en una ejecucin, ya sea por otro motivo.

Las libreras del sistema, en particular las de las llamadas, tienen que pro-

porcionar los detalles ms especficos que dependen de cada sistema

para conseguir una transferencia adecuada del control al rea del siste-

ma.Tambin tienen que informar acerca de cules son los parmetros

necesarios y de la forma de pasarlos.


Nos encontramos con tres mecanismos bsicos por los cuales se puede transferir

el control de ejecucin desde un usuario al sistema operativo. Son los siguientes:

1) Llamadas explcitas al sistema operativo. Son puntos concretos del c-

digo de usuario donde se realiza una transferencia explcita del control al sis-

tema operativo. Desde este punto vista, son acontecimientos sncronos.

2) Excepciones. Son roturas de secuencia no previstas; de hecho, son inte-

rrupciones, pero provocadas directamente por la ejecucin del mismo cdigo

del usuario en curso. Cuando surge un problema de este tipo, se genera una

interrupcin que llama a una rutina de servicio, y sta intenta solucionar el

problema o bien informar al sistema operativo de la situacin. A partir de aqu

no se puede generalizar; en algunas ocasiones no queda ms alternativa que

suspender la ejecucin del proceso.

3) Interrupciones. Son sucesos asncronos totalmente ajenos al proceso en eje-

cucin. El hecho es que transfieren el control de la CPU al sistema operativo desde

el proceso en ejecucin. Para llevar a cabo este cambio, el mecanismo que acta

es similar al de un cambio de contexto entre procesos, pero en este caso, tras haber

acabado la rutina de servicio, se vuelve al punto de ejecucin del mismo proceso.

4.4. El ncleo del sistema operativo

Antes de detallar cules son y cmo se utilizan los diferentes servicios que pro-

porciona el sistema operativo, haremos una pequea introduccin acerca del

ncleo de un sistema operativo dado, teniendo en cuenta que es la clave para

entender este tema.

El ncleo, que tambin recibe el nombre de kernel o core, slo es una peque-

a parte de la totalidad del sistema operativo, pero es el cdigo ms utili-

zado. Constatamos una cierta tendencia a hacer referencia al mismo como

si fuese el sistema operativo completo. Como ya hemos comentado, el n-

cleo reside en la memoria, en cambio otras partes del sistema se cargan en

la memoria exclusivamente cuando se necesitan.

El ncleo es la parte del sistema operativo formada por un conjunto de

procesos ubicados siempre en la memoria principal. Es el encargado de

gestionar directamente el hardware y de implementar las funciones ms

bsicas de la gestin de procesos, memoria y entrada/salida. En concre-

to, la gestin del mecanismo que regula las interrupciones es una de las

funciones ms importantes del ncleo, tanto por lo que se refiere a las

interrupciones propiamente dichas (entrada/salida), como a las excep-

ciones y las llamadas al supervisor.

Las llamadas al sistema operativo se detallan en el subapartado 4.1. de este mdulo didctico.

Un ejemplo de excepcin puede ser una divisin por cero o un error

de dispositivo de entrada/salidaque no responde.


Figura 7

El ncleo determina las formas existentes para invocar el cdigo del sistema

operativo con el fin de obtener un cierto servicio (ya sea de los dispositivos o

de los procesos).

La figura 7 muestra un diagrama de las posibles formas en que se puede ejecu-

tar el ncleo.

Para garantizar esta gestin, el ncleo utiliza todas las herramientas que ofrece

el hardware, las cuales guardan una relacin muy estrecha con el sistema de cir-

cuitos involucrado en las interrupciones. Podemos decir que los mecanismos

ms significativos son los siguientes:

1) La ejecucin de un modo privilegiado que le permite acceder a todos los

registros de control de la mquina y ejecutar instrucciones que en el modo

normal provocaran una excepcin. El hecho de que existan diferentes modos

de ejecucin hace que la ejecucin de un proceso se pueda desdoblar en fun-

Notad que la figura...

... no muestra todas las rela-ciones posibles entre los dife-rentes puntos de entrada al ncleo.Por ejemplo, slo se ha considerado el paso a un esta-do de espera por peticin de entrada/salida, pero este caso se puede extender a cualquier mecanismo por el cual un pro-ceso tiene que esperar una se-al externa para continuar.


cin de si ejecuta cdigo programado por el usuario o si ejecuta cdigo del n-

cleo. Este comportamiento se puede observar en la siguiente figura:

Figura 8

Como podis observar en el diagrama de estados, las transiciones entre los es-

tados pueden deberse a las siguientes causas:

a) De usuario a sistema. Hay dos posibilidades, que son por llamada al siste-

ma* o por una interrupcin de hardware.

b) De sistema a usuario. Cuando se acaba la ejecucin de la rutina de servicio

del ncleo, se retorna el control del flujo del proceso al usuario.

c) De sistema a sistema. Este caso viene dado por la atencin de una interrupcin

mientras se est ejecutando cdigo del sistema.

2) La jerarquizacin de las interrupciones mediante una orden de priorida-

des. Para poder organizar de manera correcta la urgencia de los servicios que se

solicitan al ncleo, es necesario que stos se organicen en funcin de unas prio-

ridades. La jerarquizacin de estos servicios mediante el hardware simplifica y

agiliza el funcionamiento del ncleo.

En la figura que encontramos a continuacin mostramos un ejemplo tpico de

cmo se pueden organizar las interrupciones:

* Una llamada al sistema puede ser implementada por una interrupcin

de software.

Figura 9


Resumen

En el este mdulo didctico hemos visto el sistema operativo como una m-

quina virtual que esconde a los usuarios la complejidad de la gestin de los

recursos hardware y software que componen un sistema computador. Para ana-

lizar este entorno y entender quines son los usuarios de un sistema inform-

tico, se ha descrito una sesin de trabajo. A partir de este anlisis hemos visto

que los usuarios del sistema, sus interlocutores directos, son los programas

que se ejecutan en el mismo. Hemos analizado el proceso de creacin de un

programa y el mecanismo de comunicacin que hay entre los programas y

el SO. Se ha introducido el concepto de proceso como entorno de ejecucin

de un programa y, por ltimo, hemos hecho una introduccin a la gestin de

los procesos que realiza un sistema multiprogramado.

El siguiente mapa conceptual refleja las relaciones que se establecen entre los

diferentes conceptos presentados en este mdulo:


Actividades

1.a) Iniciad y finalizad una sesin de trabajo breve.b) Identificad las fases de que consta.c) Identificad el proceso del shell y comprobad que siempre se encuentra presente durante la sesin.d) Utilizad la orden ps para ver los procesos activos asociados a la sesin.

2. Lanzad una ejecucin simultnea de ms de un programa utilizando el carcter &, quehar que la orden se ejecute de fondo (background). Verificad de nuevo la presencia del intr-prete de rdenes (shell) como proceso activo.

3. a) Ejecutad diferentes rdenes y determinad dnde se encuentra el cdigo.b) Distinguid orden interna de orden externa y observad cul es el camino predefinido delsistema. Podis comprobar tambin que la variable de camino predefinido forma parte delentorno del usuario. Intentadlo con las rdenes ls, cd, pwd, etc. Tambin os puede ser tilver el contenido del directorio /bin.c) Qu puede pasar si en vuestro directorio de trabajo editis un fichero de rdenes (script)con el nombre de una orden de sistema? Comprobadlo.

4. Analizad las utilidades que posee UNIX para editar, compilar, montar y depurar un pro-grama.

5. Observad cules son las utilidades de que disponis para las libreras. Podis visualizarlas,modificarlas o crear otras nuevas. Consultad el manual para conocer sus detalles.

Ejercicios de autoevaluacin

Cuestiones breves

1. En un entorno multiusuario, podis decir por qu nos tenemos que identificar para poderiniciar una sesin de trabajo?

2.a) Indicad cul es el mecanismo de bsqueda de las rdenes de usuario por parte del intr-prete de rdenes (shell).b) Explicad qu es el directorio de trabajo y el camino predefinido.

3. Qu aplicaciones resultan ms adecuadas para ejecutarlas fuera de la sesin de trabajo delusuario?

4.a) Podis explicar, de manera esquemtica, las funciones del montador?b) Con qu otras herramientas del sistema tiene relacin?c) Imaginad que habis escrito un nico fichero de programa fuente; por qu lo tenis quemontar?

5. Qu se necesita para convertir un programa en proceso?

6. Estableced las diferencias ms relevantes entre los modos de ejecucin de usuario y sistema.

7. Por qu creis que es importante que las llamadas a los servicios se realicen con la inter-vencin de interrupciones y, por tanto, del hardware?

8. Por qu no es conveniente realizar el cambio de contexto de un proceso mientras ste seencuentra ejecutando rutinas del ncleo?

9. Relacionad el intrprete de rdenes (shell) con la modalidad interpretada de ejecucin deprogramas.


Solucionario

Ejercicios de autoevaluacin

Cuestiones breves

1. Para relacionar los recursos con el usuario y los terminales. Para poder personalizar el entorno de trabajo de cada usuario. Para tener identificado al propietario de ficheros y procesos, y saber a qu servicios o fun-

cionalidades tiene derecho.

2. a) Hay rdenes que el intrprete de rdenes es capaz de ejecutar de manera directa. En el casode las rdenes externas, el intrprete busca la orden en el directorio actual y lo carga en lamemoria para que se ejecute. Si no se encuentran en el directorio actual, las rdenes externaspor lo general estn en un directorio concreto del sistema de ficheros, y el intrprete de r-denes sigue una ruta concreta.b) El directorio de trabajo (actual) es el lugar del sistema de ficheros desde donde se solicitala ejecucin de las rdenes. Suele ser el directorio desde el cual el usuario demanda la ejecu-cin de una orden, pero desde los mismos procesos se puede cambiar el directorio de trabajo. La ruta definida por el usuario para buscar los programas se guarda en una variable de sistemadenominada camino predefinido.

3. La primera condicin es que sean aplicaciones carentes de interactividad.Pueden ser aplicaciones que tienen que estar siempre en funcionamiento para ofrecer servi-cios generales, por ejemplo, el servicio de telnet, el FTP, el HTTP, etc. Por norma general, elpropietario de estas aplicaciones es el administrador del sistema.Otro tipo de aplicaciones adecuadas son las que precisan mucha carga de procesador, comolas simulaciones o las aplicaciones de clculo intensivo.

4. a) El montador combina diferentes mdulos objeto y las libreras para construir el programaejecutable. El trabajo ms importante que lleva a cabo es resolver las referencias entre las di-ferentes partes, establecer la correspondencia entre las direcciones de las diferentes variablesy procedimientos. b) El montador guarda relacin con la fase de compilacin, en la cual se producen los mdu-los objeto y las libreras del sistema.c) Siempre hay que utilizar el montador porque siempre hay que aadir los encabezamientospara el cargador y las rutinas de

sistemas operativos mod3

Documents