Compiladores &
Traductores

Un traductor convierte código fuente en código objeto. Facilita detección de errores, aumenta productividad y brinda portabilidad.

Fases del Compilador

Lee el código fuente carácter a carácter y produce tokens. Cada token es un nodo de lista enlazada:

struct t_token {
    int   intTokenCode;           // código numérico (T_TRIGHT=1, T_ADVANCE=3, etc.)
    char *strTokenSourceCodeText; // texto original del fuente
    int   intRow;                 // fila en el fuente
    int   intColumn;              // columna en el fuente
    struct t_token *ptrNext;      // siguiente token → lista enlazada
};

Tokens definidos en Eiichi

#define T_TRIGHT 1  · T_TLEFT 2  · T_ADVANCE 3  · T_GOBACK 4
#define T_IF_CRASH 5 · T_PICKUP 6 · T_PUTDOWN 7  · T_Num 8
#define T_SemiColon 9 · T_EOF 13

El proyecto implementa ambos tipos Top-Down: RDCP y LL(1), sobre la misma gramática.

RDCP — funciones auxiliares clave

// Implementa FIRST: ¿puede el token actual iniciar el no terminal?
int CurrentTokenInFirst(int intNTSymbol) { ... }

// Consume el token si coincide; si no, activa boolParserError
void Expect(int intTSymbol) { ... }

// Program ::= Instruction; {Instruction;}
void Program() {
    Instruction();
    Expect(T_SemiColon);
    while(CurrentTokenInFirst(NT_Instruction)) {   // ← usa FIRST
        Instruction();
        Expect(T_SemiColon);
    }
}

LL(1) — Tabla de Reconocimiento RM[7][13]

// RM[No Terminal - 1][Terminal - 1] = número de regla (-1 = error)
// Columnas: TR TL ADV GOB IF  PU  PD  Nm  ;  Sp  Tb  EOL EOF
   { 1,  1,  1,  1,  1,  1,  1, -1, -1, -1, -1, -1, -1}, // NT_Program
   { 2,  2,  2,  2,  2,  2,  2, -1, -1, -1, -1, -1,  3}, // NT_Program2 (3=eps con EOF)
   { 4,  4,  5,  5,  6,  7,  7, -1, -1, -1, -1, -1, -1}, // NT_Instruction
   { 8,  9, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, // NT_InstrTurn
   {-1, -1, 10, 11, -1, -1, -1, -1, -1, -1, -1, -1, -1}, // NT_InstrAdvance
   {-1, -1, -1, -1, 12, -1, -1, -1, -1, -1, -1, -1, -1}, // NT_InstrIfCrash
   {-1, -1, -1, -1, -1, 13, 14, -1, -1, -1, -1, -1, -1}  // NT_InstrObject

FIRST y FOLLOW

Robot en tablero 8×8. Debe recoger un objeto y salir evitando chocar.

Instrucciones → Código generado

Máquina Multinivel

Modos de Direccionamiento en Eiichi

La VM de Eiichi es una máquina virtual de propósito específico. El parser RDCP genera código binario (a través de GC()) y la VM lo ejecuta. La relación entre ambos es directa: cada instrucción Eiichi produce una secuencia de bytes exacta.

Set de instrucciones de la VM

Registros de la VM

Flags de la ALU

// Se actualizan después de DEC y CMP:
void ReviewACCFlags() {
    FLAG_EQUAL_TO_ZERO    = (ACC == 0) ? TRUE : FALSE;
    FLAG_GREATER_THAN_ZERO = (ACC > 0) ? TRUE : FALSE;
    FLAG_LESS_THAN_ZERO   = (ACC < 0) ? TRUE : FALSE;
}
// JNZ usa:  FLAG_GREATER_THAN_ZERO || FLAG_LESS_THAN_ZERO
// JEZ usa:  FLAG_EQUAL_TO_ZERO

Ciclo de Ejecución — Fetch → Decode → Execute

PC = 0;
do {
    IR1 = mem[PC++];   // FETCH: lee opcode, avanza PC
    switch (IR1) {     // DECODE + EXECUTE
        case A_MOV:    i_mov();    break; // lee 4 bytes más (AM+val AM+reg)
        case A_ADV:    i_adv();    break; // sin parámetros
        case A_DEC:    i_dec();    break; // ACC--
        case A_JNZ:    i_jnz();   break; // lee 1 byte: dirección de salto
        case A_JEZ:    i_jez();    break; // lee 1 byte: dirección de salto
        case A_PUSH:   i_push();   break; // lee 2 bytes (AM+val)
        case A_CMP:    i_cmp();    break; // sin parámetros
        case A_TRIGHT: i_tright(); break; // sin parámetros
        case A_TLEFT:  i_tleft();  break; // sin parámetros
        case A_PICKUP: i_pickup(); break; // sin parámetros
        case A_PUTDOWN:i_putdown();break; // sin parámetros
        case A_END:    i_end();    break; // sin parámetros
    }
    graphBoard_DrawExecutionContext(); // dibuja tablero después de cada instrucción
} while ((mem[PC] != A_END) && (!boolSystemError) && (!boolSystemSuccess) && (keypressed != 'q'));

Cómo funciona ADVANCE N en detalle

Es el ejemplo más completo de cómo el parser RDCP genera un bucle completo en ensamblador:

// InstrAdvance() en parser_RDCP.c genera:
GC(A_MOV); GC(AM_IMMEDT); GC(Num); GC(AM_DIRREG); GC(R_AC);
//   MOV #N, AC   → carga el contador

signed short label = (signed short)PC;  // ← guarda posición del inicio del bucle
GC(A_MOV); GC(AM_DIRREG); GC(R_AC); GC(AM_DIRREG); GC(R_ACC);
//   MOV AC, ACC  → copia contador al acumulador (para los flags)

GC(A_ADV);   // ADV → avanza el robot 1 posición
GC(A_DEC);   // DEC → ACC-- (y actualiza flags)
GC(A_MOV); GC(AM_DIRREG); GC(R_ACC); GC(AM_DIRREG); GC(R_AC);
//   MOV ACC, AC  → actualiza el contador con el nuevo valor

GC(A_JNZ); GC(label);
//   JNZ label   → si ACC ≠ 0, vuelve al inicio del bucle

Cómo funciona IF_CRASH en detalle

// InstrIfCrash() genera:
GC(A_PUSH); GC(AM_DIRREG); GC(R_CRC); // PUSH CRC → empuja crash counter
GC(A_PUSH); GC(AM_IMMEDT); GC(0);     // PUSH #0  → empuja cero
GC(A_CMP);                             // CMP → ACC = 0 - CRC (si CRC=0: ACC=0)
GC(A_JEZ);
signed short LabelToBeSolved = (signed short)PC; // guarda posición del operando
GC(0);        // placeholder temporal — se resolverá con backpatch
GC(A_TLEFT);  // si CRC > 0: gira izquierda (instrucción de recuperación fija)
// ... instrucción adicional si existe ...
signed short Label = (signed short)PC;
GC_AddToVectorAddressesToBeUpdate(LabelToBeSolved, Label); // backpatch

Es el programa compilado en formato binario. Cada valor es un signed short (2 bytes). Para leerlo desde Python:

import struct
with open("object.bin", "rb") as f:
    data = f.read()
values = struct.unpack(f"{len(data)//2}h", data)
for i, v in enumerate(values):
    print(f"{i}\t{v}")

La VM también lo desensambla automáticamente con GC_VerifyGeneratedBinaryFile(), que imprime el ensamblador legible al ejecutar.

Cómo leer el binario manualmente

Se aplica la misma tabla de #define del proyecto. El primer valor es siempre un opcode. Según el opcode, los siguientes valores son sus parámetros:

Desensamblado real del object.bin del proyecto

Este es exactamente el output que produce GC_VerifyGeneratedBinaryFile() al ejecutar la VM:

Cómo la VM carga y ejecuta el binario

// 1. LoadProgramInMemory() lee el .bin y lo pone en mem[]
void LoadProgramInMemory(char *strBinaryFile) {
    FILE *f = fopen(strBinaryFile, "rb");
    signed short sshValue;
    int PCLocal = 0;
    while(fread(&sshValue, sizeof(signed short), 1, f) != 0)
        mem[PCLocal++] = (int)sshValue;  // cada signed short → una celda de mem[]
    fclose(f);
}

// 2. main() ejecuta desde mem[0]
PC = 0;
do {
    IR1 = mem[PC++];   // FETCH
    switch(IR1) { ... } // DECODE + EXECUTE
} while (mem[PC] != A_END && ...);

Estos bugs fueron encontrados en la versión original entregada. La VM corregida (v2) ya los resuelve — pero quedan 4 pendientes.

Bugs ya corregidos en la VM v2

Bugs pendientes en la VM v2 (corregida)

Bugs en parser_RDCP.c

Pipeline completo

GC() — Generate Code

void GC(signed short sshByte) {
    if (!boolParserError) {
        fwrite(&sshByte, sizeof(signed short), 1, ptrGCBinaryFile);
        PC++;  // PC del compilador, no de la VM
    }
}
// Cada instrucción Eiichi = múltiples llamadas a GC():
// ADVANCE 3; → GC(1) GC(1) GC(3) GC(2) GC(6)  ← MOV #3,AC
//             GC(1) GC(2) GC(6) GC(2) GC(7)    ← MOV AC,ACC
//             GC(2) GC(3)                        ← ADV DEC
//             GC(1) GC(2) GC(7) GC(2) GC(6)    ← MOV ACC,AC
//             GC(4) GC(label)                    ← JNZ label

Diferencias clave: RDCP vs LL