En/Je/On 2015-12-02 19:25, Miguel Angel Rodriguez Jodar [email protected] [forth-es] escribió / skribis / wrote :
> Me refiero no a un compilador de C, sino al lenguaje C en general: es un > lenguaje que puede ser tan cercano a la máquina como lo sería un > macroensamblador. El programador, por ejemplo, puede forzar, o al menos > sugerir, que una variable se guarde en un registro y no en memoria, y al > contrario: forzar a que una variable siempre esté en memoria y nunca se > guarde de forma permanente en un registro. No sabrá qué registro se usa, > pero sí puede saber en qué dirección de memoria se ha guardado la > variable, y de hecho este tipo de cosas se usan para, por ejemplo, > detectar si la máquina en la que se está ejecutando el programa es > big-endian o little-endian. Entonces mis conocimientos de C están más oxidados de lo que creía. Gracias por la actualización tan detallada. No recordaba que en la fuente se pudiera hacer todo eso expresamente. El funcionamiento en todo caso es muy diferente a Forth, porque, aunque sí hay compiladores de Forth en el sentido habitual de la palabra, es decir, que crean un código binario real, ejecutable por el procesador, son la excepción. > También puede usar los valores de las variables como secuencias de > bits que son, y así por ejemplo examinar el signo de un número mirando > su bit más significativo y esas cosas (por supuesto a costa de perder > portabilidad). Sí, igual que en Forth, puedes tener el control que quieras a ese nivel. > Las operaciones elementales a nivel de ALU tienen una correspondencia > directa con las operaciones aritméticas en C. Recientemente quise hacer > una pequeña virguería con la implementación FPGA que hice del Jupiter > ACE y me encontré que no había (o no la encontré) una instrucción para > desplazar a izquierda o derecha un valor una serie de bits. Vale que es > lo mismo (casi) que multiplicar o dividir por dos, pero me extrañó que > una operación tan simple y de tan bajo nivel no estuviera implementada. El motivo es que ACE Forth, aunque está bien adaptado a las limitaciones de la máquina (por ejemplo, soluciona muy ingeniosamente cómo reeditar la fuente de una palabra sin tener que volver a leerla de la cinta) carece de palabras que en su época ya eran habituales en otros sistemas Forth. De todas maneras eso no es un problema porque, a diferencia de lo que ocurre con otros lenguajes, en Forth no escribes programas limitándote al lenguaje, sino que amplías el propio lenguaje para adaptarlo al problema que quieres solucionar. En este caso se añadirían `rshift` y `lshift` como palabras primitivas (escritas en código máquina), y sería exactamente lo mismo que si hubieran venido de serie, no habría ninguna diferencia. Otra solución para estos casos es compilar código máquina en el espacio de datos y llamar a esa direccióndirectamente con la palabra `call` de Ace Forth. > Era esto: > https://www.youtube.com/watch?v=rRmp40PNK7o > > El programa, si mal no recuerdo, era algo así: > > :BOLD > 12288 11264 DO > I C@ DUP 2 * OR I C! > LOOP > END; Buena memoria. Esas son las direcciones del juego de caracteres, efectivamente. Solo te has comido un par de espacios: ---- : BOLD 12288 11264 DO I C@ DUP 2 * OR I C! LOOP ; ---- > Y lo que hace es cambiar el juego de caracteres para que la letra > aparezca como en negrita. En el clon FPGA esto es posible porque la > memoria destinada a guardar el juego de caracteres es leible y > escribible. En el Jupiter ACE original sólo es escribible. ¿Solo escribible? Tengo hechos algunos jueguecillos en ACE Forth pero no recordaba esa limitación. Entonces puedes definir tus propios caracteres porque están ya copiados en RAM, pero no puedes leer lo que hay en esa zona porque ese rango de direcciones no está conectado como debería... Recuerdo que el mapa de memoria de Jupiter ACE es muy peculiar, con algunas zonas visibles en más de un rango de direcciones. Entonces, ¿con el clon FPGA se puede modificar esa zona porque tú lo has programado así o porque es una limitación de la descripción que haces de los circuitos? Quiero decir, ¿no queda más remedio que que sea modificable o podrías recrear el comportamiento exacto de la máquina real en ese punto? > > trasparente. Por ejemplo, manejas directamente direcciones de memoria y > > sabes dónde están "las cosas". Hablo de un Forth clásico, con un pequeño > > Mi única experiencia con Forth es con el Jupiter ACE y ahí defino > variables con VAR, y no sé dónde las situa el intérprete. En la dirección que la variable deja en la pila cuando se ejecuta. ---- variable zx zx . ( dirección ) zx @ . ( contenido ) ---- > Puedo averiguar más tarde dónde las situa, pero no he sido yo (el > programador) quien ha elegido ese sitio. Puedo forzar a que una > variable esté en una dirección, sí: exactamente lo mismo que puedo > hacer en C, en donde también puedo forzar a que una variable esté en > una dirección concreta Sí, en Forth puedes elegir dónde guardar lo que quieras, incluso forzar dónde se tienen que compilar las palabras, o de dónde debe leer la fuente el intérprete. Lo que sea. Y todo ello sobre la marcha en cualquier momento, durante la interpretación, durante la compilación o durante la ejecución. > > implementado con un núcleo escrito en C u otro lenguaje, por ejemplo, > > esta relación directa puede perderse, depende de cómo esté escrito. En > > Si se escribe en C no se pierde. ¡Los punteros son tus amigos! Es más fácil que en C no se pierda, pero depende de cómo esté escrita la implementación. Por ejemplo, en una implementación clásica de Forth el diccionario es una estructura definida en la memoria, que se puede examinar y manipular directamente (a costa de portabilidad) para hacer cosas especiales. Eso se puede perder en otros casos, según cómo se implemente. Pero, como siempre, a cambio de otras ventajas. Hay innumerables implementaciones de Forth, de todo tipo. > > Forth, ni que esté más cerca de la máquina. De hecho, la máquina virtual > > de Java, que ejecuta su código de octetos seudocompilado, tiene muchas > > similitudes con cómo funciona el intérprete interior de Forth. > > ¿Es una máquina basada en pila? Sí. Una pila es una estructura muy eficaz para manipular datos y pasarlos entre comandos. > De momento ya convencí a un alumno para que hiciera un clon del Jupiter > ACE, y este año tengo unos cuantos que se van a poner manos a la obra > para construir clones de Spectrum :D Para los Spectrum te bastas tú solo, pero aquí en el grupo está Sergio, que ha hecho un clon de Jupiter ACE y te puede ayudar a poner la nota :) -- Marcos Cruz http://programandala.net
