Apuntes t8

Enviad sugerencias y/o errores a la dirección de correo vivancos@dsic.upv.es
Procesadores de lenguajes
Unidad temática 8:
Generación de código intermedio
V. 11.1
2
!"#$"%&'%()*+'*,&)%
-.%/0&,1)2%,*+'34'&,)2%......................................................................................................%5!
"#"#!$%&'(!)*!+*&+*(*,-./%',*(!%,-*+0*)%.(!###########################################################################################################!1!
!"#$%&'()*"+#,&-$)................................................................................................................................................................)/!
012"3)45)+&(#$6&+)$2+#1$%#$)............................................................................................................................................)/!
7'4&8")45)#15+)4&15%%&"(5+)9%:$1#5#"+;).....................................................................................................................)<!
7'4&8")45)4"+)4&15%%&"(5+)9#51%5#"+;).........................................................................................................................)=!
"#2#!3,(-+4//%',*(!)*5!/6)%7'!)*!-+*(!)%+*//%',*(!#################################################################################################!8!
"#9#!:*,*+./%6,!)*!/6)%7'!%,-*+0*)%'!0*)%.,-*!4,.!7+.0;-%/.!)*!.-+%<4-'(!#########################################!=!
6.%7(('2)%"%4,'4#3)2%&'%8*"%'2+38(+83"%9%'$'4'*+)2%&'%8*%"33"9%...................................%-:!
2#"#!>//*('!.!0%*0<+'(!)*!4,.!*(-+4/-4+.!###########################################################################################################!"1!
2#2#!>//*('!.!*5*0*,-'(!)*!4,!.++.?!#######################################################################################################################!"@!
>.>.?.)@%%5+")$)3"+)535A5(#"+)45):()$11$B)A:3#&4&A5(+&"($3)5()C$+%$3)...................................................)?<!
>.>.>.)@%%5+")$)3"+)535A5(#"+)45):()$11$B)A:3#&4&A5(+&"($3)5()7)..............................................................)?D!
5.%;<=3'2,)*'2%$01,("2%'%,*2+38((,)*'2%&'%()*+3)$%&'%>$8?)%................................................%-@!
9#"#!A.+%.<5*(!?!*B&+*(%',*(!567%/.(!########################################################################################################################!"C!
9#2#!D*&+*(*,-./%6,!,40E+%/.!###################################################################################################################################!2F!
9#9#!D*&+*(*,-./%6,!&'+!/',-+'5!)*!G54H'!###############################################################################################################!21!
:.%A'>'3'*(,"2%*)%2"+,2>'(B"2.%A'$$'*)%=)3%3'+3)('2)%.......................................................%6C!
1#"#!I5.,-*.0%*,-'!)*5!&+'<5*0.!##############################################################################################################################!2@!
1#2#!D*55*,'!&'+!+*-+'/*('!############################################################################################################################################!28!
1#9!D*&+*(*,-./%6,!,40E+%/.!)*!*B&+*(%',*(!567%/.(!J/',!+*55*,'!&'+!+*-+'/*('K!###########################!2L!
1#1!D*&+*(*,-./%6,!)*!*B&+*(%',*(!567%/.(!&'+!/',-+'5!)*!G54H'!J/',!+*55*,'!&'+!+*-+'/*('K!#######!2=!
/./.?.)7'4&8")5()%"1#"%&1%:&#").....................................................................................................................................)EF!
/./.>.)G$1&$235+)3'8&%$+)B)15*15+5(#$%&'()*"1)%"(#1"3)45),3:-")......................................................................)EF!
/./.E.)H(+#1:%%&"(5+)45)%"(#1"3)45),3:-")...................................................................................................................)E?!
C.%D8#=3)13"4"2%.............................................................................................................%5:!
@#"#!D*7%(-+'(!)*!./-%M./%6,!*,!I.(/.5#!###################################################################################################################!91!
<.?.?.)I5%3$1$%&'().............................................................................................................................................................)E/!
<.?.>.)J3$A$4$)...................................................................................................................................................................)E<!
@#2#!N.+/'(!*,!O!################################################################################################################################################################!98!
<.>.?.)I5%3$1$%&'().............................................................................................................................................................)E=!
<.>.>.)J3$A$4$)...................................................................................................................................................................)E=!
E,#$,)13">F"%3'()4'*&"&"%...............................................................................................%5G!
;?'3(,(,)2%.........................................................................................................................%5H!
D)$8(,)*'2%"%$)2%'?'3(,(,)2%2'$'((,)*"&)2%.........................................................................%:H!

3
1. Códigos intermedios
Además de analizar el código fuente (fase de análisis) un compilador debe generar código
(fase de síntesis). Esta generación de código se realiza en dos fases. Una primer fase en la que el
“front-ent” del compilador produce como resultado una representación intermedia (“Intermediate
Representation” o IR) del programa fuente y una segunda fase en la que el “back-end” producirá
el código objeto.
La fase de síntesis puede generar directamente como salida un código máquina, pero en ese
caso el compilador será totalmente dependiente de la máquina destino. Además, debido a la gran
disparidad entre el tipo de instrucciones que se emplean en los lenguajes de alto nivel y en los
lenguajes máquina, la construcción del generador de código será larga y el código resultante
difícil de mantener. Otra alternativa consiste en que la fase de síntesis genere código en otro
lenguaje de alto nivel. En este caso se requiere del empleo de otro compilador para la máquina
destino que finalmente genere el código máquina. La construcción del traductor será mucho más
sencilla, pero a cambio el código ejecutable que obtendremos consumirá en general más recursos
(tiempo y memoria).
La utilización de una representación intermedia (IR) aparece como una solución a mitad de
camino entre las dos anteriores. El proceso de generación de código queda dividido en dos etapas
de traducción: una primera fase independiente de la máquina destino en la que se genera una
representación intermedia, y una segunda fase en la que, a partir de la representación intermedia,
se genera el código objeto ejecutable para la máquina destino. En la primera etapa conocida
como generación de código intermedio se genera una representación intermedia del código
fuente que se va a compilar. Esta representación intermedia, independiente de la máquina para la
que se generará código y del lenguaje fuente, será la entrada del módulo generador de código
encargado de realizar la segunda etapa de traducción. Esta tercera opción es la que vamos a
estudiar con más detalle a lo largo de este capítulo.
Un código intermedio es una estructura de código cuya complejidad está entre el código
fuente en el lenguaje de alto nivel y el código máquina. Este código intermedio puede ser
considerado como la interfaz entre el generador de código (“back-end”) y las fases anteriores del
compilador (“front-end”). Su utilización presenta algunas ventajas frente a la generación directa
de un código máquina:
• Se facilita la reutilización de toda la etapa inicial del compilador (“front-end”) para la
construcción de compiladores de un mismo lenguaje fuente para distintas máquinas.
(Fig. 2.1), y de toda la etapa final para construcción de compiladores de otros
lenguajes fuente sobre la misma plataforma.
• Se puede aplicar a la representación intermedia un optimizador de código
independiente de la máquina.
4
• Facilita la división en fases del proyecto: Permite abstraerse de los detalles propios de
la máquina destino en el desarrollo de la etapa inicial del compilador y de los propios
del lenguaje fuente en el desarrollo de la etapa final.
Fortran
Pascal
C
C++
Sparc
PowerPC
x86
ARM
Fortran
Pascal
C
C++
Sparc
PowerPC
x86
ARM
Representación
Intermedia
(a) (b)
Figura 2.1. Compiladores para 4 lenguajes y 4 máquinas sin (a) y con (b) utilización de un código intermedio.
Una buena representación intermedia debe cumplir las siguientes propiedades:
• Debe ser sencilla de generar y manipular.
• Debe ser adecuada para permitir su traducción al código máquina de todas las
máquinas-destino deseadas.
• Cada construcción debe tener un significado claro y simple que facilite la
implementación del módulo optimizador.
El código generado por un compilador de Java, conocido como bytecode, puede considerarse
como un ejemplo de código intermedio con la característica peculiar de que que posteriormente
es ejecutado en la máquina virtual.
1.1. Tipos de representaciones intermedias
Hay distintos tipos de representación intermedia. En el capítulo 10 de [Tremblay, 85] puede
encontrarse una explicación más extensa las formas de representación intermedias que se
presentan a continuación.
Notación postfija
Notación sencilla empleada en máquinas de pila donde un operador se coloca a continuación
de sus operandos. Por ejemplo, la instrucción de asignación x := a+b+(c*d) quedaría en notación
postfija como: x ab+cd*+ :=
Este tipo de representación intermedia es poco adecuada para la fase de optimización y es
difícil de emplear para representar estructuras de control de flujo e instrucciones de selección.
Árbol de sintaxis abstracta
Un árbol de sintaxis abstracta (“Abstract Sintax Tree” o AST) no es más que un árbol en el
que un nodo interior representa un operador, y donde sus operandos serán sus descendientes

5
directos. En la Fig. 2.2 se puede observar como queda un árbol de sintaxis abstracta para la
asignación x:= (a+b*c) / d.
Figura 2.2. Árbol de sintaxis abstracta para la instrucción x:= (a+b*c) / d.
Una variante de los árboles de sintaxis abstracta son los grafos dirigidos acíclicos (GDA). La
principal diferencia con los árboles de sintaxis abstracta es que en los primeros se permite que un
nodo tenga más de un padre. Este tipo de representación facilita el análisis del código y su
optimización, por lo que es muy empleada en compiladores optimizadores.
Código de tres direcciones (cuartetos)
Representación intermedia en la que las instrucciones constan de un operador y tres
direcciones: dos para los operandos y una tercera para el resultado. Las instrucciones tendrán la
forma genérica
<operador> <op1> <op2> <resultado>
Por ejemplo, la instrucción de asignación x := (a+b*c)/d se podría representar mediante una
secuencia de instrucciones en un código de tres direcciones como
Operador op1 op2 res
(1) MULT b c t1
(2) SUMA a t1 t2
(3) DIV t2 d t3
(4) ASIGNA t3 x
Un código de tres direcciones no es más que una representación lineal de un árbol de sintaxis
abstracta o de un GDA en el que se ha empleado una variable temporal para representar los
valores de los nodos interiores.
:=
x /
+ d
a *
b c
6
Código de dos direcciones (tercetos)
En un código de tres direcciones se suele emplear un gran número de variables auxiliares
(temporales) para almacenar los resultados parciales durante la evaluación de una expresión. Un
código de dos direcciones evita este problema permitiendo que los operandos que aparecen en
una instrucción sean apuntadores a las instrucciones cuyo resultado se desea emplear.
La forma general de una instrucción de dos direcciones es
<op> <operando1> <operando2>
El mismo ejemplo de instrucción de asignación que hemos vistos representada mediante un
código de tres direcciones, x := (a+b*c)/d se podría representar mediante un código de dos
direcciones como
Operador op1 op2
(1) MULT b c
(2) SUMA a (1)
(3) DIV (2) d
(4) ASIGNA (3) x
Donde (1), (2) y (3) representan punteros a las instrucciones de código dos direcciones 1, 2 3
respectivamente.
La principal ventaja del código de dos direcciones frente al de tres es el ahorro de variables
temporales.
1.2. Instrucciones del código de tres direcciones
Para este capítulo hemos escogido como representación intermedia un código de tres
direcciones. Se muestran a continuación los tipos de instrucciones de este código y la forma
general que tendrán. En la mayoría de los casos, los operadores podrán ser constantes,
direcciones de memoria donde se encuentra el valor a usar, o directamente direcciones de
memoria.
Asignación
x := y op z
Donde op es una operador aritmético.
x := op z
Siendo op un operador unario.
x := z
Salto incondicional

7
goto E
Donde E es la etiqueta (representada por un número) de la instrucción de código
intermedio a la que se saltará.
Salto condicional
if x op y goto E
Siendo op un operador lógico binario. Si se cumple la relación se saltará a la instrucción
etiquetada E.
Pila de activación
push x
Apila x en la pila de activación.
pop
Devuelve el valor que se desapila.
Llamada y retorno de subprograma
call E
Salta a la instrucción etiquetada E.
ret
Finaliza el subprograma y salta a la dirección que se encuentra en la cima de la pila de
activación.
Asignaciones relativas
a [i] := x
x quedará almacenada i posiciones más allá de la dirección base a.
x := a[i]
Asigna a x el valor de la posición que se encuentra i unidades más allá de la posición base
a.
Acceso a la pila de activación
Acceso en las instrucciones de asignación al “frame pointer” (FP) y al tope de la pila (TOP).
8
Generación de etiquetas
Los destinos de los saltos se indican mediante etiquetas. Al definir el código intermedio
podemos elegir entre dos formas de generar estas etiquetas:
Generación explícita de etiquetas: Cada vez que se desee poner una etiqueta a una
instrucción de código intermedio se debe crear y emitir una etiqueta que tendrá la forma:
<nombre_etiqueta> :
Esta forma es la usada habitualmente por los lenguajes ensambladores. En el ejercicio
8.20 se puede ver un ejemplo de utilización de este tipo de etiquetas.
Generación implícita de etiquetas: Podemos suponer que cada instrucción de código
intermedio generada tendrá implícitamente una etiqueta que se corresponderá con un
número entero. Este número se corresponde con el número de orden de la instrucción
dentro de programa. Esta forma es empleada en algunos lenguajes de alto nivel como
Basic, que comienza cada línea con un número que representa la etiqueta de la
instrucción.
El código intermedio que se emplea en este capítulo utiliza etiquetas implícitas.
1.3. Generación de código intermedio mediante una gramática de atributos
En temas anteriores se ha mostrado la utilización de las gramáticas atribuidas como
formalismo para la especificación semántica. En este tema se seguirán empleando las gramáticas
atribuidas, pero sus acciones generan código intermedio de tres direcciones. Para ello vamos a
emplear un procedimiento llamado emite que recibirá como parámetros una instrucción de
código intermedio y sus argumentos. Este procedimiento se encargará de almacenar
secuencialmente las instrucciones en una estructura intermedia (que podría ser un fichero o un
vector de instrucciones de código intermedio). De esta forma, como resultado colateral de la
evaluación de la gramática, en la estructura intermedia empleada por emite, tendremos toda la
secuencia de instrucciones de código intermedio generadas, las cuales forman el programa en
código intermedio equivalente al programa fuente. Este programa en código intermedio tendrá
todas sus instrucciones etiquetadas con un número entero: el número de instrucción que será
generado automáticamente por el procedimiento emite.
Las expresiones que aparezcan entrecomilladas en la llamada al procedimiento emite, se
tomarán literalmente, mientras que el resto de expresiones se evaluarán antes de generar la
instrucción de código intermedio.

9
Ejemplo 2.1.-
emite (x ‘:=’ 5 ‘+’ 9)
emite (x ‘:=’ 5 + 9)
La primera llamada al procedimiento emite generará la instrucción de código tres direcciones
correspondiente a la asignación en la posición x del resultado de sumar las constantes 5 y 9 (se
emite una instrucción de suma, es decir, la suma se realizará en tiempo de ejecución). En cambio
la segunda llamada al procedimiento emite generará una instrucción que almacenará en la
posición x el valor 14 (se emite una instrucción de asignación, la suma se ha realizado en tiempo
de compilación).
En las gramáticas atribuidas que construyamos para generar código intermedio utilizaremos
la siguiente notación:
id.nom: Atributo asociado el símbolo léxico identificador que representa su lexema (nombre).
Su valor es devuelto por el analizador léxico. Este nombre nos permitirá buscar la posición en la
tabla de símbolos (TDS) donde se encuentra la información del identificador.
id.pos: Atributo del símbolo léxico que representa la posición de memoria que contendrá
durante la ejecución el valor de la variable representada por el identificador. Se le asigna a la
variable cuando se declara, se almacena en la TDS y puede ser consultado mediante la función
BuscaPos(...). En un lenguaje con estructura de bloques esta posición suele estar representada
por el par (nivel, desplazamiento). Cuando otros símbolos de la gramática tengan un atributo con
el mismo (.pos) nombre tendrán el mismo significado.
id.tipo: Atributo que representará la expresión de tipo asignada al identificador. Está
almacenado en la TDS y se puede consultar mediante la función BuscaTipo(...). Cuando otros
símbolos de la gramática tengan un atributo con el mismo nombre tendrán el mismo significado.
num.val: Atributo asociado al símbolo léxico constante numérica (num) que representa su
valor. Es devuelto por el analizador léxico. Cuando otros símbolos de la gramática tengan un
atributo con el mismo nombre tendrán el mismo significado.
Para simplificar los esquemas de traducción dirigidos por la sintaxis, nos vamos a permitir
emplear en las acciones semánticas variables globales. Estas variables globales podrán ser
accedidas desde cualquier acción semántica, es decir, se corresponderán con variables globales
del código fuente del compilador desarrollado. Para distinguirlas, aparecerán siempre en
mayúsculas. Si en alguna acción semántica aparece una variable en minúsculas se tratará de una
variable local asociada al símbolo no-terminal del lado izquierdo de la producción en la que
aparece.
10
SIGINST: Variable global del compilador que estamos construyendo que representa el
número de la SIGuiente INSTrucción que se va a generar. Esta variable es inicializada a 0 y el
procedimiento emite se encarga de incrementarla automáticamente cada vez que se emite una
instrucción.
Dada la siguiente gramática que representa una instrucción de asignación de un lenguaje de
alto nivel similar a C
Asig ! id = E
E ! E + E
E ! id
podemos construir un esquema de traducción dirigido por la sintaxis (ETDS) que genere
código de tres direcciones para instrucciones de asignación usando el procedimiento emite:
Asig ! id = E { Asig.pos := BuscaPos ( id.nom ) ;
emite ( Asig.pos ‘:=’ E.pos ); }
E ! E1 + E2 { E.pos := CrearVarTemp() ;
emite ( E.pos ‘:=’ E1.pos ‘+’ E2.pos ) }
E ! id { E.pos := BuscaPos (id.nom ) }
Veamos cada una de las acciones semánticas asociadas a estas producciones.
Asig ! id = E { Asig.pos := BuscaPos ( id.nom )
;
emite ( Asig.pos ‘:=’ E.pos ) }
En el ETDS (esquema de traducción dirigido por la sintaxis) anterior se puede observar que
no aparecen acciones semánticas necesarias para realizar las comprobaciones semánticas. Esto es
debido a que este capítulo se centra únicamente en la generación de código intermedio.
Se puede observar como en la primera acción semántica se realiza una llamada a la función
BuscaPos. La función BuscaPos recibe como argumento el lexema (nombre) del identificador,
busca la entrada del identificador en la TDS y devuelve la posición de memoria que se ha
asignado a dicho identificador. Esta posición de memoria en un lenguaje con estructura de
bloques será habitualmente el nivel de anidamiento (o contexto) del identificador y su
desplazamiento relativo.
La siguiente acción semántica es una llamada al procedimiento emite. Éste emitirá una
instrucción en código de tres direcciones que asignará en la posición del identificador id el
contenido de la posición de memoria representada por E.pos. También se puede observar que la
acción semántica devuelve en el atributo sintetizado Asig.pos la posición de memoria donde

11
estará en tiempo de ejecución el valor de la variable id.nom. Esto se hace porque en C una
instrucción de asignación debe devolver el valor asignado a la variable del lado izquierdo de la
asignación. La utilidad de este atributo sintetizado se puede observar si añadimos a la gramática
anterior la producción
E ! Asig { E.pos :=Asig.pos }
donde se puede observar que una expresión puede ser una asignación.
La siguiente producción del ETDS es:
E ! E1 + E2 { E.pos := CrearVarTemp() ;
emite ( E.pos ‘:=’ E1.pos ‘+’ E2.pos ) }
La primera acción de esta producción realiza una llamada a la función CrearVarTemp(). Está
función devolverá la dirección de la primera posición de memoria libre (no asignada) dentro del
área de datos del bloque que se está compilando. En esa posición de memoria se almacenará el
valor de una variable temporal (de ahí el nombre de la función).
La segunda acción emite una instrucción de código de tres direcciones. Esta instrucción se
almacenará en la estructura intermedia empleada por emite para guardar el código intermedio.
Cuando en tiempo de ejecución se ejecute la instrucción, se asignará a la posición de memoria
representada por E.pos (la posición que devolvió CrearVarTemp) el resultado de sumar el
contenido de las posiciones de memoria representadas por E1.pos y E2.pos. Podemos observar
que E.pos es un atributo sintetizado que toma valor en esta producción mientras que E1.pos y
E2.pos son dos atributos sintetizados cuyo valor se usa en esta producción.
E ! id { E.pos := BuscaPos (id.nom ) }
La única acción semántica asociada a esta producción se encarga de dar al atributo E.pos la
posición de memoria asignada al identificador id. Para ello se realiza un llamada a la función
BuscaPos que recibe como argumento el lexema del identificador (id.nom), lo busca en la tabla
de símbolos y devuelve la posición de memoria que se le adjudicó en la fase de asignación de
memoria.
Ejemplo:
Veamos el comportamiento de este ETDS mediante la construcción del árbol anotado
correspondiente a la cadena a = b + c (Fig. 2.3). Suponemos que en la TDS tenemos la
información asociada a cada identificador que aparece en la Fig. 2.3.
12
TDS
Nom tipo posición [nivel, desp]
a tentero [0,24]
b tentero [0,26]
c tentero [0,28]
Figura 2.3. Árbol anotado y código
intermedio generado para la cadena
a=b+c.
Para que resulte más cómodo de leer el código intermedio, en lugar de poner las posiciones
de memoria, en el resto de este capítulo se utilizará el nombre de la variable a la que
corresponde. En el caso de las variables temporales, su nombre comenzará por la letra minúscula
t seguida de un número entero que indicará el orden en el que ha sido generada: t1, t2, … En la
Fig. 2.3 se puede observar como al llamar a la función CrearVarTemp(), ésta ha devuelto como
posición de memoria la primera posición libre dentro del área de datos del bloque para el que se
estaba generando código (nivel 0, desplazamiento 30). Como ésta es la primera variable temporal
que se crea se le ha dado el nombre t1. De esta forma el código generado anteriormente puede
representarse para mayor claridad como:
(1) t1 := b + c
(2) a := t1
Veamos a continuación como se puede extender el ETDS anterior para generar código
también para otras expresiones aritméticas sencillas.
Instruc
id.pos=[0,24] = E.pos = [0,30]
+ E.pos = [0,28]E.pos = [0,26]
id.pos=[0,26] id.pos=[0,28]
Código tres direcciones generado
(1) [0,30] := [0,26] + [0,28]
(2) [0,24] := [0,30]

13
E ! E1 * E2 { E.pos := CrearVarTemp() ;
emite ( E.pos ‘:=’ E1.pos ‘*’ E2.pos ) }
E ! num { E.pos := CrearVarTemp() ;
emite ( E.pos ‘:=’ num.val ) }
E ! ( E1 ) { E.pos := E1.pos }
E ! - E1 { E.pos := CrearVarTemp() ;
emite ( E.pos ‘:= -‘ E1.pos) }
Las acciones semánticas de la primera producción son semejantes a las que aparecían en la
producción que representaba la suma de expresiones, pero en este caso se genera una instrucción
de código intermedio de multiplicación. En la segunda producción podemos observar que cuando
la expresión es una constante numérica se ha decidido crear una variable temporal y generar una
instrucción de código intermedio que asigne en la posición de la variable temporal el valor de la
constante numérica (num.val) que proporciona el analizador léxico. Una opción más adecuada
habría sido que el no-terminal E devolviese el valor de la constante numérica, lo que habría
evitado la creación de una variable temporal. Sin embargo, esta segunda opción habría obligado
a que el no-terminal E, además del atributo .pos tuviese al menos otro atributo para devolver
valores constantes, lo que obligaría a añadir más acciones semánticas a todas las producciones
del no-terminal E. Para simplificar los esquemas de traducción hemos elegido la primera opción.
Hay que tener en cuenta que esta elección no afectará a la calidad del código finalmente
generado porque este tipo de variables temporales son fácilmente eliminadas durante la fase de
optimización de código intermedio.
En la tercera producción, una expresión (E) se reescribe como una expresión entre paréntesis
(E1). Puesto que el valor de una expresión entre paréntesis es el mismo de la expresión sin
paréntesis, basta con hacer que el atributo E.pos tome el mismo valor del atributo E1.pos. De esta
manera los dos atributos representan la misma posición de memoria (y por lo tanto el mismo
valor de la expresión).
Finalmente, en la última expresión observamos que E se reescribe como una expresión
cambiada de signo. Este caso es diferente del anterior, puesto que la expresión representada por
E no tomará el mismo valor que E1, por lo tanto es necesario utilizar una nueva posición de
memoria para almacenar el nuevo valor.
Ejercicio
Construye una gramática no-ambigua equivalente a la anterior. A continuación asocia a
cada producción las acciones semánticas necesarias para generar el código intermedio
correspondiente.
14
2. Acceso a miembros de una estructura y elementos de un
array
2.1. Acceso a miembros de una estructura
El acceso a los miembros de un estructura en C depende de la información que se almacene
en la TDS sobre la posición de los miembros. La forma habitual consiste en almacenar, junto a
cada miembro, su desplazamiento con respecto al comienzo del área de memoria asignada a esa
estructura (Fig. 2.4).
Ejemplo 2.2.- Dada la definición de las variables a y b de tipo estructura en el lenguaje C
struct ej {
int c1 ;
float c2 ;
}a, b;
La TDS quedaría:
TDS
nom tipo posición … ref
a testructura 0 , 124
b testructura 0 , 130
Figura 2.4. Asignación de memoria en la TDS para los miembros de una estructura.
De esta forma, en la entrada en la TDS de cada miembro de un tipo de estructura concreta se
almacenará el mismo desplazamiento independientemente de que hayan declaradas más de una
variable de ese tipo. Lo único que cambiará será la dirección base de cada variable de ese tipo de
estructura. Evidentemente antes de generar código intermedio para acceder a un miembro de una
estructura será necesario sumar a la dirección base de la variable estructura, el desplazamiento
asignado al miembro. En la Fig. 2.5 se muestra como quedaría un ETDS para acceder a los
miembros de una estructura de esta manera.
Se ha usado la función EsMiembro(id1.nom, id2.nom) que devolverá el valor TRUE si el
nombre id2.nom es un miembro de la estructura de nombre id1.nom. La función
BuscaPos(id1.nom) devuelve la posición de memoria base a partir de la cual se encontrarán en
tiempo de ejecución los miembros de la estructura id1.nom. La llamada a
BuscaPosMiembro(id1.nom, id2.nom) devolverá el desplazamiento relativo del miembro a partir
de la posición de memoria base de la estructura.
TALLA_REAL = 4
TALLA_ENTERO = 2
Tabla de miembros
nom tipo posición
c1 tinteger 0
c2 treal 2

15
Inst_simple ! id1 . id2 = E { si BuscaTipo (id1.nom) <> testructura ent MemError();
sino base := BuscaPos (id1.nom) ;
si no EsMiembro (id1.nom, id2.nom) ent MemError()
sino desp_miembro:=BuscaPosMiembro(id1.nom, id2.nom);
pos := base + desp_miembro ;
emite ( pos ‘:=’ E.pos ) }
Figura 2.5. ETDS Para el acceso a los miembros de una estructura.
2.2. Acceso a elementos de un array
En los lenguajes de alto nivel podemos ver que frecuentemente se permite definir arrays de
varias dimensiones (como en Pascal o C), con un límite inferior (Pascal) y superior (Pascal y C)
definido para cada una de las dimensiones. En cambio, en el código intermedio definido solo
disponemos de instrucciones de asignación con un modo de direccionamiento relativo: de
z:=a[x] (en la posición z se almacena el valor de la posición resultante de sumar a la
dirección base a el contenido de la posición x) y a[x]:=z. Esto obliga a realizar proceso de
traducción que requiere el cálculo de la posición de memoria que ocupará en tiempo de ejecución
cada elemento del array definido en el programa fuente.
2.2.1. Acceso a los elementos de un array multidimensional en Pascal
Una forma bastante frecuente y cómoda de almacenar las matrices consiste en almacenar
todos sus elementos en posiciones consecutivas de memoria. Con esta representación, cada vez
que nos encontremos en el lenguaje de alto nivel con una expresión donde aparezca un elemento
de una matriz, será necesario calcular el desplazamiento que hay que sumar a la dirección base
de la matriz para acceder al elemento indicado. Veamos como se realiza este cálculo en el caso
en el que se pueden definir límites inferiores y superiores (Pascal).
Si suponemos la declaración de una variable A de tipo vector (matriz de una dimensión) en
Pascal:
A: array [inf..sup] of integer ;
y se desea acceder al elemento A[i], éste se encontrará en la posición
base +(i - inf) * Talla
donde
base es la dirección base donde se encuentra el primer elemento del vector,
inf es el límite inferior de vector, y
16
Talla es el número deposiciones de memoria que ocupa cada elemento del vector
(dependiente del tipo de elementos que contiene el vector).
De igual forma, si se define una matriz de dos dimensiones:
A: array [inf1..sup1, inf2..sup2] of integer ;
la fórmula para acceder a un elemento A[i1,i2] sería:
base +((i1 – inf1) * n2 +(i2-inf2) ) *Talla
donde n2 es el número de elementos de la segunda dimensión de la matriz (n2 = sup2–
inf2+1)
que puede quedar como:
base +( (i1*n2 +i2) – (inf1*n2 + inf2) )*Talla
(inf1* n2+inf2) puede ser calculado en tiempo de compilación, y recibe el nombre de
desplazamiento inicial de la matriz. Este valor, puesto que no depende del elemento de la matriz
al que se quiera acceder, puede ser almacenado en la TDS. En cambio, (i1*n2+i2) tendrá que ser
calculado en tiempo de ejecución y por lo tanto habrá que generar código para realizar este
cálculo.
En general, dada la declaración de una matriz n-dimensional:
A: array [inf1..sup1, inf2..sup2, ... infn..supn] of integer ;
la fórmula para acceder a un elemento A[i1,i2,...in ] quedará como:
base +( (((i1*n2+i2)*n3+i3 …)*nn+in) – (((inf1*n2+inf2)*n3+inf3…)*nn+infn) ) * Talla
donde (((inf1*n2+inf2)*n3+inf3…)*nn+infn) es el desplazamiento inicial de la matriz.
Puesto que el acceso a un elemento de una matriz puede aparecer en el lado derecho o
izquierdo de una asignación, las producciones que definen la sintaxis de este acceso aparecerán
en dos lugares distintos de la gramática. Como el código generado para los dos casos es
prácticamente el mismo, se muestra únicamente uno de los casos (cuando el acceso al elemento
de la matriz aparece en el lado izquierdo de la asignación):
Inst_simple ! id [ Lista_indices ] := E
Lista_indices ! E Resto_LI
Resto_LI ! , E Resto_LI
| "

17
En la Fig. 2.6 se muestra un ETDS que genera código intermedio para el acceso a los
elementos de una matriz n-dimensional en Pascal.
Inst_simple -> id { Lista_indices.nom := id.nom }
[ Lista_indices ] := { temp := Lista_indices.pos ;
emite (temp := temp ‘–‘ Desp_inicial(id.nom)) ;
emite (temp := temp ‘*’ Talla (id.nom)) }
E { pos := BuscaPos (id.nom) ;
emite ( pos ‘[‘ temp ‘]’ := E.pos }
Lista_indices ! E { temp := CrearVarTemp()
emite (temp := E.pos); Resto_LI.ndim := 1;
Resto_LI.temp := temp ; Resto_LI.nom := Lista_indices.nom }
Resto_LI { Lista_indices.pos := Resto_LI.pos }
Resto_LI ! , E { Resto_LI.ndim := Resto_LI.ndim + 1;
emite (Resto_LI.temp :=
Resto_LI.temp‘*’Num_elementos(Resto_LI.nom, Resto_LI.ndim));
emite (Resto_LI.temp := Resto_LI.temp ‘+’ E.pos)
Resto_LI1.ndim := Resto_LI.ndim ;
Resto_LI1.temp := Resto_LI.temp ;
Resto_LI1.nom := Resto_LI.nom ; }
Resto_LI1 Resto_LI1{ Resto_LI.pos:= Resto_LI1 pos }
Resto_LI ! " { Resto_LI.pos:= Resto_LI.temp }
Figura 2.6. ETDS para el acceso a los elementos de un array en Pascal.
La función Desp_inicial(R_Inst_simple.nom) devuelve el desplazamiento inicial de la matriz
de nombre R_Inst_simple.nom que se guardó en la TDS cuando se declaró la matriz. De igual
forma, la función Talla(R_Inst_simple.nom), devuelve el tamaño de cada elemento de la matriz,
y Num_elemen(Lista_indices.nom,n_dim) devuelve el número de elementos de la dimensión
n_dim de la matriz Lista_indices.nom.
Ejemplo 2.3.- Veamos qué código generará este ETDS para el acceso a un elemento de una
matriz bidimensional que se define en el siguiente trozo de código fuente en Pascal:
var
...
A: array [2..11,1..20] of real ;
x,y: integer ; z: real;
begin
...
A[x,y] := z
...
18
TDS
nom tipo posición tipo_elem … desp_ini ref
A tarray 0, 140 treal 41
x tentero 0, 940 -
y tentero 0, 942 -
z treal 0, 944 -
Figura 2.7. Contenido de la TDS para el Ejemplo 2.3.
Suponiendo que el contenido en la TDS es el de la Fig. 2.7 se generará el siguiente código
intermedio:
(100) t1 := x
(101) t1 := t1 * 20
(102) t1 := t1 + y
(103) t1 := t1 – 41
(104) t1 := t1 * 4
(105) A [t1] := z
2.2.2. Acceso a los elementos de un array multidimensional en C
La generación de código intermedio para acceder a arrays multidimensionales en C es más
sencilla que la del caso de Pascal, ya que en C todos los arrays comienzan en la posición 0. Se
trata por lo tanto de un caso particular del visto para Pascal.
En general, dada la declaración de un array n-dimensional en C
int A[n1][n2]... [nn];
la fórmula para acceder al elemento A[i1][i2]...[in] quedaría como:
base +(((i1*n2+i2)*n3+i3 …)*nn+in) * Talla
donde ni es el número de elementos de la i-ésima dimensión.
Se puede construir un ETDS que genere código para el acceso a los elementos de una matriz
n-dimensional en Pascal tal y como aparece en la Fig. 2.8.
Tabla de arrays
n_dim lim_inf lim-sup
1 2 11
2 1 20
TALLA_REAL = 4
TALLA_ENTERO = 2 desp_ini = (inf1 * n2 + inf2) = 2*20+1 =
41

19
Inst_simple -> id { LI.nom := id.nom }
LI = E { emite (LI.pos := LI.pos ‘*’ Talla (id.nom)) ;
pos := BuscaPos (id.nom) ;
emite ( pos ‘[‘ LI.pos ‘]’ := E.pos ; }
LI ! [ E ] { LI.pos := CrearVarTemp() ;
emite (LI.pos := E.pos); LI.ndim := 1; }
LI ! { LI1.nom := LI.nom ; }
LI1 [ E ] Resto_LI1{ LI.ndim := LI1.ndim + 1; LI.pos := LI1.pos ;
emite (LI.pos := LI.pos ‘*’ Num_elementos(LI.nom, LI.ndim)) ;
emite (LI.pos := LI.pos ‘+’ E.pos) ; }
Figura 2.6. ETDS para el acceso a los elementos de un array en C.
3. Expresiones lógicas e instrucciones de control de flujo
En un lenguaje de alto nivel las expresiones de tipo lógico se emplean principalmente como
expresiones condicionales en instrucciones de control de flujo. Debido a esto hay una
dependencia elevada entre la forma de representar los valores de las expresiones lógicas y el
código que se debe generar para traducir las instrucciones de control de flujo. Por esta razón
vamos a ver en la misma sección la representación de los valores lógicos y la traducción de
instrucciones de control de flujo.
3.1. Variables y expresiones lógicas
Cualquier variable necesita una posición de memoria en la que, durante la ejecución del
código generado, se almacene su valor. Cuando se trata de una variable de tipo lógico o boolena,
para representar su valor también se necesita una posición de memoria (¡bastaría un bit!) para
almacenar su valor. Como el código intermedio definido en este capítulo no dispone del tipo
lógico ni el tipo bit, en la posición de memoria de una variable lógica se almacenará un entero
que representará su valor. Para esta representación numérica se empleará el mismo criterio
seguido en el lenguaje C1 de que un cero representa el valor de verdad “falso”, mientras que
cualquier valor distinto de cero representa el valor de verdad “cierto”.
Pero además de variables lógicas, en los lenguajes de alto nivel aparecen otro tipo de
expresiones lógicas, conteniendo comparaciones y/o conectivas lógicas. Para representar el valor
de una expresión lógica se pueden emplear dos métodos: la representación numérica y la
representación por control de flujo.
1 El tipo bool (lógico) no aparece en el lenguaje C hasta el estándar C99 (a través de <stdbool.h>) y no todos los
compiladores lo soportan. Por esta razón, las instrucciones de control de flujo en C utilizan expresiones enteras (0 es
falso y distinto de cero es cierto) para decidir el flujo.
20
En la representación numérica de una expresión lógica toda expresión lógica tendrá asignada
una posición de memoria donde se almacenará su valor de verdad: un entero igual a 0 para
“falso” o distinto de cero para “cierto”. Por el contrario, en la representación por control de flujo
no se emplea una posición de memoria para representar el valor de verdad de la expresión. Su
valor vendrá determinado implícitamente por la instrucción de código intermedio que se ejecute.
Tal y como se afirma en [AHOA90], ninguno de los dos métodos es siempre mejor que el otro.
En este apartado se muestran las dos formas de representación.
3.2. Representación numérica
En la representación numérica a cada expresión lógica se le asigna una posición de memoria
donde se almacena un valor numérico que indica el valor de verdad de la expresión. Si el código
intermedio permite emplear valores y operadores binarios bastaría con usar un 0 para representar
el valor falso y un 1 para el valor cierto. Si, como es nuestro caso, el código intermedio no
permite el empleo de valores binarios, se puede usar un número entero con un valor de cero para
representar el valor falso y un número distinto de cero para representar el valor cierto. Con esta
forma de representación, la evaluación de una expresión lógica se convierte en la evaluación de
una expresión aritmética.
En los siguientes ETDS se va a presentar una generación de código intermedio para el caso
en el que el lenguaje fuente permite la utilización de expresiones booleanas (como en Pascal) en
lugar de utilizar valores enteros (como en C). Como se ha comentado anteriormente, esto
obligará a realizar una traducción entre la representación del lenguaje fuente (booleanos) y la del
lenguaje intermedio (enteros).
Podemos escribir un ETDS para una sencilla gramática que genere expresiones lógicas
similares a las de Pascal tal y como aparece en el Fig. 2.8.
E ! true { E.pos:= CrearVarTemp() ;
emite( E.pos ‘:=’ 1 ) }
E ! false { E.pos:= CrearVarTemp() ;
emite( E.pos ‘:=’ 0 ) }
E ! ( E1 ) { E.pos := E1.pos }
E ! id { E.pos := BuscaPos(id.nom) }
Figura 2.8. ETDS representación numérica de expresiones lógicas.
Tal y como se puede apreciar en el ETDS anterior, cuando una expresión lógica sea la
constante TRUE o FALSE, basta con crear una nueva variable temporal y asignar en la posición
de memoria correspondiente un 1 o un 0 respectivamente. En el caso de que la expresión lógica
sea una variable (id), al igual que ocurría en el caso de las expresiones aritméticas, basta con que
el atributo E.pos tome el valor de la posición de memoria donde se almacena el valor de verdad
del identificador (devuelto por la función BuscaPos).

21
Para evaluar una expresión relacional, como a<5 hay que tener en cuenta que su valor de
verdad, en general, no se puede conocer en tiempo de compilación. Por esta razón es necesario
generar código de tres direcciones cuya ejecución produzca como resultado la evaluación de la
expresión relacional, asignando en la posición de memoria reservada para la expresión un valor 0
o distinto de cero según sea falsa o cierta la expresión, respectivamente.
Ejemplo
Para evaluar la expresión a<5, se puede generar la siguiente secuencia de código de tres
direcciones:
(1) t1 := 1
(2) if a < 5 goto 4
(3) t1 := 0
(4) ...
Tal y como fácilmente se puede comprobar, la ejecución del fragmento anterior de código de
tres direcciones produce como resultado que si a < 5 se almacenará un 1 en la posición de
memoria reservada para almacenar el valor de verdad de la expresión (en el ejemplo t1). En caso
contrario se almacenará un 0. El ETDS para generar la secuencia de código intermedio anterior
es
E ! E1 oprel E2 { E.pos := CrearVarTemp() ;
emite( E.pos ‘:=’ 1 ) ;
emite( ‘if’ E1.pos oprel.op E2.pos ‘goto’ SIGINST+ 2 ) ;
emite( E.pos ‘:=’ 0 ) }
En este ETDS puede verse la utilización del atributo oprel.op. Este atributo represente al
valor del operador relacional que aparece en el código fuente que se está compilando: “=”, “>”,
”>=”, “<”,… También se puede observar la aparición de una nueva variable global: SIGINST.
En el código intermedio de este tipo de expresiones se debe generar una instrucción de salto
condicional que se salte la instrucción que le sigue. Para generar esta instrucción se debe conocer
cuál es el número de la instrucción que se está generando. Con este fin, en el ETDS (y por lo
tanto en el código fuente del compilador desarrollado) existe un contador del número de
instrucciones de código intermedio generadas: SIGINST. Esta variable global del compilador es
actualizada de forma automática por el procedimiento emite cada vez que se genera una
instrucción. De esta forma, si en el momento de llamar al procedimiento emite para generar la
instrucción de salto condicional ‘if’ E1.pos oprel.op E2.pos ‘goto’ SIGINST+ 2, la variable
SIGINST vale 15, se generará la instrucción (15) if pos1 oprel pos2 goto 17.
Cuando la expresión lógica incluye operadores lógicos “and” y “or”, si el código intermedio
no dispone de estos operadores, como es nuestro caso, será necesario buscar una equivalencia
con los operadores disponibles en el código intermedio. En nuestro caso, podemos observar que
el operador lógico “and” puede implementarse como una operación de multiplicación entre
22
valores de verdad, y el operador “or” como una suma. De esta manera, podemos obtener el
ETDS:
E ! E1 or E2 { E.pos:= CrearVarTemp() ;
emite( E.pos ‘:=’ E1.pos ‘+’ E2.pos ) }
! E1 and E2 { E.pos:= CrearVarTemp() ;
emite( E.pos ‘:=’ E1.pos ‘*’ E2.pos ) }
Al generar código intermedio de esta manera hay que tener en cuenta que, cuando se realice
una operación “or” entre dos expresiones con el valor de verdad “cierto”, el resultado será otra
expresión con el valor “cierto” pero representado con un valor entero distinto de “1”. Esto
introduce un nuevo problema: En algún momento podría darse el caso de que el valor entero
sobrepase el rango válido de los enteros, apareciendo enteros negativos. Esto a su vez puede
provocar que una operación “or” entre dos expresiones ciertas representadas por valores enteros
iguales pero con signos distintos den como resultado el valor falso. Así por ejemplo, si
consideramos dos expresiones booleanas con el valor “cierto” pero representadas
respectivamente por los valores enteros “-5” y “5”, la operación “or” entre ellas (su suma) dará
como resultado “0” (valor “falso”). Esto es un error provocado por la forma en la que generamos
el código y por lo tanto debe corregirse. Una posible forma de corregir este problema consiste en
asegurarse de que un valor “cierto” siempre se representa por el entero “1”. Para ello
generaremos una instrucción que compruebe el valor entero después de la operación “or”. De
esta manera, el ETDS anterior quedaría:
emite( E.pos ‘:=’ E1.pos ‘+’ E2.pos )
emite( ‘if’ E.pos ‘<= 1’ goto’ SIGINST+2 ) ;
emite( E.pos ‘:= 1’)}
Para generar el código correspondiente al operador lógico “not”, si no está disponible en el
código intermedio, tal y como es nuestro caso, será necesario generar una secuencia de
instrucciones cuya ejecución produzcan el resultado equivalente. Así por ejemplo, para obtener
en la posición de memoria t1 el valor numérico de verdad de la expresión “not a” se puede
generar la secuencia de instrucciones de código intermedio:

23
(1) t1 := 0
(2) if a <> 0 goto 4
(3) t1 := 1
(4) ...
El ETDS correspondiente quedará como aparece en la Fig. 2.9.
emite( E.pos ‘:=’ E1.pos ‘+’ E2.pos )
emite( ‘if’ E.pos ‘<= 1’ goto’ SIGINST+2 ) ;
emite( E.pos ‘:= 1’)}
! E1 and E2 { E.pos:= CrearVarTemp() ;
emite( E.pos ‘:=’ E1.pos ‘*’ E2.pos ) }
! not E1 { E.pos:= CrearVarTemp() ;
emite( E.pos ‘:=’ 0 ) ;
emite( ‘if’ E1.pos ‘<> 0 goto’ SIGINST+2 ) ;
emite( E.pos ‘:=’ 1) }
Figura 2.9. ETDS operadores lógicos con representación numérica.
Para ver un ejemplo de la utilización de las expresiones lógicas en las instrucciones de
control de flujo, se va a construir un ETDS que genere código de tres direcciones para la
instrucción de do-while de C. Su sintaxis es
I ! do I1 while ( E )
El esquema del código a generar se puede representar tal y como aparece en la Fig. 2.10. El
bloque I1 representa todas las instrucciones que se han generado en las producciones del no-
terminal I para el cuerpo del bucle. De igual forma, el bloque E representa todo el código
intermedio emitido para la evaluación de la expresión E.
I1
E
if E.pos = 0 goto
Figura 2.10: Esquema de código para un do-while con representación numérica.
La ejecución del código intermedio generado para la evaluación de la expresión lógica dejará,
tal y como se ha visto, en una posición de memoria (E.pos) un valor 0 o distinto de 0 (1) según
sea falsa o cierta la expresión. El código que se genera para la instrucción do-while, saltará al
inicio del bucle si en esa posición hay un número igual a 0. El ETDS quedará por lo tanto
24
I ! do
I1
while ( E )
{ I.inicio := SIGINST }
{ emite( ‘if’ E.pos ‘<> 0 goto’ I.inicio) }
Se puede observar que se ha utilizado el atributo I.inicio para guardar el valor de la variable
global SIGINST justo antes de I1. Este atributo almacenará el número de la primera instrucción
de código intermedio generada en I1. Esta instrucción será el destino del salto condicional
generado para ejecutar una nueva iteración del bucle. Este ETDS emite únicamente una
instrucción, el salto que aparece al final del bucle, ya que las instrucciones del cuerpo del bucle
serán emitidas por las acciones semánticas de las producciones I y las correspondientes a la
evaluación de la expresión lógica por las del no-terminal E.
De forma semejante se puede intentar construir una gramática atribuida que genere código de
tres direcciones para una instrucción “while” de C:
I! while
( E )
I1
{ I.inicio:= SIGINST }
{ emite( ‘if’ E.pos ‘=0 goto’ I.fin ) }
{ emite( ‘goto’ I.inicio ) ;
I.fin := SIGINST }
Sin embargo, se puede observar que esta gramática no es L-atribuida. Esto es debido a que en
la acción semántica de generación de la instrucción de salto condicional { emite( ‘if’ E.pos‘=0
goto’ I.fin ) } aparece el atributo I.fin que toma su valor en una acción que aparece a la derecha
de la acción semántica del emite. Esto significa que si se realiza una traducción dirigida por la
sintaxis, en el momento en que se realiza la llamada a emite para generar la instrucción de salto
condicional, no se conoce todavía el valor del atributo I.fin que debería contener el número de la
primera instrucción de código intermedio generada después del bucle (se trata de un argumento
de la llamada a emite cuyo valor no se conoce). Este problema de tener que generar una
instrucción antes de conocer todos sus argumentos se resolverá en la sección dedicada a las
referencias no satisfechas.
3.3. Representación por control de flujo
En la representación por control de flujo se considera la representación de expresiones
lógicas dentro del contexto en el que más frecuentemente aparecen: las instrucciones de control
del flujo. En una instrucción de control de flujo el valor de la expresión lógica se utiliza para
decidir a qué bloque de código se debe saltar. El código generado para una expresión lógica
consistirá en la generación de una instrucción de salto para el caso en el que la expresión sea
cierta y otra para el caso en el que la instrucción sea falsa. Veamos un ejemplo de utilización de
esta representación en el contexto de un lenguaje de programación de alto nivel similar a Pascal.
El código generado para las constantes lógicas TRUE y FALSE quedaría:

25
E ! true { emite( ‘goto’ E.verdadero) }
E ! false { emite( ‘goto’ E.falso) }
donde E.verdadero y E.falso son etiquetas que representan el número de la instrucción a la
que hay que saltar cuando la expresión es cierta o falsa respectivamente.
Considerando una representación de los valores lógicos por control de flujo, un ETDS para la
instrucción repeat-until de Pascal podría ser:
I ! repeat
I1
until E
{ E.falso:= SIGINST }
{ E.verdadero := SIGINST) }
Se puede observar que en este ETDS no se ha generado ninguna instrucción. Únicamente ha
sido necesario dar un valor a los atributos E.falso y E.verdadero. L instrucción de salto que
provocará que se vuelva al principio del bucle si la expresión E se avalúa a falso se ha generado
en las producciones para el no-terminal E.
Desgraciadamente en el momento de generar el código para la expresión lógica no siempre se
conoce el valor de estas etiquetas. Este problema de tener que generar una instrucción antes de
conocer todos sus argumentos apareció también en la representación numérica y se resolverá en
la sección dedicada a las referencias no satisfechas.
4. Referencias no satisfechas. Relleno por retroceso
4.1. Planteamiento del problema
En la sección anterior se ha visto que frecuentemente se debe generar una instrucción de
código de la que no se conoce el valor de todos sus argumentos. Una primera aproximación para
solucionar este problema es realizar dos pasadas: En una primera pasada se generan las
instrucciones aunque algunas de ellas contengan referencias cuyo valor no se conoce todavía.
Tras esta pasada, en la que se han generado todas las instrucciones, se realiza una segunda
pasada en la que se van sustituyendo las referencias por sus valores.
Una alternativa que permite solucionar el problema de las referencias no-satisfechas sin tener
que realizar una segunda pasada es la conocida como relleno por retroceso. Básicamente esta
técnica consiste en la generación de cada instrucción aunque alguno de sus argumentos quede
incompleto. Cada vez que se genera una instrucción incompleta se guarda el número de la
instrucción incompleta en un atributo relacionado con al argumento cuyo valor no se conoce.
Cuando posteriormente, al seguir generando el resto de las instrucciones, se conozca el valor se
incorpora directamente a la instrucción que quedó incompleta, quedando de esta manera
completada.
26
4.2. Relleno por retroceso
Para realizar la implementación de esta técnica se pueden definir tres funciones con el
siguiente perfil:
ptro CreaLans(E): Crea una lista que solo contiene un número de instrucción E a rellenar
posteriormente. Devuelve un puntero a dicha lista.
ptro CompletaLans( ptro, E ): Rellena todas las instrucciones incompletas, cuyo número está
contenido en la lista apuntada por ptro, con el valor de argumento E.
ptro FusionaLans (ptro, ptro): Concatena las listas apuntadas por sus dos argumentos y
devuelve un puntero a la nueva lista.
Veamos mediante un ejemplo cómo pueden utilizarse estas funciones para implementar la
técnica de relleno por retroceso. Supongamos que en el momento de generar la instrucción de
salto incondicional de la línea 100 no se conoce cuál será el número de la instrucción destino de
este salto.
100 goto –
Se puede anotar en una lista, relacionada con el destino del salto, el número de la instrucción
generada que contiene este argumento no-satisfecho. Esto se hace mediante una llamada a la
función CreaLans(100). La lista ahora contendrá el número de la instrucción 100: lista={100}
Se continúa generando código y, si se genera otra instrucción de salto incompleta (por
ejemplo la número 103) cuyo destino sea el mismo, se añade a la lista asociada a ese destino el
número de la nueva instrucción incompleta: lista={100, 103}.
101 ...
102 ...
103 if a>0 goto ---
Continúa la generación de código intermedio y, en el momento en el que se conozca el valor
del argumento (por ejemplo el destino de los dos saltos podría ser la instrucción número 105), se
llama a la función CompletaLans(lista ,105) que se encargará de completar las instrucciones
100 y 103 con el valor 105. El código del ejemplo quedará por tanto:
100 goto 105
101 ...
102 ...
103 if a>0 goto 105
104 ...
105 ...
En la sección 3.1 se construyó un ETDS para la instrucción while de C suponiendo que se
utilizaba una representación numérica para las expresiones lógicas:

27
I! while
( E )
I1
{ emite( ‘if’ E.pos ‘=0 goto’ I.fin )
}
I.fin := SIGINST }
En este ETDS ya aparece el problema de tener que generar una instrucción de salto
condicional en la que no se conoce el número de la instrucción destino. Ahora se puede resolver
este problema usando relleno por retroceso. Justo antes de generar la instrucción de salto se crea
una lista en la que se guarda el número de la instrucción que contiene la referencia no-satisfecha:
CreaLans(SIGINST). Cuando finalmente se conozca el destino del salto (la instrucción que se
genere justo después de la última instrucción del bucle), se llamará a la función
CompletaLans(final, SIGINST) para completar la instrucción de salto condicional. El ETDS
quedará por tanto como aparece en la Fig. 2.11.
I! while
( E )
I1
{ Iinicio:= SIGINST }
{ I.final:= CreaLans(SIGINST) ;
emite( ‘if’ E.pos ‘=0 goto’ --- ) }
CompletaLans(I.final, SIGINST) }
Figura 2.11. ETDS while con relleno por retroceso (representación numérica de expresiones lógicas).
4.3 Representación numérica de expresiones lógicas (con relleno por retroceso)
Usando relleno por retroceso se puede resolver también el problema de argumentos no
satisfechos que aparece al intentar generar código para otras instrucciones de control de flujo en
C. Suponiendo que se emplea una representación numérica de las expresiones lógicas, se puede
generar código intermedio para una instrucción if-else de C mediante el siguiente ETDS:
I ! if E
I1 else
I2
{ I.falso:= CreaLans(SIGINST);
emite( ‘if’ E.pos ‘=0 goto’ --- ); }
{ I.fin := CreaLans( SIGINST) ;
emite( ‘goto’ --- ) ;
CompletaLans(I.falso, SIGINST) }
{ CompletaLans (I.fin, SIGINST) }
En este ETDS, además del salto al código del “else” para el caso en que la expresión sea falsa,
se emite un salto “emite( ‘goto’ --- )” que garantiza que, tras la ejecución del código de I1 no se
28
ejecuta siempre el del I2. Las dos instrucciones de salto se generan de forma incompleta (falta el
destino de los saltos) y se completan posteriormente con las llamadas a “CompletaLans(I.falso,
SIGINST)” para añadir el destino del salto a I2 y con “CompletaLans (I.fin, SIGINST)” para
completar el salto emitido después del código de I1.
De forma similar, podemos construir un ETDS que genere código intermedio para un bucle
for parecido al del lenguaje C:
I ! for ( I1 ;
E ;
I2 )
I
{ I.cond := SIGINST; }
{ I.fin := CreaLans (SIGINST);
emite( ‘if’ E.pos ‘=0 goto’ --- );
I.cuerpo := CreaLans (SIGINST);
I. incr := SIGINST ; }
{ emite(‘goto’ I.cond);
CompletaLans(I.cuerpo, SIGINST) ; }
{ emite(‘goto’ I.incr);
CompletaLans(I.fin, SIGINST) ;
}
4.4 Representación de expresiones lógicas por control de flujo (con relleno por retroceso)
Usando relleno por retroceso podemos resolver el problema que apareció en el ejemplo de la
representación de expresiones lógicas por control de flujo en Pascal. El ETDS para la evaluación
de la expresión lógica (solo para el caso de las constantes TRUE y FALSE) quedaría:
E ! True { E.listaverdad := CreaLans( SIGINST) ;
E.listafalso := nil }
emite( ‘goto’ --- ) }
E ! False { E.listafalso := CreaLans( SIGINST) ;
E.listaverdad := nil ;
Como se puede apreciar, en cada producción se emite una instrucción de salto que queda
incompleta, pero se guarda una referencia a la instrucción en la lista E.listaverdad (para TRUE) o
E.listafalso (para FALSE). Estas instrucciones de salto incompletas se completarán cuando se
conozca el destino del salto. Por ejemplo, el ETDS para un repeat-until de Pascal quedaría tal y
como aparece en la Fig. 2.12.

29
I! repeat
I1
until E
{ CompletaLans(E.listafalso, I.inicio);
CompletaLans(E.listaverdad, SIGINST) }
Figura 2.12. ETDS repeat-until con relleno por retroceso (representación expresiones lógicas por control de flujo).
El ETDS para un do-while de C sería muy parecido, ya que bastaría con intercambiar los
valores con los que se completan las listas de referencias no satisfechas .listaverdad y .listafalso:
I! do
I1
while (E)
{ inicio:= SIGINST }
{ CompletaLans(E.listaverdad, inicio);
CompletaLans(E.listafalso, SIGINST) }
Figura 2.13. ETDS do-while con relleno por retroceso (representación expresiones lógicas por control de flujo).
Siguiendo esta técnica se puede construir un ETDS que genere código intermedio para la
evaluación de expresiones lógicas e instrucciones de control de flujo empleando una
representación de los valores lógicos mediante control de flujo, solucionando el problema de las
referencias no-satisfechas mediante relleno por retroceso.
Hemos visto que en la representación de los valores lógicos mediante control de flujo se
generan instrucciones de salto de las que no se conoce a donde se debe saltar. Para solucionar
este problema, se genera la instrucción de salto sin especificar la dirección destino. Se anota el
número de la instrucción incompleta en una lista que se corresponde con el valor de verdad de la
expresión: E.lv para el valor verdadero y E.lf para el valor falso. De esta forma, E.lv (E.lf) será
una lista que contendrá los números de las instrucciones de código intermedio donde se ha
generado un salto a la dirección destino para el caso de que la expresión sea cierta (falsa).
Cuando se conozca la dirección destino correspondiente, se completarán las instrucciones
incompletas con el valor de la dirección. El ETDS para las expresiones lógicas empleando esta
técnica quedará tal y como se muestra en la Fig. 2.14.
E ! E1 or
E2
{ CompletaLans( E1.lf,SIGINST) ;
E.lv := FusionaLans( E1.lv, E2.lv ) ;
E.lf := E2.lf }
E ! E1 and
E2
{ CompletaLans( E1.lv, SIGINST) ;
E.lv := E2.lv ;
E.lf := FusionaLans( E1.lf,E2.lf ) }
E ! not E1 { E.lv := E1.lf ;
E.lf := E1.lv }
E ! ( E1 ) { E.lv := E1.lv ;
30
E.lf := E1.lf }
E ! E1 oprel E2 { E.lv := CreaLans( SIGINST) ;
emite( ‘if’ E1.pos oprel.op E2.pos ‘goto’ --- ) ;
E.lf := CreaLans( SIGINST ) ;
E ! True { E.lf := nil ;
E.lv := CreaLans( SIGINST) ;
E ! False { E.lv := nil ;
E.lf := CreaLans( SIGINST) ;
E ! id { si BuscaTipo( id.nom ) = tlógico
ent E.lf := CreaLans( SIGINST)
emite( ‘if’ id.pos ‘= 0 goto’ --- ) ;
E.lv := CreaLans( SIGINST) ;
Figura 2.14. ETDS expresiones lógicas con representación por control de flujo y relleno por retroceso.
4.4.1. Código en cortocircuito
Del ETDS de la Fig. 2.14 se puede destacar el tratamiento que han recibido los operadores
lógicos “and” y “or”. Para estos dos operadores se ha decidido generar código en la forma
conocida como “cortocircuito”. Esto supone que no siempre se avaluarán todos los componentes
de la expresión lógica: se finalizará la evaluación de la expresión tan pronto como se conozca su
valor de verdad. Así por ejemplo la evaluación de la expresión lógica
TRUE or (a<b) or (a=5)
no llegará hasta las dos últimas subexpresiones, puesto que al evaluar la primera
subexpresión (la constante TRUE) ya se conoce el valor lógico de toda la expresión.
El código intermedio que se genera realiza esta evaluación “en cortocircuito” porque las acciones
semánticas de la producción E ! E1 or E2 fusionan las listas de los atributos E1.lv y E2.lv. Lo
mismo se puede decir del operador “and”, solo que en este caso la evaluación de la expresión
lógica se interrumpirá en cuanto se evalúe una subexpresión cuyo valor sea FALSE.
4.4.2. Variables lógicas y representación por control de flujo
Teniendo en cuenta que una variable siempre debe tener almacenado su valor en una posición
de memoria, parece evidente que esto será también cierto para las variables lógicas. Por esta
razón es necesario utilizar una representación numérica para almacenar el valor de una variable
lógica. Si para representar los valores de expresiones lógicas también se utiliza una
representación numérica no habrá ningún problema, ya que en ambos casos se utiliza el mismo
tipo de representación. En cambio, si se desea realizar una asignación de una expresión lógica

31
cuya representación es por control de flujo a una variable lógica (cuya representación es
numérica), será necesario realizar una conversión. Para realizar esta conversión es necesario
generar código intermedio tal y como se muestra en el ETDS de la Fig. 2.15.
I ! id := E { id.pos := BuscaPos(id.nom) ;
si BuscaTipo( id.nom ) = tlógico
ent
CompletaLans( E.lf , SIGINST) ;
emite( id.pos ‘:= 0’ ) ;
emite( ‘goto’ SIGINST+ 2 ) ;
CompletaLans( E.lv, SIGINST) ;
emite ( id.pos ‘:= 1’ ) ;
sino
emite ( id.pos ‘:=’ E.pos ) }
Figura 2.15. ETDS asignación de valor a variable lógica.
4.4.3. Instrucciones de control de flujo
En el ETDS de la Fig. 2.15 puede apreciarse que el código emitido para evaluar las
expresiones lógicas contiene instrucciones de salto cuyo destino no se conoce en el momento de
emitirla (referencias no satisfechas). Por lo tanto, en las instrucciones de control de flujo será
necesario realizar el relleno de los argumentos no satisfechos. En el ETDS de la Fig. 2.16 se
emite código intermedio para tres instrucciones típicas de los lenguajes de programación de alto
nivel (en este caso Pascal) suponiendo que las expresiones lógicas se representan mediante
control de flujo. Obsérvese que en el ETDS se asume que el código intermedio generado para
evaluar las expresiones lógicas realiza la evaluación de éstas mediante “cortocircuito”.
I ! if E then
I1 else
I2
{ CompletaLans( E.lv, SIGINST) }
{ I. listaSig := CreaLans( SIGINST) ;
CompletaLans( E.lf, SIGINST) }
{ CompletaLans (I. listaSig, SIGINST) }
I ! while
E
do I1
{ I. inicio := SIGINST }
32
I ! for id := E1
to E2
do I1
{ id.pos := BuscaPos (id.nom) ;
emite( id.pos ‘:=’ E1.pos ) }
{ I. inicio := SIGINST ;
condic := CreaLans( SIGINST) ;
emite( ‘if’ id.pos ‘>’ E2.pos ‘goto’ -- ) }
{ emite( id.pos ‘:=’ id.pos ‘+’ 1 ) ;
emite( ‘goto’ I. inicio ) ;
CompletaLans (condic, SIGINST) }
Figura 2.16a. ETDS instrucciones de control de flujo del lenguaje Pascal con relleno por retroceso (expresiones
lógicas con representación por control de flujo).
Ejemplo 2.4.- Para entender un poco mejor como funciona el ETDS anterior, se puede
comparar el código que se generaría para la asignación x:= a<b or (c<d and e<f)
suponiendo que se utilice una representación por control de flujo o numérica para las expresiones
lógicas. En la Fig. 2.17. se muestra el árbol anotado para la instrucción cuando se emplea una
representación por control de flujo.
Instruc
id.pos=X := E
orE
oprel.op=<
(
E
id.pos=a id.pos=b E
)
E E
and
oprel.op
=<id.pos
=c id.pos
=d
oprel.op
=<id.pos
=e
id.pos
=f
.lv = {100,104}
.lf = {103,105}
.lv
= {100}
.lf = {101}
.lv = {104}
.lf =
{103,105}
.lv = {102}
.lf = {103}
.lv = {104}
.lf = {105}
.lv = {104}
.lf = {103,105}
Figura 2.17: Árbol anotado para la cadena x:=a<b or (c<d and e<f).

33
Repr. Numérica Repr. por control de flujo
100 t1 := 1 100 if a<b goto 108
101 if a<b goto 103 101 goto 102
102 t1 := 0 102 if c<d goto 104
103 t2 := 1 103 goto 106
104 if c<d goto 106 104 if e<f goto 108
105 t2 := 0 105 goto 106
106 t3 := 1 106 x := 0
107 if e<f goto 109 107 goto 109
108 t3 := 0 108 x := 1
109 t4 := t2 * t3 109
110 t5 := t1 + t4
111 x := t5
Ejemplo 2.5.- Veamos cuál sería el código intermedio generado para un bucle while-do de
Pascal, utilizando una representación por control de flujo para las expresiones lógicas
while a<b or (c<d and e<f) do a:=a+1
100 if a<b goto 106
101 goto 102
102 if c<d goto 104 E w
103 goto 110 h
104 if e<f goto 106 i
105 goto 110 l
106 t1 := 1 e
107 t2 := a + t1 I
108 a := t2
109 goto 100
110
El siguiente ETDS genera código para varias instrucciones de control del flujo en C
suponiendo una representación del valor de las expresiones lógicas por control de flujo y usando
relleno por retroceso para resolver el problema de los argumentos no satisfechos:
34
I ! if E
I1
else
I2
{ I. listaSig := CreaLans( SIGINST) ;
{ CompletaLans (I.listaSig, SIGINST) }
I ! while
( E )
I1
{ I.inicio := SIGINST }
I ! do
I1
while ( E )
{ CompletaLans(E.listaverdad, I.inicio);
CompletaLans(E.listafalso, SIGINST) }
Figura 2.16b. ETDS instrucciones de control de flujo del lenguaje C con relleno por retroceso (expresiones lógicas
con representación por control de flujo).
En [Aho 90] pueden encontrarse ETDS similares a los presentados en esta sección, en los que
se utiliza un atributo .siguiente asociado a un auxiliar S, para representar el número (o etiqueta)
de la instrucción siguiente a las generadas por el auxiliar S. Además, puede encontrarse en ese
tema cómo se genera código cuando el código intermedio permite la utilización de etiquetas
explícitas (similar a uno de los ejercicios que aparecen al final de este tema).
5. Subprogramas
En el capítulo anterior ya se vio con bastante detalle cuál sería la secuencia de carga y
descarga de un registro de activación para la llamada y finalización de un subprograma. En esta
sección se presentan los ETDS que especifican la generación del código intermedio que se
encarga de realizar la carga y descarga de un registro de activación (Pascal) y marco (C).
5.1. Registros de activación en Pascal.
5.1.1. Declaración
Cuando se genera código para la declaración de un subprograma es necesario generar el
código que realiza la parte de la secuencia del carga y descarga del registro de activación que
lleva a cabo el subprograma llamado. Se muestra a continuación como quedaría esta parte del
ETDS correspondiente a la declaración a una función en Pascal. Obsérvese como es necesario
utilizar relleno por retroceso para completar la instrucción de salto incondicional encargada de
saltar el posible código de subprogramas locales al subprograma que se está compilando.

35
La instrucción PUSH permite apilar el valor del display del nivel de anidamiento
correspondiente al subprograma que estamos compilando (PUSH Display[NIVEL]). Así mismo,
suponemos que el tope de la pila se encuentra almacenado en la posición (o registro) TOP.
Decl_Subprg ! function id (Param_Form):
Tipo;
Bloque ;
Decl_Subprg
{emite(‘push Display[‘NIVEL’]’);
emite(‘display[‘NIVEL’] := top’);
area_datos := CreaLans(SIGINST);
emite(‘incTop’ ---) ; }
{ CompletaLans (area_datos, DESP)
emite(‘top := Display[‘NIVEL’]’);
emite(‘pop Display[‘NIVEL’]’);
emite(‘ret’) }
Bloque ! Decl_Var
Decl_Subprg begin
Instrucciones end
{ inst := CreaLans(SIGINST);
emite(‘goto’ ----); }
{ CompletaLans(inst,SIGINST); }
Figura 2.18. ETDS carga/descarga de un registro de activación por el procedimiento llamado.
5.1.2. Llamada
Cuando se genera código para la llamada a un subprograma es necesario generar el código
que realiza la parte de la secuencia de carga y descarga de un registro de activación que lleva a
cabo el subprograma llamador. Se muestra a continuación como quedaría el ETDS
correspondiente al lenguaje Pascal. Obsérvese como se utiliza la instrucción INCTOP para
reservar espacio para el valor devuelto por la función, y la instrucción PUSH para apilar los
parámetros actuales. Posteriormente, durante la secuencia de descarga del registro de activación,
se utiliza una instrucción DECTOP para decrementar el valor del tope de la pila y de esta forma
desapilar los parámetros que se cargaron al realizar la llamada.
E ! id
( Param_Act )
{ E.pos := CreaVarTemp();
emite(‘incTop Talla_Tipo(id.nom)) }
{ emite(‘push’ <estado máquina>);
emite(‘call’ BuscaPos(id.nom)) ;
emite(‘pop’ <estado máquina>);
emite(‘decTop’ TallaParam(id.nom)) ;
emite(‘pop’ E.pos) }
Param_Act ! E { emite(‘push’ E.pos) }
Param_Act ! Param_Act , E { emite(‘push’ E.pos) }
Figura 2.19. ETDS carga/descarga de un registro de activación por el procedimiento llamador.
36
5.2. Marcos en C
5.2.1. Declaración
Se muestra a continuación como quedaría un ETDS correspondiente a la declaración a una
función en C. La instrucción “push FP” que se emite, permitirá en tiempo de ejecución apilar el
valor del “frame pointer” correspondiente al subprograma que se estará cargando.
Decl_Subprg ! Tipo id ( Param_Form )
Bloque ;
{ emite(‘push FP’);
emite(‘FP := TOP’);
area_datos := CreaLans(SIGINST);
emite(‘TOP := TOP + ---‘) ; }
{ CompletaLans (area_datos, DESP)
emite(‘TOP := FP’);
emite(‘FP := pop);
emite(‘ret’) }
Figura 2.18. ETDS carga/descarga de un frame en C realizado por la función llamada.
5.2.2. Llamada
Al igual que en Pascal, en C cuando se genera código para la llamada a una función es
necesario generar el código que realiza la parte de la secuencia de carga y descarga del frame de
la función llamada. La instrucción “top := top + Talla_Tipo(id.nom)” se emite para que al
ejecutarse reserve espacio para el valor devuelto por la función. De igual forma, la instrucción
“push” se emite para que en tiempo de ejecución apile los parámetros actuales. Durante la
secuencia de descarga del frame se utiliza decrementa el valor del tope de la pila para, de esta
forma, desapilar los parámetros que se cargaron al realizar la llamada.
E ! id
( Param_Act )
{ E.pos := CreaVarTemp();
emite(‘TOP := TOP +’ Talla_Tipo(id.nom)) }
{ emite(‘push’ <estado máquina>);
emite(‘call’ BuscaPos(id.nom)) ;
emite(‘pop’ <estado máquina>);
emite(‘TOP := TOP -’ TallaParam(id.nom)) ;
emite(‘pop’ E.pos) }
Param_Act ! E { emite(‘push’ E.pos) }
Param_Act ! Param_Act , E { emite(‘push’ E.pos) }
Figura 2.19. ETDS carga/descarga de un frame realizado por la función llamadora.

37
Bibliografía recomendada
En [Tremblay 85] se puede encontrar un tema dedicado a formas de representación de código
intermedio. El tema de generación de código intermedio que más coincide con el contenido de
este tema es el que aparece en [Aho 90].
[Aho 08] Aho, Alfred V.; Lam, Monica S.; Sethi, Ravi; Ullman, Jeffrey D. Compiladores:
Principios, técnicas y herramientas. Segunda edición Pearson/Addison-Wesley
Iberoamericana, 2008
[Tremblay 85] Tremblay, Jean-Paul; Sorenson, Paul G. The Theory and Practice of
Compiler Writing. McGraw-Hill, 1985
38
Ejercicios
*8.1.- La siguiente gramática genera bucles “for” muy parecidos a los de Pascal estándar pero
con algunos matices:
I ! for id := E to E S do I
| begin LI end
S ! step E
| "
LI ! I ; LI
| I
...
donde E es una expresión de tipo entero.
La opción “step E” que puede aparecer en la cabecera del bucle indica que la variable
contador (id) en vez de incrementarse en una unidad (como ocurre cuando no aparece la opción
(“step”), se incrementará en “E” unidades al final de cada iteración.
Construir un ETDS que incluya las acciones semánticas necesarias para la comprobación de
tipos y la generación de código intermedio. Deben emplearse listas de referencias no satisfechas
(relleno por retroceso) para el control de los saltos.
*8.2.- Dado el siguiente fragmento de una gramática que genera instrucciones de asignación con
sumas y multiplicaciones, donde las llaves “{ }” representan la clausura reflexivo-transitiva
(0 o más ocurrencias):
IS ! id := E
E ! T { + T }
T ! F { * F }
F ! num
| id
| ( E )
...
a) Construir un ETDS para la generación de código intermedio.
b) Partiendo del ETDS anterior, incluir en el analizador descendente recursivo asociado a la
gramática, las acciones necesarias para la generación de código intermedio.
NOTAS:
• No incluir comprobaciones de tipo.

39
• Emplear el juego de instrucciones de tres direcciones. (Ejemplo: “id.pos:=id.pos*5”)
• El analizador léxico devuelve para cada identificador su entrada en la TDS en la variable
“ind”, y para una constante numérica su valor en la variable global “num”.
• Se suponen definidas las siguientes funciones:
• CrearVarTemp(): Crea una variable temporal y devuelve su posición.
• BuscaPos(id.nom): Devuelve la posición de memoria asignada al identificador cuya
entrada en la TDS es id.nom.
• En la declaración de cada parámetro formal, deberá indicarse si el uso es por valor o
referencia.
*8.3.- Dada la siguiente gramática (inspirada en la proposición “switch” del C):
I ! switch ( E ) { L }
L ! case num : P ; L
L ! default : P ;
L ! "
...
P ! P ; P
P ! break
P ! I
P ! "
...
Donde:
a) Tanto “E” como la constante “num” deben ser enteras.
b) Si la constante de un “case” coincide con el valor de la expresión E, se deberá
comenzar a ejecutar todas las instrucciones asociadas a ese “case” y a los que le siguen.
La proposición “break” provoca una salida inmediata del “switch”. Las instrucciones
asociadas al “default” se ejecutarán siempre (excepto si se encontró antes una
instrucción “break”).
Construir un ETDS que realice las acciones semánticas necesarias para la generación de
código intermedio de tres direcciones.
*8.4.- Construir un Esquema de Traducción Dirigido por la Sintaxis que realice las
comprobaciones semánticas y genere código de tres direcciones para una gramática con las
siguientes reglas de producción.
40
S ! case E of L end
L ! num : S ; L
L ! "
...
Tanto las constantes de selección, como la expresión, deben ser de tipo entero.
*8.5.- Dada la siguiente gramática:
P ! D ; I .
D ! id : T # D ; D # "
T ! pila ( num ) de TS # TS
TS ! entero # real
I ! apilar ( id , E ) # id := E # I ; I # "
E ! desapilar ( id ) # cima ( id ) # id
Donde:
pila (num) de TS, representa la definición del tipo pila, con un máximo de num
elementos de tipo entero o real.
apilar (id, E), indica que se apila el valor de E en la pila id
desapilar (id), devuelve el elemento que desapila de la pila id
cima (id) devuelve el elemento que hay en la cima de la pila id (no lo desapila).
Construir un ETDS que realice las acciones semánticas necesarias para la comprobación de
tipos, la asignación de memoria y la generación de código tres direcciones teniendo en cuenta
que:
a) La talla de los enteros y reales es 1.
b) No se debe permitir la asignación de pilas.
c) No hay coerción de entero a real.
Se deben realizar las comprobaciones dinámicas para los controles de desborde de pila y pila
vacía.

41
*8.6.- Dada la siguiente gramática:
P ! D ; I .
D ! id : T | D ; D | "
T ! cadena ( num ) | TS
TS ! entero | real | caracter
...
I ! concatena ( id , id ) | id := E | I ; I | "
E ! longitud ( id ) | id
Donde:
cadena(num) representa la definición de un objeto de tipo “cadena de caracteres”
cuyo tamaño máximo viene dado por num.
concatena(id1, id2) concatena al final de la cadena id1 la cadena id2.
longitud(id) devuelve el tamaño de la cadena id.
Construir un ETDS que realice las acciones semánticas necesarias para la comprobación de
tipos, la asignación de memoria y la generación de código de tres direcciones teniendo en cuenta
que:
a) La talla de los enteros, reales y caracteres es 1, y no hay coerción entre tipos.
b) Se deben realizar las comprobaciones dinámicas para controlar que no se sobrepasa el
tamaño máximo permitido de una cadena.
c) No se deben permitir las asignaciones entre cadenas.
NOTA: Se recomienda implementar una cadena declarada de tamaño máximo num, como un
vector de num+1 elementos, donde el elemento 0 se puede usar para almacenar la longitud actual
de la cadena.
*8.7.- Incorporar a la gramática siguiente, las acciones semánticas necesarias para la
comprobación de tipos, la asignación de memoria y la generación de código intermedio (tres
direcciones):
S ! D S
D ! D ; D | id : T
T ! char | integer | string(num)
S ! S ; S | id := E
E ! F + F | id (num : num)
F ! id | /id/
NOTAS:
42
1) string(num) representa una cadena de caracteres de talla máxima num.
2) id(a:b) representa la subcadena de id comprendida entre a y b.
3) /id/ es la longitud de la cadena id.
4) Será necesario considerar explícitamente la talla actual de las cadenas.
*8.8.- Dado el siguiente fragmento de gramática.
I ! while E do I Rw
Rw ! except E do I
Construye un ETDS para la comprobación de tipos y emisión de código intermedio. La
sentencia “while-do” tiene el comportamiento estándar de Pascal, pero con un pequeño matiz:
La parte “except” permite indicar una instrucción alternativa a ejecutar en las iteraciones en
las que se cumple la condición booleana introducida por la palabra “except”. La expresión del
“except” se evalúa antes de entrar en el cuerpo del bucle.
Ejemplo:
a := 9 ;
while a < 15 do
begin a:= a +1; write(a) end => 10 11 12 13 15
except a=13 do a:= a+1;
*
8.9.- Escribe un ETDS que genere código intermedio para el siguiente fragmento de una
gramática independiente del contexto, correspondiente a un lenguaje de programación. La
semántica de la instrucción loop es la siguiente: Si la expresión “E” que sigue a loop es cierta
se ejecutan las instrucciones que siguen al then y preceden a exitloop, y la instrucción loop
finaliza, en caso contrario, se irán evaluando sucesivamente las expresiones que siguen al
elseif hasta que una sea cierta, en cuyo caso, se ejecutan las instrucciones que siguen a ese
then y el flujo del programa vuelve al principio de la instrucción loop. Si ninguna expresión
es cierta se ejecutan las instrucciones que siguen al else y se vuelve al principio de la
instrucción loop.
I ! loop E then I exitloop O
O ! elseif E then I O
O ! else I endloop
I ! I ; I
E ! E oprel E
El diagrama de flujo de la instrucción sería el de la figura.

43
*8.10.- Definir un ETDS que
realice la generación de código intermedio para la instrucción WHILE-DO, en la que se
permita la posibilidad de una instrucción EXITLOOP. La instrucción Exitloop supone la
salida inmediata del bucle. Para ello utilizar la sintaxis propia de Pascal.
*8.11.- Dada la siguiente gramática (inspirada en la proposición “for” del C), construir un ETDS
que realice las acciones semánticas necesarias para la comprobación de tipos y la generación
de código intermedio de tres direcciones usando una representación por control de flujo de
las expresiones boolenas.
I ! for ( I1 ; E ; I2 ) { P }
...
P ! I ; P
P ! I
...
Donde:
a) Tanto I1 como I2 son instrucciones, típicamente de asignación o llamadas a función. I1 se
ejecutará antes del bucle e I2 dentro del bucle después de las instrucciones asociadas a la
proposición P.
b) E debe ser una expresión booleana que determine la condición de finalización del bucle.
*8.12.- Construir un ETDS que realice la declaración, la comprobación estática de tipos y la
generación de código intermedio para la siguiente gramática:
E
E
E
E
I
I
I
I
True
False
False
False
False
True
True
True
I
...
salida
44
P ! D ; I .
D ! id : T | D ; D | !
T ! integer | set of [ num ]
E ! member ( E , id ) | num | id
...
I ! for-each id in id do I
Siendo:
set of [ num ] un tipo de datos que representa un conjunto cuyos elementos pueden ser {0, 1,
2, 3, . . . num}. Por ejemplo: “a: set of [5]” declara la variable a cuyo valor puede ser cualquier
subconjunto de {0, 1, 2, 3, 4, 5}.
member(E, id) una función que devuelve TRUE (ó 1) si el elemento E está en el conjunto id
(FALSE ó 0, en caso contrario).
for-each id1 in id2 do I una instrucción donde la variable entera “id1” toma todos los valores
que corresponden a la variable conjunto id2 . Además, la instrucción I se ejecutará para cada uno
de los valores de id1 cuando este valor pertenezca al conjunto id2. Por ejemplo:
a: set of [5];
.....
a := {1, 3, 5}
for-each n in a do print (n);
producirá como resultado: 1, 3, 5.
Nota.- Se recomienda representar las variables de tipo conjunto “set of [num]” como un
“num + 1” posiciones consecutivas de memoria. Donde cada posición de memoria representará
la pertenencia (1 ó 0) de un elemento al conjunto. Por ejemplo, la variable “a”, de"nida
anteriormente, se representaría por 6 posiciones de consecutivas memoria, que si contuviesen los
valores (1, 0, 1, 0, 0, 1) indicarían que el conjunto a contiene los elementos {0, 2, 5}.
8.13.- Dada la siguiente gramática, construir un ETDS que realice: las comprobaciones
semánticas y de tipo usuales en la instrucción FOR y la generación de código intermedio.
Utilizar listas de referencias no satisfechas para la gestión de las expresiones booleanas.
S ! for id := E R E do S
R ! to | downto
8.14.- Construir un ETDS que genere código intermedio para comprobar en tiempo de ejecución
que los índices de una matriz están dentro de los límites definidos en su declaración. Para la
generación de este código, se puede suponer la existencia de otros atributos necesarios, cuya
evaluación se realiza en otras producciones, siempre que se indique su carácter sintetizado o
heredado.

45
8.15.- Considérese la siguiente instrucción cuya semántica viene dada por el diagrama de flujo
que se adjunta. Diseñar el ETDS para la generación de código tres direcciones. Utilizar listas
de referencias no satisfechas (relleno con retroceso) para el control de los saltos.
S ! pseudowhile id , E’ until E” do S’ then S”
8.16.- Dada la siguiente gramática que representa registros en Pascal, construir un ETDS que
realice:
P ! D ; I
D ! D ; D | id : T
T ! integer | real | record LC end
LC ! id : T RLC
RLC ! ; LC | "
I ! L := E
L ! L . id | id
E ! E + E | L
a) Las comprobaciones semánticas de: Compatibilidad de tipos, los tipos de los campos de
un RECORD solo pueden ser de tipo simple y no se permite la asignación de registros.
b) El cálculo de las posiciones relativas de los objetos en memoria.
c) La generación de código intermedio para las expresiones e instrucciones.
d) Extender el ETDS para generar código intermedio para la asignación de registros.
e) Extender el ETDS para permitir registros con parte variante.
8.17.- La siguiente gramática representa expresiones en las que un operador (suma o producto)
actúa sobre una lista de operandos que se encuentran entre paréntesis junto al operador.
Además, alguno de estos operandos puede ser a su vez toda una expresión entre paréntesis.
S ! ( + P L ) | ( * P L )
P ! id | S
L ! P L | "
a) Escribir en PASCAL las rutinas del Análisis Sintáctico por Descenso Recursivo LL(1)
para esta gramática.
b) Introducir en el esquema anterior las acciones semánticas necesarias para la generación
de código tres direcciones.
id > E'
id > E''
S' S''
No
No
Si
Si
46
8.18.- Suponiendo que una matriz A[a1..b1,a2..b2,...an..bn] se representa en memoria por el
método de división en subtablas (tal y como se ilustra en la figura). En las subtablas de los
niveles 1..n-1 únicamente aparecen referencias (de talla 1) a los orígenes de las subtablas de
los niveles inmediatamente siguientes. Solo en las subtablas de nivel n se almacenarán los
elementos de la matriz.
a) Determinar la función de acceso para el elemento genérico A[i1,i2,...in].
b) Diseñar el ETDS para la generación del código intermedio correspondiente, para la
siguiente gramática.
S ! L := E
E ! L
L ! id
L ! I ]
I ! I , E
I ! id [ E
8.19.- Dada la siguiente gramática:
P! var D_V I
D_V ! D_V D_V | Lista_id : T ;
Lista_id ! Lista_id , id | id
T ! record ListaCampos Cvar end | T_simple
T_simple ! T_disc | integer | real
ListaCampos ! ListaCampos ; ListaCampos | id : T_simple
T_disc ! num..num | boolean
Cvar ! case id : T_disc of LCV | "
LCV ! LCV ; LCV | Val_sel : ( ListaCampos )
Val_sel ! num | id
I ! id := E | id . id := E | if E then I else I
E ! E oprel E | id . id | id
a) Dar un ETDS que realice el cálculo de las posiciones relativas de las variables en
memoria para esta gramática.
a1
b1
i1 i2
a2
b2
.
.
2
.
.
in-1
in
.
.
.
.
n-1
.
.
n
.
.
an
bn
A[i1,i2,..in]
1

47
b) Ampliar el anterior ETDS para que realice la comprobación de tipos y genere el código
intermedio necesario para evaluar las expresiones y realizar las asignaciones adecuadas en
dicha gramática.
NOTA: Diseñar la estructura de la tabla de símbolos que permita la realización de los
apartados anteriores. Igualmente, describir brevemente los atributos, así como los perfiles y
acciones realizadas por las funciones y/o procedimientos que utilicéis.
*8.20.- El código intermedio definido en este capítulo se modifica para permitir generar etiquetas
y utilizarlas como destino de los saltos (similares a las utilizadas en los lenguajes
ensambladores). Por ejemplo, podríamos generar secuencias de código intermedio similares a:
if e<f goto L1
goto L2
L2: a:= a-1
L1: a := a + 1
a) Construye un ETDS que genere este código intermedio para la evaluación de expresiones
lógicas (mediante representación por control de flujo) para la siguiente gramática:
E ! E or E | E and E | not E
| ( E ) | E oprel E
| true | false | id
b) Construye otro ETDS que genere código intermedio para las instrucciones representadas
por la siguiente gramática, que sea coherente con el ETDS del apartado anterior.
Instruc ! if E then Instruc else Instruc
| while E do Instruc
| for id := E to E do Instruc
| id := E /* de tipo lógico */
c) ¿Qué código generará tu ETDS para las siguientes cadenas?
x := a<b or (c<d and e<f)
while (not a) or (x < b and true) do x := x + 1
48
Soluciones a los ejercicios seleccionados
8.1.-
E1
id.pos := E1.pos
E2
if id > E2 goto
goto
(step) E
goto
I
goto
id := id +E
I ! for id := E1
to E2
S
do I
{ si E1.tipo <> tentero ent MemError()
id.pos:=BuscaPos(id.nom);
emite(id.pos ‘:=’ E1.pos) }
{ si E2.tipo <> tentero ent MemError()
fin:=CreaLans(SIGINST); comi:=SIGINST;
emite(‘if’ id.pos ‘>’ E2.pos ‘goto’ ---)
cont:=CreaLans(SIGINST);
emite(‘goto’ -- ); inc:=SIGINST; S.pos:=id.pos; }
{ emite(‘goto’ comi); CompletaLans(cont, SIGINST) }
{ emite(‘goto’ inc);
CompletaLans(fin, SIGINST) }
S ! step E { si E.tipo <> tentero ent MemError()
emite(S.pos ‘:=’ S.pos ‘+’ E.pos) }
S ! " { emite(S.pos ‘:=’ S.pos ‘+’ 1) }
8.2.-
a)
E ! T1
{ +
T2
}
{ E.pos:=CreaVarTemp(); emite (E.pos ’:=’ T1.pos) }
{ emite(E.pos ‘:=’ E.pos ‘+’ T2.pos ) }
T ! F1
{ *
F2
{ T.pos:=CreaVarTemp(); emite (T.pos ‘:=’ F1.pos) }
{ emite(T.pos ‘:=’ T.pos ‘*’ F2.pos ) }

49
}
F ! num { F.pos:=CrearVarTemp();
emite(F.pos ‘:=’ num.val) }
F ! id { F.pos:=BuscaPos(id.nom) }
F ! ( E ) { F.pos:=E.pos }
IS ! id := E { id.pos:=BuscaPos(id.nom);
emite(id.pos ‘:=’ E.pos) }
b)
Procedure E ( var E.pos );
var
T1.pos, T2.pos
begin
T(T1.pos); E.pos:=CrearVarTemp(); emite (E.pos`:=´T1.pos);
while sim=mas do
begin
obtsym;
T(T2.pos); emite(E.pos ‘:=’ E.pos ‘+’ T2pos);
end;
end; { procedure E }
Procedure T ( var T.pos );
var
F1.pos, F2.pos
begin
F(F1.pos); T.pos:=CrearVarTemp(); emite(T.pos `:=´F1.pos);
while sim=multi do
begin
obtsym;
F(F2.pos); emite(T.pos ‘:=’ T.pos ‘*’ F2.pos);
end;
end; { procedure T }
Procedure F ( var F.pos );
var
E.pos
begin
case sim of
num:
F.pos:=CrearVarTemp(); emite(F.pos:=num.val);
obtsym;
identificador:
F.pos:=BuscaPos(id.nom);
obtsym;
abrepar:
50
obtsym;
E(E.pos); F.pos:=E.pos;
empareja(cierrapar);
end; { case }
end; { prcedure F }
Procedure IS;
var
E.pos, id.pos
begin
id.pos:=BuscaPos(id.nom);
empareja(identificador);
empareja(asignación);
E(E.pos); emite(id.pos:=E.pos);
end; { procedure IS }
8.3.-
E
if E<>cte1 goto
P1
goto
P2
goto (break)
if E<>cte2
goto
goto
P (default)
...
En la solución propuesta se puede observar que se genera una instrucción “goto”
inmediatamente a continuación del cuerpo de un “case” cuya finalidad es saltar al cuerpo del
siguiente “case”. Con esto se consigue que si se cumple la igualdad de la constante de un
“case”, tras ejecutarse su cuerpo se ejecuten las instrucciones del cuerpo de todos los “case”
que le siguen (hasta que se encuentre un salto generado para un break).
I ! switch ( E )
{ L }
{ L.pos:=E.pos; L.anterior := nil; L.fin:=nil}
L ! case num :
P ;
{ sigcond:=CreaLans(SIGINST) ;
emite(‘if’ num.val ‘<>’ L.pos ‘goto’ --);
CompletaLans(L.anterior, SIGINST) }
{ L1.anterior:=CreaLans(SIGINST) ; emite (‘goto’ --);

51
L1
L1.pos:=L.pos; CompletaLans(sigcond, SIGINST);
L1.fin:=FusionaLans(P.fin, L.fin) }
L ! default :
P ;
{ CompletaLans(L.anterior, SIGINST) }
{ CompletaLans(L.fin, SIGINST);
CompletaLans(P.fin, SIGINST) }
L ! " { CompletaLans(L.anterior, SIGINST)
CompletaLans(L.fin, SIGINST);}
P ! P1 ; P2 { P.fin:=FusionaLans(P1.fin,P2.fin) }
P ! break { P.fin:=CreaLans(SIGINST); emite(‘goto’ --) }
P ! I { P.fin:=I.fin }
P ! " { P.fin:=nil }
8.4.-
E
if E.pos<>cte.val goto
S
goto
S
if E.pos<>... goto
goto
...
L ! num :
S ;
L1
{ si num.tipo $ tentero ent MemError() ;
sig:=CreaLans(SIGINST);
emite(‘if’ num.val ‘<>’ L.pos ‘goto’ --) }
{ falsa:=CreaLans(SIGINST);
emite(‘goto’ --);
CompletaLans(sig, SIGINST);
L1.pos:=L.pos }
{ L.fin:=FusionaLans(falsa, L1.fin) }
L ! " { L.fin:=nil }
S ! case E
of L
{ si E.tipo $ tentero ent MemError();
L.pos:=E.pos }
{ CompletaLans(L.fin, SIGINST) }
8.5.-
52
Es importante observar que en tiempo de compilación no conocemos el tamaño de la pila,
solo conocemos el tamaño máximo de la pila. Por lo tanto, será necesario reservar una
posición de memoria para que en tiempo de ejecución se almacene allí el tope de la pila.
Podemos implementar la pila de ‘num’ elementos como un vector (array) de ‘num+1’
elementos, donde el elemento 0 se puede usar para almacenar el tamaño actual (tope) de la
pila. Cada vez que apilemos un nuevo elemento, lo haremos sobre la posición indicada en
pila[0] (dirección base del vector). A continuación incrementaremos el valor de pila[0]. De
esta forma, las acciones semánticas para generar código para apilar, desapilar, y obtener la
cima podrían ser:
I ! apilar ( id ,
E )
{ pos := BuscaPos (id.nom) ;
emite ( pos ‘:=’ pos ‘+’ 1 );
emite (‘if’ pos ‘<=’ limite ‘goto’ SIGINST +2 )
emite (‘fin’) }
{ emite ( pos ’[‘ pos ’] :=’ E.pos) }
E ! desapilar (id) { pos := BuscaPos (id.nom) ;
emite (‘if’ pos ‘>’ 0 ‘goto’ SIGINST + 2 ) ;
emite (‘fin’) ;
E.pos := CrearVarTemp() ;
emite ( E.pos ‘:=’ pos ’[‘ pos ’]’ );
emite (pos‘:=‘ pos ‘-‘ 1) }
E ! cima (id) { pos := BuscaPos (id.nom) ;
emite (‘if’ pos ‘> 0 goto’ SIGINST +2 );
emite (‘fin’)
E.pos := CrearVarTemp();
emite (E.pos ‘:=’ pos ’[‘ pos ’]’ ) }
En el ETDS anterior hemos se puede ver que pos[0] y pos hacen referencia al mismo
valor, ya que es lo mismo tomar el contenido de la dirección base del vector (pos) o el
contenido de la dirección resultante de sumar a la base del vector un desplazamiento cero
(pos[0]) .
El ETDS, incluyendo algunas comprobaciones de tipo quedará finalmente:
P !
D ; I .
{ DESP:=0 }
D ! id : T { InsertarTDS (id.nom, T.tipo, DESP);
DESP := DESP + T.talla ;
si T.tipo = Tpila(limite,tipo) ent emite (DESP ‘:=’ 0) }
D ! D ; D
D ! "
T ! pila ( num ) de { si num.val <=0 ent T.tipo := terror

53
TS sino T.tipo:= tpila (num.val, TS.tipo) ;
T.talla := TS.Talla * (num.val +1) }
T ! TS { T.talla := TS.talla ; T.tipo := TS.tipo }
TS ! entero { T.talla := 1 ; T.tipo := tentero }
TS ! real { T.talla := 1 ; T.tipo := treal }
I ! apilar ( id , E ) { si BuscaTipo (id.nom) <> tpila (limite,tipo) ent I.tipo := terror
sino pos := BuscaPos (id.nom) ;
emite ( pos ‘:=’ pos ‘+’ 1 );
emite (‘if’ pos ‘<=’ limite ‘goto’ SIGINST + 2 )
emite (‘fin’)
si E.tipo <> tipo ent I.tipo := terror
sino emite ( pos’[‘ pos ‘] :=’ E.pos)
I.tipo := tvacío }
I ! id := E { id.tipo := BuscaTipo (id.nom) ;
si id.tipo = tpila (limite, tipo) ent I.tipo := terror
sino id.pos = BuscaPos (id.nom) ;
si id.tipo <> E.tipo ent I.tipo := terror
sino emite (id.pos ‘:=’ E.pos) ;
I.tipo := tvacio }
I ! I ; I
I ! "
E ! desapilar ( id ) { si BuscaTipo (id.nom) <> tpila (limite, tipo ) ent E.tipo := terror
emite (‘if’ pos ‘> 0 goto’ SIGINST + 2 ) ;
emite (‘fin’) ;
E.pos := CrearVarTemp() ;
emite ( E.pos ‘:=’ pos ’[‘ pos ’]’ );
emite ( pos ‘:=’ pos ‘-‘ 1 ) ;
E.tipo := tipo }
E ! cima ( id ) { si BuscaTipo (id.nom) <> tpila (limite, tipo) ent E.tipo := terror
E.pos := CrearVarTemp();
emite (E.pos ‘:=’ pos ’[‘ pos ’]’ );
E.tipo := tipo }
E ! id { E.tipo := BuscaTipo (id.nom) ; E.pos := BuscaPos (id.nom) }
54
8.6.-
P ! { DESP:=0 } D ; I .
D ! id : T
| D ; D
| "
{ InsertaTDS(id.nom, T.tipo, DESP) ; DESP:=DESP+T.talla }
T ! cadena ( num )
| TS
{ T.tipo:=tcadena(num.val) ; T.talla:=num.val }
{ T.tipo:=TS.tipo ; T.talla:=TS.talla }
TS ! entero
| real
| caracter
{ TS.tipo:=tentero ; TS.talla:=1 }
{ TS.tipo:=treal ; TS.talla:=1 }
{ TS.tipo:=char ; TS.talla:=1 }
I ! concatena ( id1 , id2)
| id := E
| I ; I
| "
{ id1.pos:=BuscaPos(id1.nom); id2.pos:=BuscaPos(id2.nom);
si BuscaTipo(id1.nom)=BuscaTipo(id2.nom)=tcadena
ent
I.tipo:=tvacío;
t1:=CrearVarTemp();
emite ( t1 ‘:=’ 1);
inicio:=SIGINST;
listaFin:=CreaLans(SIGINST);
emite ( ‘if’ t1 ‘>’ id2.pos ‘goto’ -- );
emite ( id1.pos ‘:=’ id1.pos ‘+’ 1 );
emite (‘if’ id1.pos’<=’Talla(id1.nom) ‘goto’ SIGINST+2 );
emite ( ‘fin’ );
emite ( id1.pos ’[‘ id1.pos ’]:=‘ id2.pos ’[‘ t1 ’]’ );
emite ( t1 ’:=’ t1 ’+’ 1 );
emite ( ‘goto’ inicio );
CompletaLans ( listaFin, SIGINST );
sino I.tipo:=terror; }
{ si (BuscaTipo(id.nom):=E.tipo) $ tcadena $terror
ent emite( BuscaPos(id.nom) ‘:=’ E.pos );
I.tipo:=tvacío;
sino I.tipo:=terror; }
E ! longitud ( id )
| id
{ si BuscaTipo(id.nom) $ tcadena ent E.tipo:=terror;
sino E.tipo:=tentero;
E.pos:=BuscaPos(id.nom); }
{ E.tipo:=BuscaTipo(id.nom); E.pos:=BuscaPos(id.nom); }
Se puede observar que en lugar de usar la técnica de relleno por retroceso con:
listaFin:=CreaLans(SIGINST);

55
emite ( ‘if’ t1 ‘>’ id2.pos ‘goto’ -- );
en este caso podíamos haber contado las instrucciones que separaban la instrucción de salto y su
destino, y haber emitido directamente la instrucción
emite ( ‘if’ t1 ‘>’ id2.pos ‘goto’ SIGINST +7 ) */
8.7.-
Las comprobaciones de tipo serán las típicas del bloque de declaraciones. Para asignar
memoria basta con emplear una variable global que se incremente (según la talla del elemento
definido) cada vez que se declare una variable. En el caso de una cadena de caracteres
(tcadena), la talla nos viene determinada por el valor de la constante num (más uno por la
razón que se explica más adelante).
Respecto a la generación de código intermedio, se trata de un ejercicio muy parecido a los
dos anteriores. De forma parecida a como ocurría en ellos, en tiempo de compilación solo
conocemos el tamaño máximo de la cadena, pero no su tamaño real en un instante dado de la
ejecución. Una solución consistiría en reservar la primera posición de la cadena para que en
tiempo de ejecución se almacene su tamaño. En este caso, cada vez que realicemos una
asignación de cadenas, será necesario calcular el tamaño de la cadena resultado. Con este fin,
se puede observar que la instrucción para obtener una subcadena: id(num1:num2) nos
devuelve una cadena de tamaño num2 .val - num1.val +1.
8.8.-
El esquema del código que queremos generar será:
E
I1
goto
goto
.v
.f
E (RW)
.v
.f
I (RW)
El ETDS pedido quedaría:
I ! while
E do
I1
RW
{ RW.inicio := SIGINST }
{ si E.tipo <> tlógico ent MemError() ;
RW.cuerpo := SIGINST }
{ emite (‘goto’ RW.inicio) ;
CompletaLans (E.lv , SIGINST) }
{ CompletaLans (E.lf, SIGINST) }
56
RW ! except E
do I
{ si E.tipo <> tlógico ent MemError() ;
CompletaLans (E.lv, SIGINST) ;
CompletaLans (E.lf, RW.cuerpo) }
{ emite (‘goto’ RW.inicio) }
8.9.-
Solución usando representación por control de flujo para las expresiones lógicas.
I ! loop
E then
I exitloop
O
{ O.inicio := SI; }
{ CompletaLans(E.lv, SI); }
{ fin:= CreaLans(SI); emite (‘goto’ -); CompletaLans(E.lf, SI);}
{ CompletaLans(fin, SI); }
O ! elseif E
then I
O1
{ CompletaLans(E.lv, SI); }
{ emite(‘goto’ O.inicio) ; CompletaLans(E.lf, SI);
O1. inicio := O.inicio ;}
O ! else I endloop { emite(‘goto’ O.inicio) ;}
I ! I ; I
E ! E oprel E { E.lv := CreaLans( SI) ;
emite( ‘if’ E1.pos oprel.op E2.pos ‘goto’ --- ) ;
E.lf := CreaLans( SI ) ;
8.10.-
Vamos a usar la gramática que se muestra a continuación, donde I representa una instrucción,
y E una expresión. El no-terminal I tendrá más producciones, pero las que nos interesan son
las relacionadas directamente con la generación de código intermedio para las instrucciones
‘while-do’ y ‘Exitloop’.
I ! while E do I
I ! Exitloop
I ! I ; I
I ! …
Usaremos listas de referencias no satisfechas (relleno por retroceso) para el control de los
saltos. El no-terminal E, que representa la expresión lógica, tendrá asociados dos atributos:
E.lv y E.lf que representan respectivamente las listas de referencias no satisfechas de saltos
para cuando la expresión es cierta (E.lv) y para cuando es falsa (E.lf).

57
SIGINST, es una variable global que contiene la etiqueta de la siguiente instrucción de
código intermedio que se va a generar.
I ! while
E
do I1
{ inicio := SIGINST }
{ CompletaLans (E.lv, SIGINST) }
{ emite (‘goto’ inicio)
CompletaLans (I1.salida, SIGINST) ;
CompletaLans (E.lf, SIGINST) ;
I.salida := nil }
I ! Exitloop { I.salida := CreaLans (SIGINST) ;
emite (‘goto’ ---) }
I ! I1 ; I2 { I.salida:= FusionaLans (I1.salida, I2.salida) ; }
8.11.-
El esquema del código intermedio que queremos generar es el siguiente:
I1
E
I2
goto
P
goto
.v
.f
El ETDS por tanto quedaría:
I ! for ( I1 ;
E ;
I2 )
{ P }
{ inicio:=SIGINST; }
{ si E.t $ tlógico ent MenError()
sino incr:=SIGINST; }
{ emite(‘goto’ inicio);
CompletaLans(E.lv, SIGINST) }
{ emite(‘goto’ incr);
CompletaLans(E.lf, SIGINST) }
58
8.12.-
P ! D ; I .
D ! id : T { insertaTDS( id.nom, T.tipo) }
| D ; D
| "
T ! set of [ num ] { T.tipo := conjunto(num.val) }
| integer { T.tipo := entero }
E ! member ( E1 , id ) { si (E1.tipo <> entero) or (BuscaTipo(id.nom) <> conjunto(n))
ent error;
E.tipo := lógico;
E.pos := CreaVarTemp;
emite( E.pos := id.pos[E1.pos]) }
| num { E.tipo := entero;
E.pos:= CreaVarTemp;
emite(E.pos:= num.val) }
| id { E.tipo := BuscaTipo(id.nom)
E.pos := BuscaPos(id.nom) }
I! for_each id1 in id2
do I
for_each id1 in id2
{ si (BuscaTipo(id1.nom)<> entero)
or (BuscaTipo(id2.nom) <> conjunto(n))
ent error;
t1 := CreaVarTemp;
emite (id1.pos := 0);
fin := Crealans(si);
inicio := si;
emite( if id1.pos > buscalimite(id2.nom) goto __);
emite (t1 := id2.pos[id1.pos]);
salta := Crealans(si);
emite( if t1 = 0 goto __); }
{ completalans(salta, si);
emite( id1.pos := id1.pos + 1);
emite( goto (inicio));
completalans(fin, si); }

59
8.20.-
a) Usaremos la función CreaEtiqueta par crear una etiqueta. Para generar mediante el
procedimiento emite una etiqueta bastará con realizar una llamada del tipo:
emite (<NombreEtiqueta> ‘:’)
Se puede observar la similitud de este ETDS con el construido usando relleno por retroceso
para la misma gramática:
- Las instrucciones generadas, excepto los destinos de los saltos que en este ETDS son
etiquetas, son las mismas.
- Donde se emite una etiqueta que anteriormente se usó como destino de un salto, en el
ETDS mediante relleno por retroceso aparecía un completaLans.
El ETDS para las expresiones lógicas quedaría:
E !
E1 or
E2
{ E1.f := CreaEtiqueta(); E1.v := E.v }
{ emite( E1.f ‘:’);
E2.v := E.v; E2.f := E.f }
|
E1 and
E2
{ E1.v := CreaEtiqueta(); E1.f := E.f }
{ emite( E1.v ‘:’);
E2.v := E.v; E2.f := E.f }
| not E1 { E1.v := E.f ;
E1.f := E.v }
| ( E1 ) { E1.v := E.v ;
E1.f := E.f }
| E1 oprel E2 { emite( ‘if’ E1.pos oprel.op E2.pos ‘goto’ E.v );
emite( ‘goto’ E.f ) }
| True { emite( ‘goto’ E.v ) }
| False { emite( ‘goto’ E.f ) }
| id { emite( ‘if’ id.pos ‘= 0 goto’ E.f ) ;
emite( ‘goto’ E.v ) }
Instruc ! id :=
E
{ E.v := CreaEtiqueta(); E.f := CreaEtiqueta()
fin := CreaEtiqueta() }
{ emite( E.f ‘:’) ;
emite( id.pos ‘:= 0’ ) ,
emite( ‘goto’ SIGINST + 2 ) ,
emite( E.v ‘:’);
emite ( id.pos ‘:= 1’ ) ; emite( fin ‘:’ ) }
60
b)
Instruc !
if E then
Instruc1 else
Instruc2
{ E.v:= CreaEtiqueta(); E.f:= CreaEtiqueta(); fin:= CreaEtiqueta() }
{ emite( E.v ‘:’ ) }
{ emite( ‘goto’ fin ) ; emite( E.f ‘:’) }
{ emite( fin ‘:’) }
| while
E
do Instruc1
{ Inicio := CreaEtiqueta() ; E.t := CreaEtiqueta() ;
E.f := CreaEtiqueta() ; emite(inicio ‘:’) ’:’ }
{ emite( E.v ‘:’) }
{ emite( ‘goto’ inicio ) ;
emite( E.f ‘:’) }
| for id := E1
to E2
do Instruc1
{ id.pos := BuscaPos (id.pos) ;
emite( id.pos := E1.pos ) }
{ inicio := CreaEtiqueta() ;
fin := CreaEtiqueta() ;
emite( inicio ‘:’) ;
emite( ‘if’ id.pos ‘>’ E2.pos ‘goto’ fin ) }
{ emite( id.pos ‘:=’ id.pos ‘+’ 1 ) ;
emite( ‘goto’ inicio ) ;
emite( fin ‘:’) }
c) x := a<b or (c<d and e<f)
if a<b goto L1
goto L3
L3: if c<d goto L4
goto L2
L4: if e<f goto L1
goto L2
L2: x := 0
goto L5
L1: x := 1
L5:
L0: if a<b goto L1
goto L3
L3: if c<d goto L4 E w
goto L2 h
L4: if e<f goto L1 i
goto L2 l
L1: t1 := 1 I e
t2 := a + t1
a := t3
goto L0
L2:

61
while (not a) or (x < b and true) do x := x + 1
L0: if a = 0 goto L1
goto L3
L3: if c<d goto L4 E w
goto L2 h
L4: goto L1 i
L1: t1 := 1 I l
t2 := a + t1 e
a := t3
goto L0
L2:

Apuntes t8

Más contenido relacionado

La actualidad más candente

Similar a Apuntes t8

Apuntes t8