Lenguaje de descripción del compilador

El lenguaje de descripción del compilador (CDL) es un lenguaje de programación basado en gramáticas de afijos . Es muy similar a la notación de la forma Backus–Naur (BNF). Fue diseñado para el desarrollo de compiladores . Tiene muchas limitaciones en sus capacidades y flujo de control, y esto es intencional. Los beneficios de estas limitaciones son dobles.

Por un lado, hacen posible el sofisticado análisis de flujo de datos y control utilizado por los optimizadores CDL2, lo que da como resultado un código extremadamente eficiente. El otro beneficio es que fomentan una convención de nombres muy verbosa. Esto, a su vez, conduce a programas que, en gran medida, se autodocumentan .

El lenguaje se parece un poco a Prolog (esto no es sorprendente ya que ambos lenguajes surgieron aproximadamente al mismo tiempo a partir del trabajo sobre gramáticas de afijos ). Sin embargo, a diferencia de Prolog, el flujo de control en CDL se basa de manera determinista en el éxito/fracaso, es decir, no se prueban otras alternativas cuando la actual tiene éxito. Esta idea también se utiliza en el análisis sintáctico de gramáticas de expresiones .

CDL3 es la tercera versión del lenguaje CDL, significativamente diferente de las dos versiones anteriores.

La versión original, diseñada por Cornelis HA Koster en la Universidad de Nijmegen , que surgió en 1971, tenía un concepto bastante inusual: no tenía núcleo. Una fuente de lenguaje de programación típica se traduce a instrucciones de máquina o secuencias enlatadas de esas instrucciones. Estas representan el núcleo, las abstracciones más básicas que admite el lenguaje dado. Tales primitivas pueden ser las sumas de números, la copia de variables entre sí, etc. CDL1 carece de dicho núcleo. Es responsabilidad del programador proporcionar las operaciones primitivas en una forma que luego pueda convertirse en instrucciones de máquina por medio de un ensamblador o un compilador para un lenguaje tradicional. El lenguaje CDL1 en sí no tiene concepto de primitivas, ni concepto de tipos de datos aparte de la palabra de máquina (una unidad abstracta de almacenamiento, no necesariamente una palabra de máquina real como tal). Las reglas de evaluación son bastante similares a las descripciones de sintaxis de la forma Backus-Naur ; de hecho, escribir un analizador para un lenguaje descrito en BNF es bastante simple en CDL1.

Básicamente, el lenguaje consta de reglas. Una regla puede tener éxito o fallar. Una regla consta de alternativas que son secuencias de otras invocaciones de reglas. Una regla tiene éxito si cualquiera de sus alternativas tiene éxito; estas se prueban en secuencia. Una alternativa tiene éxito si todas sus invocaciones de reglas tienen éxito. El lenguaje proporciona operadores para crear bucles de evaluación sin recursión (aunque esto no es estrictamente necesario en CDL2 ya que el optimizador logra el mismo efecto) y algunos atajos para aumentar la eficiencia de la evaluación que de otro modo sería recursiva, pero el concepto básico es el anterior. Aparte de la aplicación obvia en el análisis de gramática libre de contexto, CDL también es adecuado para aplicaciones de control, ya que muchas aplicaciones de control son esencialmente reglas if-then profundamente anidadas.

Cada regla CDL1, mientras se evalúa, puede actuar sobre datos, que son de un tipo no especificado. Idealmente, los datos no deberían cambiarse a menos que la regla tenga éxito (sin efectos secundarios en caso de falla). Esto causa problemas ya que, aunque esta regla puede tener éxito, la regla que la invoca aún puede fallar, en cuyo caso el cambio de datos no debería tener efecto. Es bastante fácil (aunque consume mucha memoria) asegurar el comportamiento anterior si todos los datos se asignan dinámicamente en una pila. Sin embargo, es bastante difícil cuando hay datos estáticos, que es a menudo el caso. El compilador CDL2 puede marcar las posibles violaciones gracias al requisito de que la dirección de los parámetros (entrada, salida, entrada-salida) y el tipo de reglas (puede fallar: prueba , predicado ; no puede fallar: función , acción ; puede tener un efecto secundario: predicado , acción ; no puede tener un efecto secundario: prueba , función ) deben ser especificados por el programador.

Como la evaluación de reglas se basa en llamar reglas cada vez más simples, en la parte inferior debería haber algunas reglas primitivas que hagan el trabajo real. Ahí es donde CDL1 es muy sorprendente: no tiene esas primitivas. Tienes que proporcionar esas reglas tú mismo. Si necesitas una suma en tu programa, tienes que crear una regla con dos parámetros de entrada y un parámetro de salida, y la salida se establece para que sea la suma de las dos entradas por tu código. El compilador CDL usa tu código como cadenas (hay convenciones sobre cómo hacer referencia a las variables de entrada y salida) y simplemente lo emite según sea necesario. Si describe su regla de suma usando ensamblador, necesitará un ensamblador para traducir la salida del compilador CDL al código de máquina. Si describe todas las reglas primitivas (macros en la terminología CDL) en Pascal o C, entonces necesita un compilador Pascal o C para ejecutarse después del compilador CDL. Esta falta de primitivas básicas puede ser muy dolorosa cuando tienes que escribir un fragmento de código, incluso para la operación de instrucción de máquina más simple. Sin embargo, por otro lado, le brinda una gran flexibilidad para implementar primitivos esotéricos y abstractos que actúan sobre objetos abstractos exóticos (la "palabra de máquina" en CDL es más como "unidad de almacenamiento de datos", sin referencia al tipo de datos almacenados allí). Además, los proyectos grandes hicieron uso de bibliotecas de primitivos cuidadosamente diseñadas. Estas luego se replicaron para cada arquitectura y sistema operativo de destino, lo que permitió la producción de código altamente eficiente para todos.

Para tener una idea del lenguaje, aquí hay un pequeño fragmento de código adaptado del manual CDL2:

ACCIÓN quicksort + >desde + >hasta -p -q:
  menos+de+a, dividir+de+a+p+q,
    ordenación rápida+desde+q, ordenación rápida+p+a;
  +.

ACCIÓN dividir + >i + >j + p> + q> -m:
  hacer+p+i, hacer+q+j, sumar+i+j+m, dividir por la mitad+m,
    (de nuevo: mover hacia arriba+j+p+m, mover hacia abajo+i+q+m,
       (menos+p+q, intercambiar elemento+p+q, incr+p, decr+q, *otra vez;
        menos+p+m, intercambiar elemento+p+m, incr+p;
        menos+m+q, intercambiar elemento+q+m, decr+q;
        +)).

FUNCIÓN mover hacia arriba + >j + >p> + >m:
  menos+j+p;
  artículo más pequeño+m+p;
  incr+p, *.

FUNCIÓN mover hacia abajo + >i + >q> + >m:
  menos+q+j;
  artículo más pequeño+q+m;
  decr+q, *.

PRUEBA menos+>a+>b:=a"<"b.
FUNCIÓN hacer+a>+>b:=a"="b.
FUNCIÓN suma+>a+>b+suma>:=suma"="a"+"b.
FUNCIÓN dividir-por-la-mitad+>a>:=a"/=2".
FUNCIÓN incr+>a>:=a"++".
FUNCIÓN decr+>a>:=a"--".

PRUEBA elemento más pequeño+>i+>j:="elementos["i"]<elementos["j"]".
ACCIÓN intercambiar elementos+>i+>jt:=t"=elementos["i"];elementos["i"]=elementos["j"];elementos["j"]="t.

Las operaciones primitivas se definen aquí en términos de Java (o C). Este no es un programa completo; debemos definir los elementos de la matriz de Java en otro lugar.

CDL2, que apareció en 1976, mantuvo los principios de CDL1 pero hizo que el lenguaje fuera adecuado para proyectos grandes. Introdujo módulos, impuso el cambio de datos solo en caso de éxito y amplió un poco las capacidades del lenguaje. Los optimizadores del compilador CDL2 y, especialmente, del Laboratorio CDL2 (un IDE para CDL2) eran de primera clase y no solo para su época. Una característica del optimizador del Laboratorio CDL2 es casi única: puede realizar optimizaciones en todas las unidades de compilación, es decir, tratar todo el programa como una sola compilación.

CDL3 es un lenguaje más reciente. Abandonó la característica de final abierto de las versiones CDL anteriores y proporciona primitivas para aritmética básica y acceso al almacenamiento. La sintaxis extremadamente puritana de las versiones CDL anteriores (el número de palabras clave y símbolos se ejecuta en un solo dígito) también se ha relajado. Algunos conceptos básicos ahora se expresan en sintaxis en lugar de semántica explícita. Además, se han introducido tipos de datos en el lenguaje.

El sistema comercial mbp Cobol (un compilador Cobol para PC) así como el sistema MProlog (una implementación de Prolog de nivel industrial que funcionaba en numerosas arquitecturas (mainframe IBM, VAX, PDP-11, Intel 8086, etc.) y sistemas operativos (DOS/OS/CMS/BS2000, VMS/Unix, DOS/Windows/OS2)). Este último, en particular, es un testimonio de la portabilidad de CDL2.

Si bien la mayoría de los programas escritos con CDL han sido compiladores, existe al menos una aplicación GUI comercial que se desarrolló y mantuvo en CDL. Esta aplicación era una aplicación de adquisición de imágenes dentales que ahora es propiedad de DEXIS. También se desarrolló un sistema de gestión de consultorios dentales en CDL.

El software para el ordenador de ajedrez Mephisto III fue escrito con CDL2. ^[1]

• Un libro sobre el lenguaje CDL1 / CDL2
• La descripción de CDL3
• Bedő Árpád: Programkészítési Módszerek; Közgazdasági és Jogi Könyvkiadó, 1979. ISBN 963-220-760-2