Hola mentalthink,
No sé si esta consulta va en relación a la otra que has abierto "
Memoria RAM y como se escribe... " también en el foro, pues muchas de las contestaciones escritas allí se pueden aplicar también a este tema. En el otro hilo ha quedado más o menos claro, que es el sistema operativo quien decide cómo se va a organizar la memoria disponible. En el caso de nuestros viejos amigos de 8 bits, sería el código de la ROM o Firmware que se ejecuta en el arranque de la máquina, el responsable de permitir que el usuario interactúe en BASIC y de intentar mantener el control de los programas escritos en ese lenguaje.
El BASIC es un lenguaje interpretado. ¿Qué significa esto? A diferencia de los lenguajes de alto nivel compilados que generan un bloque de código máquina, o a los directamente escritos desde ensamblador, el BASIC se va analizando sintácticamente línea por línea y cada comando hace ejecutar una subrutina específica previa de la ROM o Firmware. Si el comando tiene que tomar valores y/o devolver resultados a través de variables, el sistema operativo se encarga internamente de definir un área de memoria para almacenar dichas variables de usuario, y mantener una tabla de punteros para llegar a ellas.
El tamaño del área de variables de usuario se ajustará dinámicamente, pues al ser el programa interpretado línea a línea, el sistema no sabe de antemano cuánto va a necesitar ni cuánto reservar. En algunos equipos de 8 bits, ese área de variables crece hacia arriba y en otros crece hacia abajo. En otros se almacena después del código del programa y es constantemente empujada conforme vamos metiendo más líneas BASIC al programa. Eso al programador de BASIC no le importa, pues se realiza internamente, pero te lo cuento para que veas que es solo cuestión de cómo el programador original de la ROM decidió organizar el equipo. Si a esos señores se le hubiese ocurrido otra cosa, el comportamiento de su BASIC habría sido radicalmente diferente.
Los procesadores tienen un registro contador de programa (PC) que es el que gestiona la ejecución de la siguiente instrucción de código máquina. Pero a la hora de interpretar el BASIC, el registro PC no es el que regula concretamente ese tema, ya que como expuse antes, cada instrucción de BASIC invoca a una subrutina de código máquina que puede ejecutar decenas o cientos de instrucciones reales de procesador. Para llevar la cuenta de por dónde va, el número de línea y el comando dentro de cada línea, el sistema lo va apuntando en su propia área de variables del sistema. Ese área, al contrario de la de variables de usuario, sí que suele ser fija y suele estar documentada, por si acaso necesitamos acceder a sus valores.
Como casi todos los BASIC permiten al usuario el poder saltar a ejecutar un programa en código máquina, es cuando pasa a ser tu responsabilidad el conocer la estructura interna del equipo y para ello existen manuales detallados de dónde deja el sistema cada cosa, porque en los 8 bits pasabas a tener el control absoluto de la máquina y cualquier fallo de tu programa bloquearía el ordenador. No sé muy bien cuál es la intención al hacer tu consulta, si es que tiene un propósito específico o es mera curiosidad.
Para Amstrad CPC, la
Guía del Firmware es el manual detallado que explica la estructura del sistema. Para ir todavía a un nivel más bajo, ya tendríamos que recurrir a desensamblados de la ROM, que no suele ser necesario salvo en extraños casos donde queramos ejecutar arbitrariamente código desde puntos de entrada no estándar. La disposición en los equipos de 64 KB va a ser diferente a la establecida en los equipos de 128 KB, ya que al incorporar más funcionalidades, muchas cosas acabaron movidas de sitio. La documentación recoge la estructura de ambas máquinas.
Yo no soy programador de Amstrad CPC, pero en la ristra de variables del sistema seguro que uno de los muchos punteros es el que almacena la posición del fin de programa.
Ver páginas 8 a 29 de este documento en PDF:
http://www.cantrell.org.uk/david/tech/c ... rmware.pdf
)