Cuando escribía likely, unlikely y __builtin_expect, me vinieron recuerdos de antaño. Me refieron en concreto a los hints o anotaciones. Es decir, añadidos que se hacen en el código fuente, con la finalidad que el documentador, compilador, intérprete o cualquier otra herramienta, pueda leerlos.
El caso de la macro likely, era evidente, un añadido que no afecta al código fuente, pero que sirve para indicar al compilador como mejorar el código que genera.
En realidad, las anotaciones, son algo que se usan con bastante frecuencia en casi todos los lenguajes de programación. Por ejemplo Google Closure Compiler y JSDoc usan los suyos para mejorar la velocidad de ejecución, detección de errores, y el detalle de la documentación respectivamente.
Estoy seguro, que habréis visto lineas de código parecidas a estas:
/* @type {number} */
var iNum;
Sabemos que Javascript es en general, y desgraciadamente, un lenguaje sin tipos de datos explícitos, de manera que añadiendo este sistema, informamos al JIT/compilador que una variable es de un tipo concreto (numérico), y así puede generar un código más eficiente.
Reconozcamos que es muy ingenioso lo de encapsularlo dentro de comentarios. Así no afecta a la sintaxis del programa, y en caso de que la anotación no se soporte, simplemente será tratada como un comentario normal, es decir, ignorada. ¿Muy ingenioso verdad?
Podríamos pensar que es que en Google son muy ingeniosos, a pesar que en realidad JSDoc, está basado en los conceptos de Javadoc de finales de los años 90. Pero no vayáis tan rápido, que en realidad el mérito no va para la gente de Sun, naturalmente.
Lo sorprendente, es que este concepto yo ya lo había visto. Concretamente con Hisoft Basic, el increíble compilador de lenguaje ZX Basic para Spectrum, que inició su andadura en 1986.
Hisoft Basic, pretendía ser totalmente compatible con el BASIC de Spectrum, eso no solamente quería decir que tuviera que ser capaz de compilar un programa existente, sino también que los programas existentes, tenían que seguir funcionando en el intérprete Basic. Así que Cameron Hayne, decidió implementar las directivas de compilación en Hisoft Basic. Estas directivas, permitían modificar comportamientos por defecto del compilador, al mismo tiempo que no interferían con el Basic del Spectrum. Visto ahora, la asociación es clara, había que hacerlo mediante comentarios (REM en Basic), justo lo mismo que Javadoc o JSDoc.
Pero es que además, el Sinclair Basic, tampoco era un lenguaje tipado, era fácil imaginar que para un ordenador de 8 bits, manejar todos los números como flotantes, que es lo que hacía Basic, era un esfuerzo tremendo, por lo que optó por añadir el tipado vía anotaciones. Eso es amigo, exactamente igual que Javascript con JSDoc o Google Closure Compiler.
Además, en los tiempos donde apenas quedaban 41 Kb. de memoria para el usuario, de las que el compilador, ya consumía 15 Kb. había que aprovechar la memoria al máximo. Así que Hayne, decidió que el formato de las anotaciones, utilizase palabras clave de Basic, internamente se codificaban como tokens, por lo que por ejemplo REM : CLOSE # no necesitaba 14 bytes para almacenarse, sino solamente 4. El manual da muchos más detalles, que permiten admirar la grandeza en algo tan pequeño para los estándares actuales.
