stringtranslate.com

Atari BÁSICO

Atari BASIC es un intérprete del lenguaje de programación BASIC que se incluía con los ordenadores Atari de 8 bits . A diferencia de la mayoría de los BASIC estadounidenses de la era de los ordenadores domésticos, Atari BASIC no es un derivado de Microsoft BASIC y difiere de forma significativa. Incluye palabras clave para funciones específicas de Atari y no admite matrices de cadenas.

El lenguaje se distribuyó como un  cartucho ROM de 8 KB para su uso con los ordenadores Atari 400 y 800 de 1979. A partir de los modelos 600XL y 800XL en 1983, BASIC está integrado en el sistema. Hay tres versiones principales del software: la versión original basada en cartucho "A", la versión "B" integrada para los modelos 600XL/800XL y la versión final "C" en los modelos XL más recientes y la serie XE.

A pesar de que los ordenadores Atari de 8 bits funcionaban a una velocidad superior a la de la mayoría de sus contemporáneos, varias decisiones técnicas situaron al Atari BASIC cerca del final de los índices de rendimiento. Los autores originales solucionaron la mayoría de estos problemas en una serie de versiones mejoradas: BASIC A+ (1981), BASIC XL (1983) y BASIC XE (1985).

El código fuente completo y anotado y las especificaciones de diseño de Atari BASIC se publicaron como The Atari BASIC Source Book en 1983. [2]

Desarrollo

Las máquinas que se convertirían en los ordenadores Atari de 8 bits se desarrollaron originalmente como consolas de videojuegos de segunda generación destinadas a reemplazar a la Atari VCS . Ray Kassar , el nuevo presidente de Atari, decidió desafiar a Apple Computer construyendo en su lugar un ordenador doméstico. [3]

Esto significaba que los diseños debían incluir el lenguaje de programación BASIC , el estándar para los ordenadores domésticos. A principios de 1978, Atari licenció el código fuente de la versión MOS 6502 de Microsoft BASIC . [4] Se ofrecía en dos versiones: una que utilizaba un formato de punto flotante de 32 bits que ocupaba unos 7800 bytes al compilarse, y otra que utilizaba un formato extendido de 40 bits que ocupaba cerca de 9 KB. [5]

Incluso la versión de 32 bits apenas cabía en el tamaño de 8 KB del formato de cartucho ROM de la máquina . Atari también sintió que necesitaba expandir el lenguaje para soportar las características de hardware de sus computadoras, similar a lo que Apple había hecho con Applesoft BASIC . Esto aumentó el tamaño de la versión de Atari a alrededor de 11 KB; AppleSoft BASIC en el Apple II+ tenía 10,240 bytes de longitud. [a] Después de seis meses, el código se redujo para que casi cupiera en una ROM de 8 KB, [4] pero Atari se enfrentaba a una fecha límite de enero de 1979 para el Consumer Electronics Show (CES) donde se mostrarían las máquinas. Decidieron pedir ayuda para tener una versión de BASIC lista a tiempo para la feria. [4]

Microsistemas Shepardson

Cartucho Atari BASIC de 8K

En septiembre de 1978, Shepardson Microsystems ganó la licitación para completar BASIC. [4] En ese momento estaban terminando el BASIC estructurado de 16K de Cromemco para las máquinas de bus Cromemco S-100 basadas en Z80 . [6] [7] Los desarrolladores Kathleen O'Brien y Paul Laughton utilizaron Data General Business Basic , una implementación de solo números enteros, como inspiración para su BASIC, dada la experiencia de Laughton con Data General en un sistema de tiempo compartido . [1]

Cromemco BASIC incluía una implementación extendida de punto flotante que utilizaba un formato decimal codificado en binario (BCD) de 14 dígitos, que era posible gracias a los 16 registros del procesador Zilog Z80 . Como convertía todos los datos al formato interno en el momento de la edición, las constantes pequeñas como "1" utilizaban una cantidad considerable de memoria, y esto podía ser un problema particular al almacenar matrices de números. Para solucionar esto, el lenguaje también admitía un formato BCD de 6 dígitos. También incluía un formato entero independiente de 16 bits para almacenar valores internos como números de línea y valores de sistema similares. [8]

Incluso los BASIC más pequeños en el 6502 generalmente usaban alrededor de 10K, por ejemplo, Commodore BASIC usaba 9K pero también dependía del soporte del KERNAL , [b] mientras que Applesoft BASIC usaba 10780 bytes. [c] Para cumplir con el objetivo de caber en una ROM de 8K, el nuevo BASIC estaría en dos partes, el lenguaje en sí en el cartucho y una biblioteca FP separada que usaba 2K en la ROM de 10K del sistema. [11] Para caber dentro de 2k, el sistema de punto flotante solo admitía el formato de 6 dígitos.

Atari aceptó la propuesta y, cuando las especificaciones se ultimaron en octubre de 1978, Laughton y O'Brien comenzaron a trabajar en el nuevo lenguaje. [4] El contrato especificaba la fecha de entrega el 6 de abril de 1979 o antes, y también incluía un sistema de gestión de archivos (más tarde conocido como DOS 1.0). [11] Los planes de Atari eran llevar una versión temprana de 8K de Microsoft BASIC al CES de 1979 y luego cambiar a Atari BASIC para la producción. El desarrollo avanzó rápidamente, ayudado por una cláusula de bonificación en el contrato, que llevó a que la versión inicial se entregara en octubre. Atari llevó una versión en cartucho de 8K al CES en lugar de la de Microsoft. [12] Atari Microsoft BASIC más tarde estuvo disponible como un producto separado. [13]

Lanzamientos

La versión que Shepardson le dio a Atari para la demostración del CES no estaba destinada a ser definitiva, y Shepardson continuó corrigiendo errores. [12] Sin que Shepardson lo supiera, Atari ya había enviado la versión del CES a fabricación. [14]

Esta versión se conoció posteriormente como Revisión A. Contiene un error importante en una rutina que copia la memoria: eliminar líneas de código que tienen exactamente 256 bytes de longitud provoca un bloqueo después de que se ingresa el siguiente comando. La Resetclave no lo soluciona. [15]

La Revisión B intentó corregir los errores más importantes de la Revisión A y se publicó en 1983 como una ROM integrada en los modelos 600XL y 800XL. Mientras arreglaba el error de copia de memoria, el programador notó el mismo patrón de código en la sección para insertar líneas y aplicó la misma corrección. Esto en cambio introdujo el error original en este código. Insertar nuevas líneas es mucho más común que eliminar las antiguas, por lo que el cambio aumentó drásticamente la cantidad de fallas. [15] La Revisión B también agrega 16 bytes a un programa cada vez que se SAVEejecuta y LOADejecuta, lo que eventualmente hace que la máquina se quede sin memoria incluso para los programas más pequeños. [16] [17] Mapping the Atari describió estos como "errores asombrosos" y aconsejó a los propietarios de la Revisión B "No se desesperen; obtengan la nueva ROM, que está disponible en cartucho" de Atari. [17] El libro proporciona un programa para escribir y parchear la Revisión B a la Revisión C para aquellos que no tienen el cartucho. [18]

La revisión C elimina las fugas de memoria de la revisión B. [17] Está integrada en versiones posteriores del 800XL [16] y en todos los modelos XE, incluido el XEGS. La revisión C también estaba disponible como cartucho. [17]

La versión se puede determinar escribiendo PRINT PEEK(43234)en el mensaje READY. El resultado es 162para la Revisión A, 96para la Revisión B y 234para la Revisión C. [19]

Descripción

Edición de programas

Los errores de sintaxis se informan inmediatamente después de ingresar una línea.

Como la mayoría de los BASIC para ordenadores domésticos, el Atari BASIC se basa en su editor de líneas . Las líneas de programa pueden ser hasta tres líneas de pantalla físicas de 40 caracteres, 120 caracteres en total. El cursor se puede mover libremente y el editor rastrea automáticamente de qué línea de programa BASIC forma parte la línea de pantalla actual. Por ejemplo, si el cursor está posicionado actualmente en la línea 30 y el usuario utiliza la función cursor-arriba para pasar a la línea 20, cualquier edición a partir de ese punto se realizará en la línea 20.

El editor de Atari BASIC detecta muchos errores que no se notarían en las versiones derivadas de MS. Si se encuentra un error, el editor vuelve a mostrar la línea, resaltando el texto cerca del error en video inverso . Los errores se muestran como códigos numéricos, con las descripciones impresas en el manual. [20] Debido a la forma en que funciona el editor de línea, el usuario puede corregir el error inmediatamente. En el ejemplo que se muestra arriba (con PRUNT), el error se puede corregir moviendo el cursor sobre U, escribiendo (el editor solo tiene un modo de sobrescritura) y presionando .IRETURN

Una línea introducida con un número inicial, de 0 a 32767, [21] se inserta en el programa actual o reemplaza una línea existente. Si no hay número de línea, el intérprete le asigna el número -1 (8000 16 ) y los comandos se ejecutan inmediatamente, en "modo inmediato". El RUNcomando ejecuta el programa almacenado desde el número de línea más bajo. Atari BASIC permite que todos los comandos se ejecuten en ambos modos. Por ejemplo, LISTse puede utilizar dentro de un programa, mientras que en muchos intérpretes esto estaría disponible solo en modo inmediato.

Durante la entrada, las palabras clave se pueden abreviar utilizando el patrón establecido por Palo Alto Tiny BASIC , escribiendo un punto en cualquier punto de la palabra. So L.se expande a LIST, tal como es LI.. Solo se deben escribir las letras suficientes para que la abreviatura sea única, por lo que PLOTrequiere PL.porque la letra única P no es única. Para expandir una abreviatura, el tokenizador busca en su lista de palabras reservadas para encontrar la primera que coincida con la parte suministrada. Los comandos más utilizados aparecen primero en la lista de palabras reservadas, con REMal principio (se puede escribir como .). Cuando el programa se LISTedita más tarde, siempre escribirá las palabras completas con tres excepciones: PRINTtiene un sinónimo, ?; GOTOtiene un sinónimo, GO TO; y LETtiene un sinónimo que es la cadena vacía (so y significan lo mismo). Estos son tokens separados, y so permanecerán como tales en la lista del programa. Los BASIC de MS también permitían una forma corta para , pero esto usaba el mismo token, por lo que se expandió de nuevo a cuando se editó, tratándolo como una abreviatura, no como un sinónimo.10 LET A = 1010 A = 10?PRINTPRINTLIST

Tokenizador

Cuando el usuario presiona mientras edita, la línea actual se copia en el búfer de línea de entrada BASIC en la memoria entre 580 y 5FF 16 . [21] El tokenizador de Atari BASIC escanea el texto, convirtiendo cada palabra clave en un token de un solo byte (por ejemplo, es 20 16 ), [22] cada número en un valor de punto flotante de seis bytes, cada nombre de variable en un índice en una tabla, y así sucesivamente, hasta que la línea se convierte completamente en un formato fácil de interpretar. El resultado se almacena en un búfer de salida ubicado en los primeros 256 bytes de la memoria libre más baja disponible, apuntada por el puntero LOMEM almacenado en 80, 81 16 . [21] Luego, la salida del tokenizador se reubica. El programa se almacena como un árbol de análisis . [d]RETURNPRINT

Shepardson se refirió a este concepto de tokenización completa como un "intérprete de precompilación". [23] El código tokenizado resultante elimina cualquier análisis durante el tiempo de ejecución, lo que hace que se ejecute más rápido. Tiene la desventaja de que las constantes pequeñas, como 0 o 1, tienen seis bytes cada una, más que el texto original.

Un conjunto de punteros (direcciones) indica varios datos: los nombres de las variables se almacenan en la tabla de nombres de variables (VNTP – 82, 83 16 ) y sus valores se almacenan en la tabla de valores de las variables (apuntada en VVTP – 86, 87 16 ). Al indirigir los nombres de las variables de esta manera, una referencia a una variable necesita solo un byte para direccionar su entrada en la tabla apropiada. Las variables de cadena tienen su propia área (apuntada en STARP – 8C, 8D 16 ) al igual que la pila de tiempo de ejecución (apuntada en RUNSTK – 8E, 8F 16 ) utilizada para almacenar los números de línea de las instrucciones de bucle ( FOR...NEXT) y subrutinas ( GOSUB...RETURN). Finalmente, el final del uso de la memoria BASIC se indica mediante una dirección almacenada en el puntero MEMTOP – 90, 91 16 ).

Funciones matemáticas

Atari BASIC incluye tres funciones trigonométricas: seno, coseno y arcotangente. DEGTambién RADpermite configurar si estas funciones utilizan radianes o grados, y el valor predeterminado es radianes. Otras ocho funciones incluyen redondeo, logaritmos y raíz cuadrada. La función aleatoria, RND, genera un número entre 0 y 1; no se utiliza el parámetro.

Manejo de cadenas

Atari BASIC copió el sistema de manejo de cadenas de Hewlett-Packard BASIC , [24] donde el tipo de datos básico es un solo carácter y las cadenas son matrices de caracteres. Internamente, una cadena se representa mediante un puntero al primer carácter de la cadena y su longitud. Para inicializar una cadena, se debe dimensionar con su longitud máxima. Por ejemplo:

10 DIM A$ ( 20 ) 20 IMPRIMIR "INGRESAR MENSAJE: " ; 30 INGRESAR A$ 40 IMPRIMIR A$        

En este programa, se reserva una cadena de 20 caracteres y se truncarán todos los caracteres que excedan la longitud de la cadena. La longitud máxima de una cadena es de 32.768 caracteres. No se admiten matrices de cadenas.

Se accede a una cadena mediante funciones de indexación de matrices o segmentación . A$(1,10)Devuelve una cadena de los primeros 10 caracteres de A$. Las matrices están indexadas en 1, por lo que una cadena de longitud 10 comienza en 1 y termina en 10. Las funciones de segmentación simplemente establecen punteros a los puntos de inicio y fin dentro de la memoria asignada existente.

Las matrices no se inicializan, por lo que una matriz numérica o una cadena contienen los datos que había en la memoria cuando se asignaron. El siguiente truco permite una inicialización rápida de cadenas y también es útil para limpiar grandes áreas de memoria de basura no deseada. Las matrices numéricas solo se pueden limpiar con un bucle FOR...NEXT:

10 REM Inicializa A$ con 1000 caracteres de X 20 DIM A$ ( 1000 ) 30 A$ = "X" : A$ ( 1000 ) = A$ : A$ ( 2 ) = A$    

La concatenación de cadenas funciona como en el siguiente ejemplo. La cadena de destino debe ser lo suficientemente grande como para contener la cadena combinada o se producirá un error:

10 DIM A$ ( 12 ), B$ ( 6 ) 20 A$ = "Hola " : B$ = "¡ahí!" 30 A$ ( LEN ( A$ ) + 1 ) = B$ 40 PRINT A$      

Los valores en las instrucciones DATA están delimitados por comas y no tienen tipo. Por lo tanto, las cadenas en las instrucciones DATA no suelen estar entre comillas. Como resultado, no es posible que los elementos de datos contengan una coma, pero sí pueden incorporar comillas dobles. Los valores numéricos en las instrucciones DATA se leen como cadenas o como números según el tipo de variable en la que se leen. La instrucción READ no se puede utilizar con variables de matriz.

Entrada/salida

El sistema operativo Atari incluye un subsistema para la entrada/salida (E/S) de dispositivos periféricos conocido como CIO (Central Input/Output). La mayoría de los programas se pueden escribir independientemente del dispositivo que utilicen, ya que todos se ajustan a una interfaz común; esto era poco común en los ordenadores domésticos de la época. Se podían escribir nuevos controladores de dispositivos con bastante facilidad que estarían disponibles automáticamente para Atari BASIC y cualquier otro programa que utilizara el sistema operativo Atari, y los controladores existentes se podían sustituir o ampliar con otros nuevos. Un E: de reemplazo , por ejemplo, podría desplazar al que estaba en la ROM para proporcionar una pantalla de 80 columnas, o aprovecharlo para generar una suma de comprobación cada vez que se devuelve una línea (como la que se utiliza para verificar una lista de programas que se escriben).

Atari BASIC admite el acceso CIO con palabras reservadas OPEN #, CLOSE #, PRINT #, INPUT #, GET #, PUT #, NOTE #, POINT # y XIO # . Existen rutinas en el sistema operativo para funciones de dibujo de gráficos simples, pero no todas están disponibles como palabras clave específicas de BASIC. PLOT y DRAWTO para el dibujo de líneas son compatibles, mientras que un comando que proporciona relleno de área para formas geométricas lineales primitivas no lo es. La función de relleno se puede utilizar a través del punto de entrada CIO general, al que se llama utilizando el comando BASIC XIO .

La declaración BASIC OPEN # prepara un dispositivo para el acceso de E/S:

10 REM Abre el dispositivo de casete en el canal 1 para leer en BASIC 20 OPEN # 1 , 4 , 0 , "C:MYPROG.DAT"   

Aquí, OPEN # significa "asegurarse de que el canal 1 esté libre", llamar al controlador C: para preparar el dispositivo (esto pondrá las bobinas de cinta de casete en tensión y avanzará los cabezales manteniendo el reproductor de cinta de casete "en pausa"). El 4 significa "leer" (otros códigos son 8 para escritura y 12 = 8 + 4 para "lectura y escritura"). El tercer número es información auxiliar, establecida en 0 cuando no es necesaria. C :MYPROG.DAT es el nombre del dispositivo y el nombre del archivo; el nombre del archivo se ignora para el controlador de casete. Los dispositivos físicos pueden tener números (principalmente discos, impresoras y dispositivos seriales), por lo que " P1: " puede ser el trazador y " P2: " la impresora de rueda de margarita, o " D1: " puede ser una unidad de disco y " D2: " y así sucesivamente. Si no está presente, se asume 1.

La declaración LPRINT envía una cadena a la impresora.

A se lee mediante PEEK en las ubicaciones de memoria mantenidas por el controlador del teclado o abriéndolo como un archivo (por ejemplo, ). Este último espera a que se presione una tecla.OPEN 1,4,0,"K:":GET #1,A$

Al escribir DOSdesde BASIC se sale al menú de comandos de Atari DOS . Los programas no guardados se pierden a menos que se haya habilitado una función de intercambio de archivos de memoria en el disco actual. No existe ningún comando para visualizar un directorio de disco desde BASIC; esto se debe hacer saliendo al DOS.

Gráficos y sonido

Atari BASIC admite sonido (a través de la declaración SOUND ), gráficos ( GRAPHICS, SETCOLOR, COLOR, PLOT, DRAWTO ) y controladores ( STICK, STRIG, PADDLE, PTRIG ). [25] La declaración SOUND establece uno de los 4 canales de onda cuadrada del hardware con parámetros de volumen, tono y distorsión.

Las capacidades avanzadas del hardware, como una resolución de tono más alta, filtros de paso alto, sonido y formas de onda digitalizados, gráficos de reproductor/misil ( sprites ), conjuntos de caracteres redefinidos, desplazamiento y modos gráficos personalizados no son compatibles con BASIC; estos requerirán rutinas de lenguaje de máquina o instrucciones PEEK/POKE. Algunos de los 17 modos de caracteres/gráficos básicos compatibles con el hardware no pueden accederse simplemente desde BASIC en el Atari 400/800 ya que las ROM del SO no los admiten. Estos incluyen algunos modos de caracteres multicolor (modos ANTIC 4 y 5), modo de caracteres descendente (modo ANTIC 3) y los modos de 2 y 4 colores de mayor resolución (modos ANTIC C y E, 160x192 píxeles). La única forma de acceder a ellos es a través de PEEK/POKE o lenguaje de máquina, configurando los registros ANTIC y la lista de visualización manualmente. Las ROM del SO en el XL/XE agregaron soporte para estos modos, excepto para el modo ANTIC 3, que requiere un conjunto de caracteres redefinido en RAM para funcionar correctamente. [26]

Los modos de mapa de bits en BASIC normalmente están configurados para tener una ventana de texto que ocupa las últimas cuatro filas en la parte inferior de la pantalla, de modo que el usuario pueda mostrar mensajes e ingresar datos en un programa. Si se agrega un 16 al número de modo invocado mediante la declaración GRAPHICS, toda la pantalla estará en modo de mapa de bits (por ejemplo, GRAPHICS 8+16). Si se invoca el modo de mapa de bits en pantalla completa, Atari BASIC volverá elegantemente al modo de texto cuando finalice la ejecución del programa, evitando dejar al usuario con una pantalla que no responde y de la que se debe salir escribiendo un comando a ciegas o reiniciando la computadora.

Las coordenadas del mapa de bits están en el rango de 0 al máximo de filas/columnas menos uno, por lo tanto, en el Modo 6 (160x192), las coordenadas máximas para un píxel pueden ser 159 y 191. Si Atari BASIC intenta trazar más allá de las coordenadas permitidas para el modo, se produce un error de tiempo de ejecución.

Técnicas avanzadas

Etiquetas de línea

Atari BASIC permite utilizar variables numéricas y expresiones para proporcionar números de línea a comandos GOTOy GOSUB. Por ejemplo, una subrutina que limpia la pantalla se puede escribir como GOSUB CLEARSCREEN, que es más fácil de entender que GOSUB 10000.

Las cadenas como forma de manipular la memoria

Las direcciones base de una cadena se almacenan en una tabla de variables. Las direcciones de cadena se pueden redirigir para que apunten a áreas arbitrarias de la RAM. Esto permite que las rutinas de cambio rápido de memoria subyacentes a la asignación de cadenas y subcadenas se puedan aplicar desde BASIC a la memoria utilizada para la pantalla o los gráficos del jugador/misil. Esto es particularmente útil para lograr un movimiento vertical rápido de las imágenes del jugador/misil directamente desde Atari BASIC.

Acceso aleatorio a través de DATOS/RESTAURAR

Se pueden utilizar variables y expresiones numéricas como parámetro de la RESTOREdeclaración, lo que permite DATAacceder a las declaraciones de forma aleatoria a través de código como . Esto también se puede utilizar para emular matrices de cadenas estáticas: .RESTORE ROOMBASE+ROOMNUMBER:READ DESCRIPTION$, TREASURE$, EXITSRESTORE STRBASE+INDEX:READ A$:PRINT A$

Manejo de errores con TRAP

La TRAPinstrucción salta a un número de línea cuando se produce un error, lo que reduce la necesidad de realizar una comprobación manual de errores. Por ejemplo, al dibujar gráficos en la pantalla, no es necesario comprobar si las líneas van más allá de los límites de la pantalla del modo gráfico actual. Este estado de error se puede detectar y, en caso necesario, se puede gestionar el error.

Incluye

El ENTERcomando lee el código fuente de un dispositivo y lo fusiona con el programa actual, como si el usuario lo hubiera escrito. Esto permite guardar los programas en secciones mediante LIST, leyéndolos mediante ENTERpara fusionar o reemplazar el código existente. Al usar bloques de números de línea que no se superponen, los programadores pueden crear bibliotecas de subrutinas y fusionarlas en nuevos programas según sea necesario.

Código automodificable

El editor se puede configurar para leer repetidamente la entrada de la pantalla hasta que se alcance un EOF. Esto permite que un programa escriba un nuevo código de programa seguido de una CONTinstrucción en la pantalla y luego, al colocar el cursor de la pantalla al comienzo del nuevo código, STOPel programa en ejecución hace que se lea el nuevo código y luego la CONTinstrucción continúe la ejecución.

Lenguaje de máquina integrado

Atari BASIC puede llamar a subrutinas de código de máquina almacenadas en cadenas o POKEintroducidas en la memoria. El área de 256 bytes que comienza en la dirección 1536 10 (600 16 ) se utiliza a menudo para este propósito.

El código de máquina se invoca con la USRfunción. El primer parámetro es la dirección de la subrutina y los siguientes valores son parámetros. Si el código se almacena en una cadena llamada ROUTINE$se puede invocar con dos parámetros como .ANSWER=USR(ADR(ROUTINE$),VAR1,VAR2)

Los parámetros se introducen en la pila de hardware como números enteros de 16 bits en el orden especificado en la USRllamada, en orden de byte bajo y byte alto. Se introduce un byte final que indica el número de argumentos. El código de lenguaje de máquina debe eliminar estos valores antes de regresar a través de la RTSinstrucción. Se puede devolver un valor de 16 bits a BASIC colocándolo en las direcciones 212 10 y 213 10 (D4 16 y D5 16 ).

Forma Backus-Naur

Atari BASIC admitía la versión Backus–Naur . Carol Shaw la ha documentado en parte . [27] Shaw, junto con Keith Brewster, también escribió el Manual de referencia de Atari BASIC . [28] [29] [30]

Actuación

En teoría, el BASIC de Atari debería funcionar más rápido que los BASIC contemporáneos basados ​​en el patrón MS. Como el código fuente está completamente tokenizado cuando se ingresa, todos los pasos de tokenización y análisis ya están completos. Incluso las operaciones matemáticas complejas están listas para ejecutarse, con cualquier constante numérica ya convertida al formato interno de 40 bits, y los valores de las variables se buscan por dirección en lugar de tener que buscarlos. [e] En la práctica, el BASIC de Atari es más lento que la mayoría de los otros BASIC para computadoras domésticas , a menudo por una cantidad considerable. [31]

En dos pruebas de rendimiento muy utilizadas en la época, la Sieve of Eratosthenes de la revista Byte y la prueba de rendimiento de Creative Computing escrita por David H. Ahl , la Atari terminó cerca del final de la lista en términos de rendimiento, y fue mucho más lenta que la Apple II y la PET contemporáneas , [32] a pesar de tener la misma CPU funcionando a aproximadamente el doble de velocidad. Terminó detrás de máquinas más lentas como la ZX81 e incluso algunas calculadoras programables. [33]

La mayor parte de la lentitud del lenguaje se debe a tres problemas. [31]

La primera es que las rutinas matemáticas de punto flotante están mal optimizadas. En la prueba comparativa Ahl, una operación de un solo exponente fue responsable de gran parte del pobre desempeño de la máquina. [31] La conversión entre números enteros de punto flotante y de 16 bits también es particularmente lenta. Internamente, estos números enteros se utilizan para números de línea e indexación de matrices, junto con algunas otras tareas, pero los números en el programa tokenizado se almacenan en formato decimal codificado en binario (BCD). [34] Siempre que se encuentra uno de estos, como el número de línea en GOTO 100, el valor BCD se convierte a un entero, lo que puede tardar hasta 3500 microsegundos. [35]

Otro problema es cómo Atari BASIC implementa las bifurcaciones. Para realizar una bifurcación en un GOTOo GOSUB, el intérprete busca en todo el programa el número de línea correspondiente. [36] Por el contrario, las versiones contemporáneas de BASIC derivados de MS buscarían hacia adelante desde la línea actual si el número de línea del objetivo de la bifurcación fuera mayor, mejorando así el rendimiento de la bifurcación aproximadamente dos veces en promedio.

Un problema relacionado y más serio es la implementación de bucles FOR.... Cuando se ejecuta una sentencia, Atari BASIC registra su número de línea. Cada vez que se alcanza, busca esa línea en todo el programa, a pesar de que se encuentra en el mismo lugar que la última vez. [31] Todos los demás BASIC, en cambio, registran la ubicación de memoria de la sentencia y pueden volver a ella inmediatamente sin tener que buscar.NEXTFORNEXTFOR

La razón de este pobre desempeño se ilustra mejor con una cita de uno de sus principales autores, Bill Wilkinson, quien en 1982 afirmó:

Personalmente, nunca he estado seguro de que sea necesario que un lenguaje interpretado (por ejemplo, BASIC) sea rápido. Los autores... han afirmado que Atari BASIC es el lenguaje más lento jamás creado. Mi primer impulso fue decir: "¿A quién le importa?" [37]

Se puede contrastar esta filosofía con la del Apple BASIC de Steve Wozniak para el Apple I original , que fue diseñado específicamente para tener el rendimiento necesario para escribir juegos:

Después de diseñar juegos arcade de hardware, sabía que poder programarlos en BASIC iba a cambiar el mundo. [38]

En la plataforma surgieron varios BASIC de terceros que solucionaban algunos o todos estos problemas. Entre ellos se encontraba el propio BASIC XL de Wilkinson , que redujo el tiempo de la prueba de referencia Byte de 194 a 58 segundos, [31] más de tres veces más rápido. En la prueba de referencia Ahl, Atari BASIC requirió 405 segundos, mientras que exactamente el mismo código en Turbo-BASIC XL tardó 41,6 segundos, una mejora de un orden de magnitud. [39]

Diferencias con Microsoft BASIC

Palabras clave

Véase también

Notas

  1. ^ AppleSoft BASIC ocupaba las ubicaciones de memoria $D000 a $F7FF, un total de 10240 bytes.
  2. ^ Commodore BASIC utilizó dos áreas principales de memoria, $A000-$BFFF y $E000-$E4D2. [9]
  3. ^ Applesoft estuvo en el área desde $D000-$F7FF, incluida la biblioteca FP. [10]
  4. ^ Aunque el árbol de análisis se implementa como un conjunto de tablas, lo cual es en realidad un detalle de implementación.
  5. ^ Esta es la razón por la que los MS-BASIC solo tienen dos letras significativas en los nombres de las variables: se almacenan en una lista con solo dos bytes de ASCII para el nombre para mejorar el tiempo de búsqueda.

Referencias

Citación

  1. ^ de Lorenzo, Mark (2017). Bucle sin fin: la historia del lenguaje de programación BASIC . Filadelfia: SE Books. pág. 106. ISBN 978-1974-27707-0.
  2. ^ Wilkinson, O'Brien y Laughton 1983.
  3. ^ Decuir 2004.
  4. ^ abcde Wilkinson 1982, pág. ix.
  5. ^ Steil, Michael (20 de octubre de 2008). "Cree su propia versión de Microsoft BASIC para 6502". Requiere algo de ensamblaje .
  6. ^ Wilkinson 1982, págs. iv–v.
  7. ^ Cromemco 1978.
  8. ^ Cromemco 1978, págs. 2, 3.
  9. ^ "Mapa de la memoria".
  10. ^ "Mapa de memoria – Apple II con Applesoft BASIC cargado".
  11. ^ desde Wilkinson 1982, pág.
  12. ^ desde Wilkinson 1982, pág. x.
  13. ^ Cherry, Charles (junio de 1987). "BASIC Bonanza". Antic .
  14. ^ Wilkinson 1982, pág. vi.
  15. ^ ab "Atari BASIC Bugs". Compute! . Julio de 1986. pág. 10.
  16. ^ ab Radcliff, Matthew (septiembre de 1985). "Revision C Converter". Antic . Consultado el 8 de julio de 2023 .
  17. ^ abcd Chadwick 1985, pág. 230.
  18. ^ Chadwick 1985, págs. 250–251.
  19. ^ Hardy, Bob (febrero de 1993). "Keycode Getter". Atari Classics . pág. 18.
  20. ^ Manual 1980, Apéndice B.
  21. ^ abc Crawford 1982, pág. 10.3.
  22. ^ Crawford 1982, pág. 10.6.
  23. ^ Wilkinson, O'Brien y Laughton 1983, pág. 5.
  24. ^ Manual de referencia de HP 2000/Access BASIC (PDF) . Hewlett Packard. Mayo de 1976. págs. e.
  25. ^ Manual 1980, pág. 54.
  26. ^ "ATR: cap.15: Mostrar listas".
  27. ^ Shaw, Carol (18 de abril de 1980). Atari BASIC BNF - Backus–Naur Form (Memorando interno). Atari.
  28. ^ "El primer libro de Atari de Compute!". www.atariarchives.org . Consultado el 11 de septiembre de 2024 . Carol Shaw, Keith Brewster. MANUAL DE REFERENCIA BÁSICA. borrador, Atari, Inc., Sunnyvale, CA (1979)
  29. ^ Edwards, Benj (12 de octubre de 2011). "Entrevista de VC&G: Carol Shaw, la primera desarrolladora de videojuegos de Atari". Tenían un manual para Atari BASIC [para Atari 800] y alguien escribió un manual bastante cursi que se suponía que iba a ser muy gracioso, pero tenía muchos errores técnicos. Terminé reescribiendo el manual . Consultado el 11 de septiembre de 2024 .
  30. ^ "Mujeres en tecnología: la revolucionaria carrera de la pionera de los videojuegos Carol Shaw". blog.avast.com . Consultado el 11 de septiembre de 2024 .
  31. ^ abcde Wilkinson 1985, pág. 139.
  32. ^ Ahl, David (noviembre de 1983). "Prueba comparativa de referencia". Creative Computing . págs. 259–260.
  33. ^ Ahl, David (enero de 1984). "Punto de referencia de la informática creativa". Creative Computing . pág. 12.
  34. ^ Wilkinson, O'Brien y Laughton 1983, pág. 17.
  35. ^ Crawford 1982, pág. 8.45.
  36. ^ Winner, Lane (1982). "De Re Atari, Capítulo 10: Atari BASIC". Atari, Inc.
  37. ^ Wilkinson, Bill (septiembre de 1982). "Insight: Atari". Compute! . pág. 116.
  38. ^ Williams, Gregg; Moore, Rob (diciembre de 1984). "La historia de Apple / Parte 1: Historia temprana". Byte . pág. A71.
  39. ^ "¿El punto de referencia de Ahl?". 28 de noviembre de 2007.

Bibliografía

Enlaces externos