Intérprete BASIC

Un ejemplo de escribir un programa popular en un intérprete BASIC (en este caso, HAMURABI)

Un intérprete BASIC es un intérprete que permite a los usuarios ingresar y ejecutar programas en el lenguaje BASIC y fue en la primera parte de la era de las microcomputadoras, la aplicación predeterminada que las computadoras arrancaban. Se esperaba que los usuarios usaran el intérprete BASIC para escribir programas o para cargar programas desde el almacenamiento (inicialmente casetes y luego disquetes).

Los intérpretes BASIC son de importancia histórica. El primer producto que comercializó Microsoft fue un intérprete BASIC (el Altair BASIC), que allanó el camino para el éxito de la empresa. Antes de Altair BASIC, las microcomputadoras se vendían como kits que debían programarse en código de máquina (por ejemplo, la Apple I). Durante el período de Altair, los intérpretes BASIC se vendieron por separado, convirtiéndose en el primer software vendido a individuos en lugar de organizaciones; Apple BASIC fue el primer producto de software de Apple. Después del MITS Altair 8800, se esperaba que las microcomputadoras se enviaran con sus propios intérpretes BASIC (por ejemplo, el Apple II, que tenía múltiples implementaciones de BASIC). Una reacción contra el precio de Altair BASIC de Microsoft también condujo al desarrollo temprano de software colaborativo, para las implementaciones Tiny BASIC en general y el Palo Alto Tiny BASIC específicamente.

Los intérpretes BASIC dejaron de usarse a medida que las computadoras crecieron en poder y sus programas asociados crecieron demasiado para escribirlos y ser un formato de distribución razonable. El software vino cada vez más precompilado y transmitido en disquete, en línea o BBS, lo que hace que la necesidad de un lenguaje estandarizado subyacente sea menos importante. Además, los intérpretes de comandos cada vez más sofisticados como MS-DOS y la GUI del Apple Macintosh se convirtieron en la principal interfaz de usuario, y la necesidad de que BASIC actuara como interfaz de línea de comandos desapareció. El uso de intérpretes BASIC como lenguaje principal e interfaz para los sistemas había desaparecido en gran medida a mediados de la década de 1980.

Historia

BASIC ayudó a impulsar la era del tiempo compartido, se convirtió en la corriente principal en la era de las microcomputadoras, luego se desvaneció para convertirse en una aplicación más en la era del DOS y la GUI, y hoy sobrevive en algunos nichos relacionados con el desarrollo de juegos, la retrocomputación y la enseñanza.

La era del tiempo compartido

Implementado por primera vez como un sistema de compilación y ejecución en lugar de un intérprete, BASIC surgió como parte de un movimiento más amplio hacia los sistemas de tiempo compartido. General Electric, después de haber trabajado en el sistema de tiempo compartido de Dartmouth y su Dartmouth BASIC asociado, escribió su propio sistema operativo subyacente y lanzó un sistema de tiempo compartido en línea conocido como Mark I, presentando un compilador BASIC (no un intérprete) como uno de sus principales puntos de venta. Otras empresas en el campo emergente rápidamente siguieron su ejemplo. Para principios de la década de 1970, BASIC era en gran medida universal en las computadoras centrales de propósito general.​

El sistema HP 2000 fue diseñado para ejecutar BASIC de tiempo compartido como su tarea principal.

BASIC, como un lenguaje simplificado diseñado con la edición de línea integrada en mente, se adaptaba naturalmente a la migración al mercado de las minicomputadoras, que estaba surgiendo al mismo tiempo que los servicios de tiempo compartido. Estas máquinas tenían una memoria principal muy pequeña, tal vez tan pequeña como 4 KB en la terminología moderna, y carecían del almacenamiento de alto rendimiento, como el disco duro, que hace que los compiladores sean prácticos. Por el contrario, un intérprete requeriría menos recursos informáticos, a expensas del rendimiento. En 1968, Hewlett Packard introdujo el HP 2000, un sistema basado en su intérprete HP Time-Shared BASIC.​ En 1969, Dan Paymar y Ira Baxter escribieron otro de los primeros intérpretes BASIC para Data General Nova.​

Uno de los que se resistieron fue Digital Equipment Corporation (DEC), el proveedor líder de minicomputadoras. Habían lanzado un nuevo lenguaje conocido como FOCAL, basado en el anterior JOSS. JOSS era similar a BASIC en muchos aspectos, y FOCAL era una versión diseñada para ejecutarse en sistemas de memoria muy pequeña, especialmente el PDP-8, que a menudo se entregaba con 4 KB de memoria principal. A fines de la década de 1960, los vendedores de DEC, especialmente en el departamento de ventas educativas, descubrieron que sus clientes potenciales no estaban interesados ​​en FOCAL y buscaban sus sistemas en otra parte. Esto llevó a David H. Ahl a contratar a un programador para desarrollar un BASIC para el PDP-8 y otras máquinas DEC. Dentro del año, todo interés en alternativas como JOSS y FOCAL había desaparecido.​

La era de las microcomputadoras

La introducción de las primeras microcomputadoras a mediados de la década de 1970 continuó el crecimiento explosivo de BASIC, que tenía la ventaja de que era bastante conocido entre los jóvenes diseñadores y aficionados a la informática que se interesaron por las microcomputadoras, muchos de los cuales había visto BASIC en minis o mainframes. BASIC era uno de los pocos lenguajes que era lo suficientemente de alto nivel para ser utilizado por personas sin capacitación y lo suficientemente pequeño como para caber en las microcomputadoras de la época. En 1972, HP presentó la calculadora de escritorio programable HP 9830A con un intérprete BASIC Plus en memoria de solo lectura (ROM).​

En junio de 1974, Alfred Weaver, Michael Tindall y Ronald Danielson de la Universidad de Illinois en Urbana-Champaign demostraron que era posible producir "un intérprete de lenguaje BASIC para el microprocesador Intel 8008", en su artículo del mismo nombre, aunque su aplicación se implementó en un simulador 8008 para el IBM 360/75 y requería 16 KB.​

Altair BASIC 8K en cinta de papel.

En enero de 1975, se anunció el Altair 8800 y provocó la revolución de las microcomputadoras. Una de las primeras versiones de BASIC para microcomputadoras fue coescrita por Gates, Allen y Monte Davidoff para su compañía recién formada, Micro-Soft. Fue lanzado por MITS en formato cinta perforada para el Altair 8800 poco después de la máquina misma,​ mostrando BASIC como el lenguaje principal para las primeras microcomputadoras.

En marzo de 1975, Steve Wozniak asistió a la primera reunión del Homebrew Computer Club y comenzó a formular el diseño de su propia computadora. Los miembros del club estaban entusiasmados con el Altair BASIC.​ Wozniak concluyó que su máquina tendría que tener un BASIC propio. En ese momento trabajaba en Hewlett Packard y usaba su dialecto de minicomputadora, HP Time-Shared BASIC, como base para su propia versión. Integer BASIC se lanzó en casete para el Apple I y se suministró en ROM cuando se comenzó a vender el Apple II en el verano de 1977.​

Otros miembros del Homebrew Computer Club comenzaron a circular copias de Altair BASIC en cinta de papel, lo que provocó que Gates escribiera su Carta abierta a los aficionados, quejándose de este ejemplo primigenio de piratería de software. En parte como respuesta a la carta de Gates, y en parte para hacer un BASIC aún más pequeño que funcionaría de manera útil en máquinas de 4 KB,​ Bob Albrecht instó a Dennis Allison a escribir su propia versión del lenguaje. Cómo diseñar e implementar una versión simplificada de un intérprete para el lenguaje BASIC se trató en artículos de Allison en los tres primeros números trimestrales de boletín People's Computer Company publicado en 1975 e implementaciones con código fuente publicadas en Dr. Dobb's Journal. Esto condujo a una amplia variedad de Tiny BASIC con funciones adicionales u otras mejoras, con conocidas versiones de Tom Pittman y Li-Chen Wang, ambos miembros del Homebrew Computer Club.​ Tiny BASIC se publicó abiertamente y Wang acuñó el término «copyleft» para alentar a otros a copiar su código fuente. Aficionados y profesionales crearon sus propias implementaciones, convirtiendo a Tiny BASIC en un ejemplo de un proyecto de software libre que existía antes del movimiento de software libre.

Muchas empresas desarrollaron intérpretes BASIC. En 1976, SCELBI presentó SCELBAL para el 8008<​ y la Universidad de Idaho y el Laboratorio Lawrence Livermore anunciaron que estaría publicando en el dominio público LLL BASIC, que incluía soporte de coma flotante.​ En 1977, las Apple II y TRS-80 Model I tenían dos versiones de BASIC, una versión más pequeña introducida con los lanzamientos iniciales de las máquinas y una versión con licencia de Microsoft presentada más tarde a medida que aumentaba el interés en las plataformas.

Hello World, con video inverso y carácter de campana, primero ejecutado y luego listado en Applesoft BASIC

Microsoft portó su intérprete al MOS 6502, que rápidamente se convirtió en uno de los microprocesadores más populares de la era de los 8 bits. Cuando comenzaron a aparecer nuevas microcomputadoras, como la Commodore PET, sus fabricantes licenciaron un Microsoft BASIC personalizado para las capacidades del hardware. En 1978, MS BASIC era un estándar «de facto» y prácticamente todas las computadoras domésticas de la década de 1980 lo incluían en la ROM. En 1980, como parte de un acuerdo de licencia más grande que incluía otros lenguajes y PC DOS, IBM rechazó una propuesta de Atari y en su lugar obtuvo la licencia de MS-BASIC sobre su propia implementación, lanzando finalmente cuatro versiones de IBM BASIC, cada uno mucho más grande que los intérpretes anteriores (por ejemplo, el cartucho BASIC ocupaba 40 KB).​ Don Estridge, líder del IBM PC, dijo: «IBM tiene un BASIC excelente: es bien recibido, se ejecuta rápido en computadoras centrales y es mucho más funcional que los BASIC de microcomputadora... Pero [su] número de usuarios era infinitesimal en comparación con el número de usuarios de Microsoft BASIC. Microsoft BASIC tenía cientos de miles de usuarios en todo el mundo. ¿Cómo vas a discutir eso?».​ (Consulte Microsoft BASIC para conocer el historial posterior de estas diferentes implementaciones).

Muchos vendedores «discutieron con eso» y usaron otras firmas o escribieron sus propios intérpretes. En septiembre de 1978, Shepardson Microsystems estaba terminando Cromemco 16K Structured BASIC para las máquinas Cromemco bus S-100 basadas en Z80.​​ Paul Laughton y Kathleen O'Brien luego crearon Atari BASIC​ esencialmente como una versión anterior de Cromemco BASIC portada al 6502.​ En 1979, Warren Robinett desarrolló el cartucho BASIC Programming (Programación BASIC) para Atari, Inc., aunque solo admitía programas con 9 líneas de código (64 caracteres en total). También en 1979, Texas Instruments lanzó TI-BASIC con su TI-99/4, que vendería casi 3 millones de sistemas cuando se renovara como TI-99/4A. Sinclair BASIC fue desarrollado para el ZX-80 por John Grant y Steve Vickers de Nine Tiles. En 1980, Sophie Wilson de Acorn Computers desarrolló Atom BASIC, que luego se convirtió en BBC BASIC, uno de los primeros intérpretes en ofrecer programación estructurada en BASIC, con los procedimientos y funciones llamados DEF PROC/DEF FN, bucles REPEAT UNTIL y estructuras IF THEN ELSE inspiradas en COMAL.​​ Jan Jones desarrolló SuperBASIC, otro BASIC británico compatible con la programación estructurada, para el Sinclair QL. En 1983, Randall Hyde desarrolló SmartBASIC para Coleco Adam.​ Richard Clayton, Chris Hall y Paul Overell desarrollaron Mallard BASIC para el BBC Micro y Locomotive BASIC para el Amstrad CPC, ambos soportaban comandos para el sistema de archivos indexado del ISAM.​ En 1985, MetaComCo lanzó ABasiC para la Amiga y el ST BASIC para la Atari ST.

En 1978, David Lien publicó la primera edición de The BASIC Handbook: An Encyclopedia of the BASIC Computer Language, que documenta palabras clave en más de 78 computadoras diferentes. En 1981, la segunda edición documentó palabras clave de más de 250 computadoras diferentes, mostrando el crecimiento explosivo de la era de las microcomputadoras.​

Los intérpretes como aplicaciones

Con el surgimiento de los sistemas operativos de disco y las posteriores interfaces gráficas del usuario, los intérpretes BASIC se convirtieron en una más de las aplicaciones, en lugar de proporcionar el primer entorno que un usuario podía ver al encender una computadora.

En 1983, debutó la computadora portátil TRS-80 Model 100, con su implementación del Microsoft BASIC que fue notable por dos razones. Primero, los programas se editaron usando el editor de texto simple, TEXT, en lugar de escribirlos línea por línea (pero aún se requerían los números de línea).​ Segundo, este fue el último producto de Microsoft que Bill Gates desarrolló personalmente.​​

También en 1983, Microsoft comenzó a empaquetar GW-BASIC con DOS. Funcionalmente idéntico a IBM BASICA, su intérprete BASIC era un ejecutable completamente autónomo y no necesitaba el ROM Cassette BASIC que se encuentra en el IBM PC original. Según Mark Jones Lorenzo, dado el alcance del lenguaje, «GW-BASIC es sin duda el "ne plus ultra" de la familia BASIC con numeración de líneas de Microsoft que se remonta al Altair, y tal vez incluso de los BASIC con numeración de línea en general».​ Con el lanzamiento de MS-DOS 5.0, QBasic ocupó el lugar de GW-BASIC.

MacBASIC presentaba un entorno de desarrollo completamente interactivo para la computadora Macintosh original, y fue desarrollado por Donn Denman,​ Marianne Hsiung, Larry Kenyon y Bryan Stearns.​ MacBASIC se lanzó como software beta en 1985 y se adoptó para su uso en lugares como el departamento de informática del Dartmouth College, para su uso en un curso de introducción a la programación. Estaba condenado a ser el segundo BASIC desarrollado por Apple «matado» para favorecer a un BASIC de Microsoft. En noviembre de 1985, Apple canceló abruptamente el proyecto como parte de un acuerdo con Microsoft para extender la licencia del BASIC en el Apple II.​

BASIC llegó a algunos sistemas de videojuegos, como Nintendo Famicom.

Los intérpretes de BASIC no fueron solo un desarrollo estadounidense/británico. En 1984, Hudson Soft lanzó Family BASIC en el mercado japonés para la consola de videojuegos Family Computer de Nintendo, una implementación que sólo trabajaba con números enteros diseñada para la programación de juegos, basada en Hudson Soft BASIC para el Sharp MZ80 (con palabras clave en inglés).​ El Turbo-BASIC XL es un superconjunto compatible de Atari BASIC, desarrollado por Frank Ostrowski y publicado en la edición de diciembre de 1985 de la revista de informática Happy Computer alemana, convirtiéndolo en uno de los últimos intérpretes publicados como para escribir los programas únicamente. El lenguaje incluía un compilador además del intérprete y presentaba comandos de programación estructurada. Otros autores lanzaron varias versiones modificadas que funcionan con diferentes sistemas DOS. En Francia, François Lionet y Constantin Sotiropoulos desarrollaron dos intérpretes BASIC con un enfoque en multimedia: STOS BASIC para el Atari ST, en 1988,​ y AMOS BASIC para Commodore Amiga, en 1990.

En mayo de 1991, Microsoft lanzó Visual Basic, un lenguaje de programación de tercera generación dirigido por eventos, conocido por su modelo de programación de Component Object Model (COM, Modelo de objetos componentes).​ Visual Basic admite el desarrollo rápido de aplicaciones (RAD) de interfaz gráfica de usuario (GUI), acceso a base de datos usando Data Access Objects, Remote Data Objects u ActiveX Data Objects, y creación de controles y objetos ActiveX. Visual Basic se utilizó para desarrollar aplicaciones internas propietarias, así como aplicaciones publicadas.

BASIC de nicho

En 1993, Microsoft lanzó Visual Basic for Applications, un lenguaje de scripting para aplicaciones de Microsoft Office, que reemplaza y amplía las capacidades de programación específica de los lenguajes macro, como el WordBASIC de Word (que se introdujo en 1989).

En 1996, Microsoft lanzó VBScript como una alternativa a JavaScript para agregar funcionalidad interactiva del lado del cliente a las páginas web vistas con Internet Explorer.​

En 1999, Benoît Minisini lanzó Gambas como una alternativa para los desarrolladores de Visual Basic que habían decidido migrar a Linux.​

En 2000, Lee Bamber y Richard Vanner lanzaron DarkBASIC, un sistema de creación de juegos para Microsoft Windows, con IDE y herramientas de desarrollo.​

En 2001, se lanzó SmallBASIC para Palm PDA.​ Otro intérprete de BASIC para Palm fue HotPaw BASIC, una rama de Chipmunk Basic.

En 2002, Emmanuel Chailloux, Pascal Manoury y Bruno Pagano publicaron un Tiny BASIC como ejemplo de desarrollo de aplicaciones con Objective Caml.​

En 2011, Microsoft lanzó Small Basic (distinto de SmallBASIC), junto con un plan de estudios de enseñanza​ y una guía introductoria,​ diseñado para ayudar a los estudiantes que han aprendido un lenguaje de programación visual como Scratch a aprender programación basada en texto.​ El IDE asociado proporciona un entorno de programación simplificado con funciones como resaltado de sintaxis, completado de código inteligente y acceso a la documentación del editor.​ El lenguaje tiene solo 14 palabras clave.​ En 2019, Microsoft anunció Small Basic Online (SBO), que permite a los estudiantes ejecutar programas desde un navegador web.​​

En 2014, Robin H. Edwards lanzó Arduino BASIC para Arduino, y ahora es una implementación ampliamente bifurcada.​ Otra implementación que usa el mismo nombre fue adaptada de Palo Alto Tiny BASIC en 1984 por Gordon Brandly para su Tiny BASIC 68000, luego portado a C por Mike Field.​

Mobile BASIC para Android

Muchos intérpretes BASIC ahora están disponibles para smartphones y tabletas a través de la App Store de Apple o la tienda Google Play para Android.

Hoy en día, la codificación de intérpretes BASIC se ha convertido en parte del pasatiempo de la retroinformática. Los lenguajes de programación de nivel superior en sistemas con mucha RAM han simplificado la implementación de intérpretes BASIC. Por ejemplo, la gestión de línea es simple si su lenguaje de implementación admite matrices dispersas, la gestión de variables es simple con matrices asociativas y la ejecución del programa es fácil con funciones eval. Como ejemplos, vea el proyecto de código abierto Vintage BASIC, escrito en Haskell​ o el OCaml Tiny BASIC.

Ventas y distribución

Inicialmente, los intérpretes se incluían con el hardware o se desarrollaban como un servicio personalizado, antes de que a finales de la década de 1960 surgiera una industria que producía software empaquetado de forma independiente para organizaciones.​ Los intérpretes BASIC primero se vendieron por separado de las microcomputadoras, y luego se incluían con estas antes de volver a venderse como aplicaciones seapradas en la era del DOS.

Texto

Año	Soporte	Ejemplo
1975	Cinta de papel	Altair BASIC
1975	Programa para tipear	Tiny BASIC ampliado
1976	Casete	Apple I BASIC
1977	ROM de disquete	MICRO BASIC
1977	ROM	Integer BASIC
1983	disquete	GW-BASIC
1995	CD-ROM	Visual Basic 4.0
2008	tienda de aplicaciones	Varios

A medida que el mercado cambió a ROM, el tamaño de la ROM llegó a dominar las decisiones sobre qué tan grande podría ser un intérprete BASIC. Debido a que la RAM se vendía como chips de 4 KB, Altair BASIC se empaquetó inicialmente en ediciones separadas para 4K, 8K y 12K; esto se trasladó a los chips ROM, ya que los fabricantes decidirían cuántos chips ROM podrían incluir en su diseño, debido al precio final y otras limitaciones.

Compiladores vs intérpretes

Compiladores vs. Intérpretes

Aspecto	Compilador	Intérprete
Optimizado para	Rendimiento	Uso de memoria
Velocidad de ejecución	más rápido	Más lento
Uso de memoria	más alto	Más bajo
Almacenamiento secundario	Obligatorio	Opcional
Comprobación de errores	Antes de la ejecución	Durante la ejecución
Código fuente	No incrustado en ejecutable	Requerido para ejecutar

La primera implementación de BASIC, Dartmouth BASIC, fue un compilador. Generalmente, los compiladores examinan el programa completo en un proceso de múltiples pasos y producen un segundo archivo que es directamente ejecutable en el lenguaje de máquina subyacente de la computadora host sin referencia al código fuente. Este código a menudo se compone de llamadas a rutinas escritas previamente en el sistema en tiempo de ejecución del lenguaje. El ejecutable normalmente será más pequeño que el código fuente que lo creó.

La principal desventaja de los compiladores, al menos en el contexto histórico, es que requieren grandes cantidades de memoria temporal. A medida que el compilador funciona, produce un archivo de salida cada vez mayor que se mantiene en la memoria junto con el código fuente original. La memoria adicional para búsquedas temporales, especialmente los números de línea en el caso del BASIC, se suma al requisito de memoria. Las computadoras de la época tenían cantidades muy pequeñas de memoria; en términos modernos, un mainframe típico podría tener unos 64 KB. En un sistema de tiempo compartido, el caso de la mayoría de los BASIC de la década de 1960, esa memoria se compartía entre muchos usuarios.

Para que un compilador funcionara, los sistemas tenían que tener algún tipo de almacenamiento secundario de alto rendimiento, normalmente un disco duro. La edición del programa se llevaba a cabo en un entorno dedicado que escribía el código fuente del usuario en un archivo temporal. Cuando el usuario ejecutaba el programa, el editor debía salir y ejecutar el compilador, que leía ese archivo y producía el código ejecutable, y finalmente el compilador salía y ejecutaba el programa resultante. Dividir la tarea de esta manera redujo la cantidad de memoria necesaria para cualquiera de las partes del sistema BASIC completo; en un momento dado, solo se tenía que cargar el editor, el compilador o el ejecutable, el resto estaba en el dispositivo de almacenamiento.

Mientras que los mainframes tenían pequeñas cantidades de memoria, las minicomputadoras tenían cantidades aún más pequeñas: los sistemas de 4 y 8 KB eran típicos en la década de 1960. Pero lo que es mucho más importante, las minicomputadoras por lo general carecían de cualquier forma de almacenamiento de alto rendimiento; la mayoría de los primeros diseños usaban cinta perforada como sistema de almacenamiento principal, y los sistemas de cinta magnética de almacenamiento de datos eran para el mercado de alta gama. En este entorno, un sistema que escribiera el código fuente, lo compilara y luego ejecutara el resultado hubiera demorado minutos. Debido a estas limitaciones, proliferaron los intérpretes.

En última instancia, los intérpretes realizan las mismas tareas básicas que los compiladores, leen el código fuente y lo convierten en instrucciones ejecutables que llaman a funciones de tiempo de ejecución. La principal diferencia es «cuándo» realizan las diversas tareas. En el caso de un compilador, todo el código fuente se convierte durante lo que el usuario ve como una sola operación, mientras que un intérprete convierte y ejecuta el código fuente una sentencia a la vez. El código de máquina resultante se ejecuta, en lugar de ser almacenado, luego ese código se descarta y el proceso se repite con la siguiente sentencia. Esto hace innecesario algún tipo de almacenamiento secundario mientras se construye el ejecutable. La principal desventaja es que ya no puede dividir las diferentes partes del proceso general: el código necesario para convertir el código fuente en operaciones de máquina debe cargarse en la memoria junto con el runtime necesario para realizarlo y también, en la mayoría de los casos, el editor de código fuente.

Producir un lenguaje con todos estos componentes que pueda caber en una pequeña cantidad de memoria y aún tenga espacio para el código fuente del usuario es un gran desafío, pero elimina la necesidad de almacenamiento secundario y era la única solución práctica para las primeras minicomputadoras y la mayor parte de historia de la revolución de la computadora doméstica.

Desarrollo

Diseño de lenguaje

El diseño del lenguaje para los primeros intérpretes simplemente implicaba, a menudo, hacer referencia a otras implementaciones. Por ejemplo, las referencias de Wozniak para BASIC eran un manual de HP BASIC y una copia de 101 BASIC Computer Games. Basándose en estas fuentes, Wozniak comenzó a esbozar una sintaxis para el lenguaje.​ No sabía que el BASIC de HP era muy diferente de la variedad DEC BASIC utilizada en 101 Games. Los dos lenguajes diferían principalmente en términos de manejo de cadenas y estructuras de control.​ Data General Business Basic, una implementación de números enteros únicamente, fue la inspiración para Atari BASIC.​

Por el contrario, Dennis Allison, miembro de la facultad de informática de la Universidad de Stanford, escribió una especificación para una versión simple del lenguaje.​ Se instó a Allison a crear el estándar por Bob Albrecht del Homebrew Computer Club, que había visto BASIC en minicomputadoras y sintió que sería la combinación perfecta para nuevas máquinas como la Altair. El diseño propuesto por Allison solo usaba aritmética de enteros y no admitía matrices ni manipulación de cadenas. El objetivo era que el programa cupiera en 2 a 3 kilobytes de memoria. El diseño general de Tiny BASIC se publicó en la edición de septiembre de 1975 del boletín People's Computer Company (PCC).

La gramática se enumera a continuación en forma Backus–Naur.​ En la lista, un asterisco («*») denota cero o más del objeto a su izquierda, excepto por el primer asterisco en la definición de «término», que es el operador de multiplicación; objetos de grupo de paréntesis; y un épsilon («<código>ε</código>») significa el conjunto vacío. Como es común en la notación gramatical del lenguaje informático, la barra vertical ("<código>|</código>") distingue las alternativas, al igual que la lista en líneas separadas. El símbolo "CR" denota un retorno de carro.

    línea ::= línea de sentencia CR | sentencia CR
 
    sentencia ::= PRINT lista-expr
                  IF expresión repetir expresión THEN sentencia
                  GOTO sentencia
                  INPUT var-lista
                  LET var = expresión
                  GOSUB expresión
                  RETURN
                  CLEAR
                  LIST
                  RUN
                  END
 
    lista-expr ::= (cadena|expresión) (,(cadena|expresión))*
 
    lista-var ::= var (, var)*
 
    expresión ::= (+|-|ε) término ((+|-) término)*
 
    término ::= factor ((*|/) factor)*
 
    factor ::= var | número | (expresión)
 
    var ::= A | B | C... | Y | Z
 
    número ::= dígito dígito*
 
    dígito ::= 0 | 1 | 2 | 3 | ... | 8 | 9
 
    repetir ::= < (>|=|ε) | > (<|=|ε) | =

Esta sintaxis, tan simple como era, agregó una innovación: GOTO y GOSUB podían tomar una expresión en lugar de un número de línea, proporcionando un GOTO asignado​ en lugar de la sentencia de cambio de la estructura ON-GOTO/GOSUB más propia de BASIC.

Sinclair BASIC usó como su definición de lenguaje el estándar American National Standards Institute (ANSI) Minimal BASIC de 1978 , pero en sí mismo era una implementación incompleta con aritmética de enteros únicamente.​ El estándar ANSI se publicó después del diseño de la primera generación de intérpretes para microcomputadoras.

Arquitectura

Componentes comunes de un intérprete BASIC:​

• E/S y manejo de interrupciones
  • Teclado y pantalla
  • Archivo de entrada/salida (si lo hay)
• Edición de rutinas
  • Línea de comandos
  • Edición y almacenamiento de programas
• Rutinas de ejecución
  • Análisis e interpretación
  • Paquete aritmético
  • Gestión de la memoria
    • Tabla de símbolos (si corresponde)
    • Recolección de basura (si la hay)

Codificación

Las primeras microcomputadoras carecían de herramientas de desarrollo y los programadores desarrollaban su código en minicomputadoras o a mano. Por ejemplo, Dick Whipple y John Arnold escribieron Tiny BASIC Extended directamente en código de máquina, usando octal.​ Robert Uiterwyk escribió a mano MICRO BASIC para el SWTPC (un sistema 6800) en un bloc de notas.​ Steve Wozniak escribió el código para Integer BASIC a mano, traduciendo las instrucciones del código ensamblador a sus código de máquina equivalentes y luego subiendo el resultado a su computadora​ (Debido a esto, el programa era muy difícil de cambiar, y Wozniak no pudo modificarlo lo suficientemente rápido para Steve Jobs, quien posteriormente obtuvo la licencia del BASIC de Microsoft.​)

Gates y Allen no tenían un sistema Altair para desarrollar y probar su intérprete. Sin embargo, Allen había escrito un emulador Intel 8008 para su empresa anterior, Traf-O-Data, que se ejecutaba en una computadora de tiempo compartido PDP-10. Allen adaptó este emulador basándose en la guía del programador de Altair, y desarrollaron y probaron el intérprete en el PDP-10 de Harvard.​ Cuando Harvard dejó de usar este sistema, Gates y Allen compraron tiempo de computadora de un servicio de tiempo compartido en Boston para completar la depuración de su programa BASIC. Gates afirmó, en su Carta abierta a los aficionados en 1976, que el valor del tiempo de computadora durante el primer año de desarrollo de software fue de US$40 000 ($190 480 en 2024)​

No es que Allen no pudiera codificar a mano en lenguaje de máquina. Durante la aproximación final al aeropuerto de Albuquerque en un viaje para hacer una demostración del intérprete, Allen se dio cuenta de que se había olvidado de escribir un programa bootstrap para leer la cinta en la memoria. Escribiendo en lenguaje de máquina 8080, Allen terminó el programa antes de que aterrizara el avión. Solo cuando cargó el programa en un Altair y vio un mensaje que le preguntaba por el tamaño de la memoria del sistema, supo que el intérprete funcionaba en el hardware de Altair.​​

Una de las versiones más populares de Tiny BASIC fue Palo Alto Tiny BASIC, o PATB para abreviar. PATB apareció por primera vez en la edición de mayo de 1976 de Dr. Dobbs, escrito en un lenguaje ensamblador personalizado con nemotecnia no estándar. Li-Chen Wang había codificado su intérprete en un sistema de tiempo compartido con un ensamblador genérico.

Una excepción al uso de ensamblaje fue el uso de ALGOL 60 para el intérprete Paisley XBASIC para sistemas grandes de Burroughs.​ Otra excepción , y programa para tipear, era BASIC clásico, escrito por Lennart Benschop en Forth y publicado en la revista holandesa Forth Vijgeblad (número 42, 1993).​

El código fuente de los intérpretes era a menudo código abierto (como con Tiny BASIC) o publicado más tarde por los autores. El código fuente completo anotado y las especificaciones de diseño de Atari BASIC se publicaron como The Atari BASIC Source Book en 1983.​

Máquinas virtuales

Algunos intérpretes BASIC fueron codificados en la representación intermedia de una máquina virtual para agregar una capa de abstracción y concisión por encima del lenguaje de máquina nativo.

Máquinas virtuales en intérpretes BASIC

Dialecto de BASIC	Lenguaje de máquina virtual	Máquina nativa
Tiny BASIC	Lenguaje Intermedio Tiny BASIC (TBIL)	6800
NIBL	Lenguaje Intermedio (IL)	SC/MP
TI BASIC	Graphics Programming Language (GPL)	TMS9900

Si bien las máquinas virtuales se habían utilizado en sistemas de compilar y ejecutar como BASIC-PLUS, solo se utilizaban para ejecutar código BASIC, no para analizarlo.​ Tiny BASIC, por el contrario, fue diseñado para implementarse como una máquina virtual que analizaba y ejecutaba (interpretaba) sentencias BASIC; en tal implementación, el intérprete de Tiny BASIC se ejecuta en un intérprete de máquina virtual.​ La longitud de todo el programa intérprete era de solo 120 operaciones de máquina virtual, que constaban de 32 comandos.​ Por lo tanto, la elección de un enfoque de máquina virtual economizaba espacio de memoria y esfuerzo de implementación, aunque los programas BASIC se ejecutaban con cierta lentitud (Consulte Tiny BASIC: Implementación en una máquina virtual para obtener un extracto y ejemplos de comandos). Si bien la intención del diseño era que Tiny BASIC usara una máquina virtual, no todas las implementación lo hicieron; entre los que sí lo hicieron se incluyen Tiny BASIC Extended, Tiny BASIC 6800,​ y NIBL.

Para su TI-99, Texas Instruments diseñó una máquina virtual con un lenguaje llamado GPL, por «Lenguaje de programación gráfica»​ (aunque ampliamente culpado por el lento rendimiento del TI-BASIC; parte del problema era que la máquina virtual estaba almacenada en la ROM de gráficos, que tenía una interfaz de 8 bits lenta).​

Un malentendido de las ROM de Apple II llevó a algunos a creer que Integer BASIC usaba una máquina virtual, un lenguaje ensamblador personalizado contenido en las ROM de Apple y conocido como SWEET16. SWEET16 se basa en bytecode que se ejecutan dentro de una máquina virtual simple de 16 bits, por lo que la memoria se puede direccionar a través de punteros indirectos de 16 bits y funciones matemáticas de 16 bits calculadas sin la necesidad de traducirlas a los instrucción fundamentales múltiples del código 6502 de 8 bits.​ Sin embargo, SWEET16 no fue utilizado por el núcleo del código BASIC, aunque más tarde se utilizó para implementar varias utilidades, como la rutina de renumeración de líneas.

Edición y almacenamiento de programas

Edición de programas

La mayoría de las implementaciones de BASIC de la época actuaron como intérprete de lenguaje y como editor de línea. Cuando se estaba ejecutando BASIC, se mostraba un símbolo del sistema > donde el usuario podía ingresar declaraciones.​ Esto se conocía como «modo directo». Al arrancar, un intérprete de BASIC pasa por defecto al modo directo.

Las declaraciones que se ingresan con números al inicio de la línea se ingresan en el almacenamiento del programa para «ejecución diferida»,​ ya sea como líneas nuevas o reemplazando cualquiera que haya tenido el mismo número anteriormente.​ Las declaraciones que se ingresan sin un número de línea se denominan comandos y se ejecutan inmediatamente. Los números de línea sin declaraciones (es decir, seguidos de un retorno de carro) eliminan una línea previamente almacenada.

Cuando un programa está presente en la memoria y el usuario escribe el comando RUN, el sistema entra en «modo indirecto». En este modo, se configura un puntero para apuntar a la primera línea del programa, por ejemplo, la línea 10. El texto original de esa línea se recupera del almacenamiento y se ejecuta como si el usuario acabara de escribirla en modo directo. El puntero luego avanza a la siguiente línea y el proceso continúa.

Diferentes implementaciones ofrecieron otras capacidades de edición de programas. Altair BASIC 8K tenía un comando EDIT para cambiar a un modo de edición para una línea. Integer BASIC, también incluía el comando AUTO para ingresar automáticamente números de línea en un número inicial dado como AUTO 100, agregando 10 al último número con cada línea nueva. AUTO 300,5 comenzaba a numerar en la línea 300 de cinco en cinco; 300, 305, etc. La numeración automática se desactivaba ingresando MAN.​ Algunos intérpretes ofrecieron comandos o utilidades de renumeración de líneas.

Tokenización y codificación de líneas

Para ahorrar RAM y acelerar la ejecución, todos los intérpretes BASIC codifican algunos caracteres ASCII caracteres de las líneas con otras representaciones. Por ejemplo, los números de línea se convierten en números enteros almacenados como bytes o palabras, y a las palabras clave se le pueden asignar tokens de un solo byte (por ejemplo, almacenar PRINT como el valor de byte 145, en MS-BASIC). Estas representaciones se volverían a convertir en texto legible al listar (LIST) el programa.

Codificación y tokenización en intérpretes BASIC

Dialecto de BASIC	Números de línea	Palabras clave	Constantes numéricas	Nombres de variables
Tiny BASIC	Sí	No	No	No
Altair BASIC	Sí	Sí	No	No
Integer BASIC	Sí	Sí	Sí	No
Atari BASIC	Sí	Sí	Sí	sí

Abreviaturas

Como alternativa a la tokenización, para ahorrar RAM, las primeras implementaciones de Tiny BASIC como Extended Tiny BASIC,​ Denver Tiny BASIC​ y MINOL​ usaban palabras clave truncadas: PR para PRINT, IN para INPUT, RET para RETURN. No se aceptaban las palabras clave completas y tradicionales.

Por el contrario, Palo Alto Tiny BASIC aceptaba palabras clave tradicionales pero permitía abreviar cualquier palabra clave a su mínima cadena única, con un punto final. Por ejemplo, PRINT podría escribirse P., aunque PR. y otras variaciones también funcionaban. Este sistema se retuvo en el LEVEL I BASIC para el TRS-80, que usaba PATB, y también se encontró en el Atari BASIC y en el BASIC de varias computadoras de bolsillo Sharp.​

Para expandir una abreviatura, el tokenizador Atari BASIC busca en su lista de palabras reservadas para encontrar la primera que coincida con la parte suministrada. Los comandos de uso más común aparecen primero en la lista de palabras reservadas, con REM al principio (se puede escribir como .). Cuando el programa es listado (comando LIST), escribirá las palabras completas. MS BASIC también permitió ? como una forma abreviada de PRINT, pero lo expandía al enumerarlo, tratándolo como una abreviatura, no como un sinónimo.

Tokenización

La mayoría de los intérpretes de BASIC realizan al menos alguna conversión del formato de texto original a varios formatos específicos de la plataforma. Tiny BASIC era simple: solo convertía el número de línea de su formato decimal a binario. Por ejemplo, el número de línea «100» se convirtió en un valor de un solo byte, $64, lo que lo hace más pequeño para almacenar en la memoria y más fácil de buscar en código de máquina (algunos diseños de Tiny BASIC permitieron números de línea de 1 a 254 o 255 solamente, aunque la mayoría usa valores de doble byte y números de línea de al menos 1 a 999). El resto de la línea se dejó en su formato de texto original.​ De hecho, Dennis Allison argumentó que, dadas las limitaciones de memoria, la tokenización requeriría más código para implementarse de lo que se ahorraría.​

MS-BASIC fue un poco más allá, convirtiendo el número de línea en un valor de dos bytes y también convirtiendo palabras clave, como FOR o PRINT, en un valor de un solo byte, el «token».​ La tokenización de Microsoft BASIC no tokenizó espacios (p. ej., PRINTA se almacenó en dos bytes, mientras que PRINT A se almacenó en tres bytes); en contraste, Sinclair BASIC mostraba un espacio después de cada palabra clave tokenizada, produciendo un código más legible. En MS BASIC, para una instrucción como 20 GOTO 100, el número de línea 20 y GOTO se tokenizaban,​ mientras que el 100 se dejó en su formato original y tenía que volver a analizarse en un número entero de 16 bits cada vez que se encontraba la línea.​

Por el contrario, Integer BASIC convertía la línea 20 GOTO 100 completamente en tokens que podían leerse y ejecutarse inmediatamente. Donde Microsoft BASIC tenía un token para la palabra clave PRINT, Integer BASIC tenía tres tokens: uno si la palabra clave no iba seguida de argumentos, uno si iba seguido de una expresión aritmética y otro si iba seguido de una cadena literal.​ Dado que Integer BASIC procesaba más del código fuente original en tokens, el tiempo de ejecución fue más rápido que las versiones que requerían un análisis adicional en tiempo de ejecución. Los literales numéricos, como el valor 500, se convertían en su representación binaria de 16 bits (dos bytes), en este caso, $01F4 hexadecimal. Para indicar que se trataba de un valor y no de una palabra clave, se insertó un solo byte entre $B0 y $B9 delante del valor de dos bytes. Los literales de cadena, como «HOLA MUNDO», se codificaron configurando el bit alto de cada carácter para que A se almacenara como $C1. Los nombres de las variables se convertían de la misma manera, con las letras codificadas para tener activado su bit alto y los dígitos del nombre representados por los correspondientes $B0 a $B9, de modo que la variable A5 se codificaba como $C1B5 (no reducido a un token).​

Llevando esto aún más lejos, el tokenizador de Atari BASIC analizaba toda la línea cuando se ingresaba o modificaba. Las constantes numéricas se analizaban en su forma interna de 48 bits y luego se colocaban en la línea en ese formato, mientras que las cadenas se dejaban en su formato original, pero con el prefijo de un byte que describe su longitud. Las variables tenían almacenamiento reservado a medida que se encontraban, y su nombre se reemplazaba con un puntero a su ubicación de almacenamiento en la memoria. Shepardson se refirió a este concepto de tokenización temprana como un «intérprete de precompilación»; las declaraciones con errores de sintaxis en realidad no se podían almacenar y se le pedía inmediatamente al usuario que las corrigiera.​

Tokenización en el teclado

Las combinaciones de teclas se usan para ingresar palabras clave BASIC.

Algunos intérpretes, como los sistemas Bally Astrocade y Sinclair, básicamente hacían que el usuario tokenizara al presionar combianciones de tecla para ingresar palabras reservadas. Los comandos más comunes necesitan solo una pulsación de tecla; por ejemplo, presionar solo P al comienzo de una línea en un Spectrum produce el comando completo PRINT. Los comandos menos frecuentes requieren secuencias de teclas más complejas: BEEP (por ejemplo) se ingresa presionando CAPS SHIFT más SYMBOL SHIFT para acceder al modo extendido (los modelos posteriores incluyen una tecla EXTENDED MODE), manteniendo presionada SYMBOL SHIFT y presionando Z. Las palabras clave están codificadas por colores en el teclado Spectrum original para indicar qué modo se requiere:​

• Blanco: solo tecla
• Rojp en la tecla misma: SYMBOL SHIFT más la tecla
• Verde encima de la tecla: EXTENDED MODE seguido de la tecla
• Rojo debajo de la tecla: EXTENDED MODE seguido de SYMBOL SHIFT más la tecla

El intérprete BASIC podía determinar rápidamente cualquier comando o función evaluando un byte (el token de palabra clave). Dado el requisito sintáctico de que cada línea comience con una palabra clave de comando (por ejemplo, LET no es opcional), al presionar una tecla para un comando al comienzo de una línea, el editor cambia del modo de comando al modo de letra. La tokenización en el teclado significaba que las palabras clave no eran «palabras reservadas» como en otros dialectos BASIC, por ejemplo, se permite definir una variable llamada PRINT y mostrar su valor con PRINT PRINT.

Muchas «computadoras de mano» utilizan de manera similar una pulsación de tecla (a veces precedida por varios tipos de teclas de mayúsculas) para producir un byte (el token de palabra clave) que representaba una palabra clave BASIC completa, como «EXP», «SQR», «IF» o «PEEK», como juegos de caracteres de la computadora de mano Sharp y TI-BASIC.

Manejo de líneas

Números de línea válidos en las primeras implementaciones de BASIC

Rango	Dialecto
1 a 254	MINOL
1 a 255	Tiny BASIC Design Note
2 a 255	Denver Tiny BASIC
0 a 999	UIUC BASIC
1 a 2045	DEC BASIC-8
0 a 32767	LLL BASIC, NIBL
1 a 32767	Apple I BASIC, Level I BASIC, Palo Alto Tiny BASIC
1 a 65535	Altair 4K BASIC, MICRO BASIC 1.3, 6800 Tiny BASIC, Tiny BASIC Extended
1 a 99999	Dartmouth BASIC
1 a 999999	SCELBAL

Los números de línea válidos variaban de una implementación a otra, pero normalmente iban del 1 al 32767.

La mayor parte de la memoria utilizada por los intérpretes de BASIC era para almacenar el listaso del programas en sí. Las declaraciones numeradas se almacenaron en orden secuencial en una matriz dispersa implementada como una colección lineal (técnicamente no es una lista ya que ningún número de línea puede aparecer más de una vez).

Muchas implementaciones de Tiny BASIC almacenaron líneas de la siguiente manera:

• Equivalente binario del número de línea (uno o dos bytes, según el rango de números de línea válidos admitidos)
• Declaración de fuente ASCII (longitud variable)
• Retorno de carro (un byte, establecido en 13)

Microsoft BASIC, comenzando con Altair BASIC, almacenó líneas de la siguiente manera:​

• Puntero a la siguiente línea (dos bytes)
• Equivalente binario del número de línea (dos bytes, sin signo)
• Declaración de fuente tokenizada (longitud variable)
• Nulo (un byte, establecido en 0)

LLL BASIC:​

• Equivalente binario del número de línea (dos bytes)
• Reenviar puntero a la siguiente línea secuencial (dos bytes)
• Longitud de la declaración de fuente ASCII (un byte)
• Declaración de fuente ASCII (longitud variable)

La longitud máxima de una línea varió: 64 caracteres en Palo Alto Tiny BASIC, incluida la representación decimal del número de línea; 120 caracteres en Atari BASIC; 128 caracteres en Integer BASIC;​ y 255 caracteres en MS-BASIC (sin incluir el número de línea).

Los intérpretes buscarían en el programa una línea a la vez, mirando cada número de línea. Si fuera más bajo que el número de línea nueva, las líneas posteriores se moverían en la memoria para dejar espacio para el espacio requerido para la línea nueva. Si tuviera el mismo número de línea y no exactamente la misma longitud, las líneas subsiguientes tendrían que moverse hacia adelante o hacia atrás​ (debido a que el orden secuencial siempre se mantuvo en la memoria, estos no eran lista enlazadas.)

En Tiny BASIC, estas búsquedas requerían verificar cada byte en una línea: el puntero se incrementaba una y otra vez hasta que se encontraba un retorno de carro, para encontrar el byte antes de la siguiente línea. En Altair BASIC y LLL BASIC, por otro lado, el puntero se colocaría al comienzo de la siguiente línea secuencial; esto era mucho más rápido, pero requería dos bytes por línea. Dado que se suponía que los programas Tiny BASIC tenían un tamaño de 4 KB o menos, esto estaba en consonancia con la filosofía de diseño general de Tiny BASIC de sacrificar el rendimiento a favor de minimizar el uso de la memoria.

Cuando el usuario ingresaba LIST en la línea de comando, el sistema pasaba por encima de la matriz de líneas, usando uno de estos métodos, convertía el número de línea nuevamente al formato decimal y luego imprimía el resto del texto en la línea, decodificando cualquier token u otras representaciones codificadas.

A medida que los desarrolladores agregaron construcciones de programación estructurada a BASIC, a menudo eliminaron la necesidad de números de línea por completo y agregaron editores de texto y, posteriormente, [[<Entorno de desarrollo integrado|entornos de desarrollo integrado]].

Variables y tipos de datos

Nombres de variables

Dartmouth BASIC y HP-BASIC limitaron los nombres de variables a un máximo de dos caracteres (ya sea una sola letra o una letra seguida de un dígito; por ejemplo, A a Z9). MS-BASIC permitía nombres de variables de una letra seguida de una letra o dígito opcional (por ejemplo, A a ZZ) pero ignoraba los caracteres subsiguientes: por lo tanto, era posible escribir inadvertidamente un programa con las variables «LOSS» (PÉRDIDA) y «LOAN» (PRÉSTAMO), que sería tratados como si fueran iguales; asignar un valor a «LOAN» sobrescribiría silenciosamente el valor previsto como «LOSS».

Integer BASIC era inusual al admitir cualquier longitud de nombre de variable (por ejemplo, SUMA, PUNTAJE, JUGADOR2), siempre que no contuviera una palabra reservada.​ Las palabras clave no se podían usar en variables en muchos de los primeros BASIC; «SCORE» se interpretaría como «SC» OR «E», donde OR era una palabra clave.

Las variables de cadena de caracteres (string) generalmente se distinguen en muchos dialectos BASIC de microcomputadoras por tener $ como sufijo a su nombre, y los valores a menudo se identifican como cadenas al estar delimitados por "comillas inglesas". Las implementaciones posteriores usarían otra puntuación para especificar el tipo de una variable: A% para entero, A! para precisión simple, y A# para precisión doble.

Con la excepción de matrices y (en algunas implementaciones) cadenas, y a diferencia de Pascal y otros lenguajes de programación más estructurados, BASIC no requiere que se declare una variable antes de que se haga referencia a ella. Por lo general, los valores predeterminados son 0 (de la precisión adecuada) o la cadena nula.

Tabla de símbolos

Debido a que Tiny BASIC solo usaba 26 variables de una sola letra, las variables podían almacenarse como una matriz sin almacenar sus nombres correspondientes, utilizando una fórmula basada en el valor ASCII de la letra como índice. Palo Alto Tiny BASIC llevó esto un paso más allá: las variables con valores de dos bytes se ubicaron en la RAM dentro del programa, desde los bytes 130 (ASCII 65, 'A', por dos) a 181 (ASCII 90, 'Z', por dos más uno para el segundo byte).​

La mayoría de los BASIC brindaban la capacidad de tener más de 26 variables y, por lo tanto, necesitaban tablas de símbolos, que reservaban capacidad de almacenamiento solo para las variables utilizadas.

En LLL BASIC, cada entrada en la tabla de símbolos se almacenaba de la siguiente manera:​

• Nombre de variable (byte 1: letra ASCII; byte 2: 0-9 ASCII o 0 binario)
• Puntero de avance (2 bytes)
• Valor (4 bytes por elemento, 1 elemento si es una variable escalar, de lo contrario, tantos elementos como DIMensiones de la matriz)

A diferencia de la mayoría de los intérpretes BASIC, UIUC BASIC tenía una función hash, codificando por la letra del nombre de la variable/función/matriz, y luego realizando una búsqueda lineal desde allí. En UIUC BASIC, una entrada de la tabla de símbolos era:​

• Indicador (bit 0: entrada en uso; bit 6: función definida por el usuario; bit 7: matriz)
• Nombre de variable (byte 1: letra ASCII; byte: 0-9 ASCII, « » o «(») o nombre de función (byte 1: letra ASCII o token 154 para FN; letra ASCII)
• Valor (5 bytes):
  • Valor de coma flotante para un escalar
  • Definición de matriz (últimos 3 bytes: dimensión superior de la primera, segunda y tercera dimensión, se supone que todo comienza en 0)
  • Función de usuario (primeros 2 bytes con la dirección de la función; el byte 3 es el desplazamiento de la tabla de símbolos al parámetro de la variable ficticia en la definición de la función).

En Atari BASIC, un conjunto de punteros (direcciones) indicaban varios datos: los nombres de las variables se almacenaban en la tabla de nombres de variables (VNTP – 82, 83₁₆) y sus valores se almacenaban en la tabla de valores de variables (señalada en VVTP – 86, 87₁₆). Al indireccionar los nombres de las variables de esta manera, una referencia a una variable necesitaba solo un byte para abordar su entrada en la tabla apropiada. Las variables de cadena tenían su propia área.

Una optimización del rendimiento de BBC BASIC incluía el uso de varias listas enlazadas para la búsqueda de variables en lugar de una sola lista larga, como en Microsoft BASIC.

Administración de memoria

Debido a la pequeña capacidad de RAM de la mayoría de los sistemas utilizados originalmente para ejecutar intérpretes BASIC, se tuvieron que emplear técnicas inteligentes de administración de memoria. Altair BASIC permite a los usuarios recuperar el espacio para las funciones de trigonometría si no se usaron durante una sesión. PATB colocó el inicio de las subrutinas más comunes al frente del programa para que las use el código de operación RST 8080 de 1 byte en lugar del código de operación CALL de 3 bytes. En LLL BASIC, algunas variables ocupaban las mismas ubicaciones de memoria, en los casos en que las diferentes variables se usaban solo en modo comando o solo en tiempo de ejecución.​

El video a menudo era direccionable a la memoria y ciertas funciones esotéricas estaban disponibles al manipular valores en valores de memoria específicos. Por ejemplo, las direcciones 32 a 35 contenían las dimensiones de la ventana de texto (a diferencia de la ventana de gráficos) en Applesoft BASIC. El comando POKE y la función PEEK (adaptado de los monitores de código de máquina, como el monitor del DECsystem-10​) proporcionó acceso directo a la memoria, para una variedad de propósitos,​ especialmente para modificar registros de desplazamiento mapeados en memoria para controlar funciones particulares de la computadora, como los periféricos de entrada/salida. Los «mapas de memoria» (en el sentido arcaico de listas de direcciones de memoria y sus funciones) eran populares para usar con PEEK y POKE, con uno de los mapas de memoria más conocidos son el libro Mapping the Atari, escrito por Ian Chadwick.

Algunas implementaciones del intérprete de Microsoft, por ejemplo, las que se ejecutan en los modelos TRS-80 I/III, requerían que el usuario especificara la cantidad de memoria que usaría el intérprete. Esto fue para permitir que se reservara una región de memoria para la instalación de subrutinas de lenguaje de máquina que pudieran ser llamadas por el programa interpretado, para una mayor velocidad de ejecución. Cuando se encienden los modelos I/III, el usuario recibe el mensaje «Memory size?» (¿Tamaño de la memoria?) para este propósito.

Matemáticas

Integer BASIC, como su nombre lo indica, utiliza enteros como base para su paquete matemático. Estos se almacenaron internamente como un número de 16 bits little-endian] (al igual que el 6502). Esto permitió un valor máximo para cualquier cálculo entre −32767 y 32767. Los cálculos que dieron como resultado valores fuera de ese rango producían un error.​

La mayoría de los intérpretes de Tiny BASIC (así como Sinclair BASIC 4K) admitían matemáticas usando solo números enteros, sin compatibilidad con coma flotante. El uso de números enteros permitió que los números se almacenaran en un formato de 16 bits mucho más compacto que podía leerse y procesarse más rápidamente que los formatos de coma flotante de 32 o 40 bits que se encuentran en la mayoría de los BASIC de la época. Sin embargo, esto limitó su uso como lenguaje de propósito general.

Las implementaciones de Business BASIC, como Data General Business Basic, también eran de solo números enteros, pero generalmente con una precisión más alta: «doble precisión», es decir, 32 bits (más o menos 2.147.483.648 ) y «triple precisión» (más o menos 1,4x10¹⁴).

A veces se usaban otros formatos de número de computadora. Por ejemplo, el MINOL Tiny BASIC admitía solo bytes sin signo,​ y el MICRO-BASIC Tiny BASIC usaba decimal codificado en binario.​ Pero la coma flotante llegaría a predominar.

Coma flotante

Una historia resume por qué la coma flotante se consideró tan importante. El prototipo original del Modelo TRS-80 corría la versión de dominio público de Li-Chen Wang de Tiny BASIC. Esto requería solo 2 KB de memoria para el intérprete, dejando un promedio de otros 2 KB libres para los programas de usuario en los diseños de memoria comunes de 4 KB de las primeras máquinas. Durante una demostración a los ejecutivos, el entonces presidente de Tandy Corporation, Charles Tandy, trató de ingresar su salario pero no pudo hacerlo. Esto se debió a que Tiny BASIC usaba enteros con signo de 2 bytes con un valor máximo de 32767. El resultado fue el pedido de matemática de coma flotante para la versión de producción.​ Esto condujo al reemplazo del código de enteros de 16 bits existente con una versión que utiliza números de coma flotante de precisión simple por Steve Leininger, empleado de Tandy.​

SCELBAL usó rutinas de coma flotante publicadas por Wadsworth en 1975 en Programación en lenguaje de máquina para el 8008, basado en un formato de 32 bits (cuatro bytes) para cálculos numéricos, con una mantisa de 23 bits, signo de 1 bit para la mantisa, un exponente de 7 bits y signo de 1 bit para el exponente. Estos se organizaron en orden inverso, con el byte menos significativo de la mantisa en el primer byte, seguido del medio y luego el byte más significativo con el signo en el bit alto. El exponente fue el último, nuevamente con el signo en el bit alto.​ El manual proporciona código ensamblador bien documentado para todo el paquete matemático, incluidos los puntos de entrada y notas de uso.​

Los consultores solían manejar aritmética de coma flotante, un dominio especializado bien estudiado y desarrollado para las aplicaciones científicas y comerciales que habían caracterizado a los mainframes. Cuando Allen y Gates estaban desarrollando Altair BASIC, su compañero estudiante de Harvard Monte Davidoff los convenció de cambiar de aritmética entera. Contrataron a Davidoff para que escribiera un paquete de coma flotante que aún pudiera caber dentro de los límites de memoria de 4 KB. Steve Wozniak recurrió a Roy Rankin de la Universidad de Stanford para implementar las funciones trascendentes LOG, LOG10 y EXP;​ sin embargo, Wozniak nunca terminó de agregar el soporte para coma flotante a Integer BASIC. LLL BASIC, desarrollado en la Universidad de Idaho por John Dickenson, Jerry Barber y John Teeter, recurrió a David Mead, Hal Brand y Frank Olken para su soporte de coma flotante soporte.​ Para UIUC BASIC, se licenció un paquete de coma flotante Datapoint 2200.​

Por el contrario, los sistemas de tiempo compartido a menudo dependían del hardware. Por ejemplo, la GE-235 fue elegida para implementar la primera versión de Dartmouth BASIC específicamente porque presentaba una «unidad aritmética auxiliar» para coma flotante y cálculos de doble precisión.​​

Los primeros intérpretes usaban formatos de 32 bits, similares al formato de coma flotante binario de precisión simple IEEE 754, que especifica:

• Bit de signo: 1 bit
• Exponente ancho: 8 bits
• Precisión de la mantisa: 24 bits (23 almacenados explícitamente)

Aquí está el valor 0,15625 almacenado en este formato:

Si bien los formatos de 32 bits eran comunes en esta era, las versiones posteriores de BASIC, comenzando con Microsoft BASIC para MOS 6502, generalmente adoptaron un formato de 40 bits (cinco bytes) para mayor precisión.​

Operadores y funciones

Los operadores infijos normalmente incluían + (suma), - (resta), * (multiplicación), / (división) y exponente utilizando el carácter ^. Las operaciones de relación incluían el conjunto estándar de =, >, <, >=, <=, y para «no igual» <> o el # inspirado en HP-TSB.​ Los operadores binarios, como AND, OR y NOT, no estaban en todas las implementaciones, y algunas tenían álgebra booleana y otras no.

La edición inicial de Dartmouth BASIC incluía las siguientes funciones: ABS (valor absoluto), ATN (arctangente), COS (coseno), EXP (e elevado a la potencia), INT (truncar cualquier valor fraccionario, devolviendo un número entero), LOG (logaritmo), RND (generador de números pseudoaleatorios), SIN (seno), SQR (raíz cuadrada) y TAN (tangente). También incluía la declaración DEF FN para declarar funciones de una línea, que luego se denominarían FNA(), FNB(), etc.

La función RND fue la función más extendida admitida en los primeros BASIC, aunque las implementaciones variaron:

• RND de Dartmouth ignoraba el parámetro y siempre devolvía un nuevo número pseudoaleatorio entre 0 y 1.
• Altair BASIC y Microsoft BASIC posteriores usaban el signo del parámetro: Para RND(X), «X<0 inicia una nueva secuencia de números aleatorios usando X. Llamar a RND con la misma X inicia la misma secuencia de números aleatorios. X=0 da el último número aleatorio generado».​
• Al no poder devolver un decimal, los BASIC de solo enteros utilizaron en su lugar el valor del parámetro, generalmente para especificar un límite superior para la aleatorización; por ejemplo, en Integer BASIC, RND(6)+1 simularía una tirada de dado, devolviendo valores del 1 al 6.
• Por el contrario, en algunos BASIC TRS-80, el parámetro era el límite superior que se podía devolver; por ejemplo, RND(6) devolvería un valor del 1 al 6, y RND(1) siempre devolvería 1.​

Matrices

La segunda versión de Dartmouth BASIC soportaba matrices y operaciones matriciales, útil para la solución de conjuntos de ecuaciones algebraicas lineales simultáneas; se admitían operaciones matriciales MAT como asignación, suma, multiplicación (de tipos de matriz compatibles) y evaluación de un determinante.

Por el contrario, Tiny BASIC, como se diseñó inicialmente, ni siquiera tenía matrices, debido a la limitada memoria principal disponible en las primeras microcomputadoras, a menudo de 4 KB, que tenía que incluir tanto el intérprete como el programa BASIC. Palo Alto Tiny BASIC agregó una sola matriz de longitud variable de números enteros, cuyo tamaño no tenía que ser dimensionado, pero ocupaba la RAM no utilizada por el intérprete o el listado del programa, A().

SCELBAL admitía varias matrices, pero juntas estas matrices no podían tener más de 64 elementos. Integer BASIC admitía matrices de una sola dimensión, limitados en tamaño solo por la memoria disponible.​ Tiny BASIC Extended admitía matrices bidimensionales de hasta 255 por 255. Altair BASIC 4K admitía solo matrices (de una dimensión), mientras que la versión 8K admitía matrices de hasta 34 dimensiones.​

Muchas implementaciones admitieron la práctica de Dartmouth BASIC de no requerir que se dimensione una matriz, en cuyo caso se suponía que tenía 11 elementos (0 a 10); por ejemplo, {{{1}}} crearía una matriz de 11 elementos como efecto secundario.

El vector de datos de las matrices varió de una implementación a otra. Por ejemplo, el vector de datos de una matriz Altair BASIC 4K:​

• Nombre de variable (2 bytes)
• Tamaño de los elementos de la matriz en bytes (2 bytes, por lo tanto 4 veces el número de elementos, que era el límite superior más uno)

Entonces la matriz se valora a sí misma:

• Valor del elemento 0 (4 bytes)
• Valor del elemento 1 (4 bytes)
• ...
• Valor del elemento N (4 bytes)

Las implementaciones que admitían matrices tenían que registrar el número de dimensiones y el límite superior de cada dimensión. Además, como algunos intérpretes tenían solo un tipo de datos (ya sea de coma flotante o entero), el vector de datos simplemente necesitaba registrar el número de dimensiones y el límite superior de cada dimensión. Los intérpretes con varios tipos de datos tenían que registrar el tipo de datos de la matriz.

Aunque Microsoft y otros BASIC admitían matrices, las operaciones de matrices no estaban integradas, sino que tenían que programarse explícitamente en los elementos de la matriz.

Cadena de caracteres

El Dartmouth BASIC original, algunos de sus descendientes inmediatos y las implementaciones de Tiny BASIC carecían de manejo de cadenas. Evolucionaron dos escuelas competidoras de manejo de cadenas, iniciadas por HP y DEC, aunque otros enfoques surgieron más tarde. Estos requirieron diferentes estrategias para su implementación.

Manejo de cadenas en intérpretes BASIC destacados

Dialecto de BASIC	Tipo	Subcadenas
HP Time-Shared BASIC	Longitud fija	Slicing
DEC BASIC-PLUS	Longitud variable	Funciones
Dartmouth BASIC Cuarta edición	Longitud variable	Indexación de matrices
Tiny BASIC	Matriz de enteros	Indexación de matrices

El manejo de cadenas más simple copió HP Time-Shared BASIC y definió las variables de cadena como matrices de caracteres que tenían que ser DIMencionadas antes de su uso. Las cadenas en HP TSB se tratan como una matriz de caracteres, hasta 72 en total, en lugar de un solo objeto de varios caracteres. De forma predeterminada, se les asigna un carácter en la memoria y, si se necesita una cadena de mayor longitud, deben declararse. Por ejemplo, DIM A$[10] configurará una cadena que puede contener un máximo de 10 caracteres.​

Se accede a las subcadenas dentro de las cadenas usando una notación «slicing»: A$(L,R) o A $[L,R], donde la subcadena comienza con el carácter más a la izquierda especificado por el índice L y continúa hasta el carácter más a la derecha especificado por el índice R, o A$[L] donde la subcadena comienza en el carácter más a la izquierda especificado por el índice L y continúa hasta el final de la cadena. TSB acepta () o [] indistintamente. Los índices de matrices y subcadenas comienzan con 1.

Esto contrasta marcadamente con los BASIC que siguen el patrón DEC que usan funciones como LEFT$(), MID$() y RIGHT$() para acceder a las subcadenas. Más tarde adoptada por ANSI BASIC, la notación de HP también se puede usar en el lado de destino de una instrucción LET o INPUT para modificar parte de un valor de cadena existente, por ejemplo 100 A$[3,5]="XYZ" o 120 B$[3]="CAMBIAR TODOS MENOS LOS DOS PRIMEROS CARACTERES", lo que no se puede hacer con las primeras implementaciones de LEFT$/MID$/RIGHT$.

Las versiones posteriores de Dartmouth BASIC incluían variables de cadena. Sin embargo, no usaron las funciones LEFT$/MID$/RIGHT$ para manipular cadenas, sino que usaron el comando CHANGE que convirtió la cadena a valores ASCII equivalentes (Posteriormente adoptada tal cual por DEC y adaptada por HP, que cambió la palabra clave a CONVERT.​) Además, se podría usar la comilla simple para convertir una constante numérica en un carácter ASCII, que permite construir una cadena en partes; A$='23 '64 '49 "DEF" produjo la cadena «ABCDEF», sin necesidad de la función CHR$().​ Dartmouth BASIC sexta edición admite SEG$ (para MID$) y POS (para INSTR).

Integer BASIC, North Star BASIC​ y Atari BASIC​ imitaba el enfoque de HP, que nuevamente contrastaba con el estilo que se encuentra en los BASIC derivados de DEC, incluido Microsoft BASIC, donde las cadenas son un tipo intrínseco de longitud variable.​

Algunas de las implementaciones de Tiny BASIC admitían una o más matrices de enteros predefinidas, que podían usarse para almacenar códigos de caracteres, siempre que el lenguaje tuviera funcionalidad para ingresar y generar códigos de caracteres (por ejemplo, Astro BASIC tenía KP y TV para este propósito).

Recolector de basura

Un ejemplo de fragmentación externa

Hacer que las cadenas utilicen una cantidad fija de memoria, independientemente del número de caracteres utilizados en ellas, hasta un máximo de 255 caracteres, podía desperdiciar memoria​ pero tenía la ventaja de evitar la necesidad de implementar la recolección de basura del montículo, una forma de gestión de memoria automática que se usa para recuperar la memoria ocupada por cadenas que no no se usan más. Las cadenas cortas que se liberaban podían almacenarse en medio de otras cadenas, evitando que esa memoria se use cuando se necesita una cadena más larga.

En las primeras microcomputadoras, con su memoria limitada y procesadores lentos, la recolección de basura BASIC a menudo podía causar pausas aparentemente aleatorias e inexplicables en medio de la operación del programa. Algunos intérpretes de BASIC, como Applesoft BASIC en la familia Apple II, escaneaban repetidamente los descriptores de cadena en busca de la cadena que tenía la dirección más alta para compactarla hacia la memoria alta, dando como resultado un rendimiento O(n²), que podía introducir pausas de varios minutos en la ejecución de programas con uso intensivo de cadenas. La recolección de basura era notoriamente lenta o incluso rotas en otras versiones de Microsoft BASIC.​ Algunos sistemas operativos que admitían tareas en segundo plano manejadas por interrupciones, como TRSDOS/LS-DOS 6.x en el TRS-80 Modelo 4, aprovechaban los períodos de inactividad del usuario (como los períodos de milisegundos entre las pulsaciones de teclas y los períodos posteriores a la actualización de la pantalla de video) para procesar la recolección de basura durante las ejecuciones del programa BASIC.

Otras funcionalidades

Gráficos y sonido

La mayoría de los intérpretes de BASIC diferían ampliamente en gráficos y sonido, que variaban dramáticamente de microcomputadora a microcomputadora. Altair BASIC carecía de gráficos o comandos de sonido, al igual que las implementaciones de Tiny BASIC, mientras que Integer BASIC proporcionó un rico conjunto de comandos.

Level I BASIC para el TRS-80 tenía el conjunto mínimo posible: CLS, para CLear Screen; SET(X,Y), que encendía una ubicación en la pantalla; RESET(X,Y), que lo apagaba; y POINT(X,Y), que devolvía 1 si una ubicación estaba iluminada, 0 si no lo estaba. Las coordenadas pueden ser cualquier expresión y van de 0 a 127 para el eje X y de 0 a 47 para el eje Y. Solo se admitía la visualización en blanco y negro.​

Por el contrario, Integer BASIC admitía gráficos en color, sonido simple y controladores de juegos. El modo de gráficos se activaba con la declaración GR y se desactivaba con TEXT.​ El dibujo era modal y normalmente se comenzaba emitiendo un comando para cambiar el color, lo que se lograba configurando una pseudovariable; COLOR=12 establecería el color del dibujo en 12, verde claro. Uno podía usar el comando PLOT 10,10 para producir un solo punto de ese color,​ HLIN 0,39 AT 20 para dibujar un línea horizontal en la fila 20 que abarcaba la pantalla, o VLIN 5,15 AT 7 para dibujar una línea vertical más corta en la columna 7.​ A=SCRN X,Y devolvía el color de la pantalla en X,Y.​​

Conjunto de gráficos de bloques de texto de la ZX-81

Los fabricantes de hardware a menudo incluían soporte patentado para semigráficos, formas simples e íconos tratados como caracteres especiales. Los ejemplos incluyeron los gráficos de bloque del ZX-81 y los símbolos de cartas de ♠, ♣, ♥ y ♦ en el conjunto de caracteres PETSCII de Commodore International. BASIC podría generar estos símbolos usando PRINT CHR$();.

Microsoft agregó muchos comandos gráficos a IBM BASIC: LINE, PSET (Pixel SET), PRESET (Pixel RESET), GET (almacena un rectángulo de la pantalla en una matriz), PUT (muestra un segmento rectangular almacenado), LOCATE (para mover el cursor de texto) y DRAW, que dibuja formas utilizando una sintaxis similar a LOGO. Bill Gates y Neil Konzen escribieron DONKEY.BAS, un juego integrado, para demostrar los gráficos en color y el sonido del intérprete.

Entrada/Salida

Otra área donde las implementaciones divergieron fue en las palabras clave para tratar con medios de almacenamiento (casetes y disquetes), entrada de teclado y controladores de juegos (si los hay).

Dado que los intérpretes de BASIC basados ​​en ROM a menudo funcionaban como shells para cargar otras aplicaciones, las implementaciones agregaron comandos relacionados con las cintas de casete (p. ej., CLOAD y CSAVE ), archivos de disco binarios (p. ej., BLOAD, BSAVE y BRUN), y programas BASIC en disco (p. ej., LOAD, SAVE y CATALOG). Las implementaciones Business Basic agregaron comandos para archivos de acceso aleatorio (Incluso los intérpretes de BASIC basados ​​en ROM no fueron diseñados o pensados ​​para ser utilizados como sistemas operativos, y las microcomputadoras más pequeñas simplemente carecían de cualquier sistema operativo.​)

Dartmouth BASIC carecía de un comando para obtener entradas desde el teclado sin pausar el programa. Para admitir videojuegos, los BASIC agregaron comandos patentados para hacerlo: INKEY$ era una función en Microsoft BASIC que devolvería una cadena vacía si no se presionaba ninguna tecla o, de lo contrario, un solo carácter; KP (para KeyPress) devolvió el valor ASCII de la entrada en Astro BASIC.

Palo Alto Tiny BASIC carecía de cadenas, pero permitía a los usuarios ingresar expresiones matemáticas como respuesta a las declaraciones INPUT; configurando variables, como Y=1; N=0, el usuario podía responder «Y» o «1» o incluso «3*2-5» en un mensaje de sí/no.

Algunos sistemas admiten controladores de juegos. Astro BASIC admite JX() (posición horizontal especificada del joystick), JY() (posición vertical del joystick), KN() (estado de la perilla) y TR() (estado de activación). Integer BASIC admitía un controlador de juego, un controlador de paleta, que tenía dos controladores en un solo conector. La posición del controlador podía leerse usando la función PDL, pasando el número del controlador, 0 o 1, como A=PDL(0):PRINT A, devolviendo un valor entre 0 y 255.​​ Integer BASIC carecía de cualquier comando personalizado de entrada/salida, y también carecía de las instrucciones DATA y el READ asociadas. Para obtener datos dentro y fuera de un programa, la funcionalidad de entrada/salida se redirigió a una zócalo de placa de expansión seleccionada con el PR#x y IN#x, que redirigía la salida o la entrada (respectivamente) al zócalo numerado. A partir de ese momento, los datos podían enviarse a la placa usando comandos PRINT convencionales y leerse usando INPUT.​ Producir sonidos era logrado mediante el comando PEEK a la ubicación asignada en la memoria de un simple «zumbador», −16336.​​

Programación estructurada

Si bien la programación estructurada, a través de ejemplos como ALGOL 58 y ALGOL 60, era conocida por Kemeny y Kurtz cuando diseñaron BASIC, adaptaron solo el bucle for, ignorando la instrucción else, bucle while, bucle de repetición, procedimientos con nombre, paso de parámetros y variables locales. Como resultado, los dialectos posteriores a menudo diferían dramáticamente en la redacción utilizada para las técnicas estructuradas. Por ejemplo, WHILE...WEND (en Microsoft BASIC), WHILE...ENDWHILE (en Turbo-BASIC XL), DO...LOOP WHILE e incluso cláusulas WHILE (ambas en BASIC-PLUS).

De las implementaciones de Tiny BASIC, solo el National Industrial Basic Language (NIBL, Lenguaje Basic Industrial Nacional) ofrecía un comando de bucle de cualquier tipo, DO/UNTIL.​ Esto fue a pesar de que el inventor de Tiny BASIC, Dennis Allison, públicamente lamentó el estado de BASIC.​

BBC BASIC fue uno de los primeros intérpretes de microcomputadoras en ofrecer programación BASIC estructurada, con procedimientos y funciones denominados DEF PROC/DEF FN, REPEAT UNTIL, bucles y estructuras IF THEN ELSE, inspiradas en COMAL. BASIC de segunda generación: por ejemplo, SBASIC (1976), BBC BASIC (1981), True BASIC (1983), Beta BASIC (1983), QuickBASIC (1985) y AmigaBASIC (1986), introdujeron una serie de características en el lenguaje relacionadas principalmente con la programación estructurada y orientada a procedimientos. Por lo general, la numeraciónde líneas se omite en el lenguaje y se reemplaza con etiquetas (para GOTO) y procedimientos para fomentar un diseño más sencillo y flexible.​ Además se introdujeron palabras clave y estructuras para soportar la repetición, selección y procedimientos con variables locales.

El siguiente ejemplo está en Microsoft QBASIC, la tercera implementación de Microsoft de un BASIC estructurado (después de Macintosh BASIC en 1984 y Amiga BASIC en 1985).​

REM ejemplo QBASIC

REM Declaración directa: permite que el código principal llame a una
REM  Subrutina que se define más adelante en el código fuente.

DECLARE SUB PrintSomeStars (StarCount!)

REM continua el programa principal
DO
   INPUT "¿Cuántas estrellas quiere? (0 para salir) ", NumStars
   CALL PrintSomeStars(NumStars)
LOOP WHILE NumStars>0
END

REM definición de la subrutina
SUB PrintSomeStars (StarCount)
   REM Este procedimiento usa una variable local llamada Stars$
   Stars$ = STRING$(StarCount, "*")
   PRINT Stars$
END SUB

Orientado a objetos

El soporte inicial para programación orientada a objetos proporcionó solo la reutilización de objetos creados con otros lenguajes, como Visual Basic y PowerBASIC, que soportaban Component Object Model de Windows. A medida que los intérpretes de BASIC continuaron evolucionando, agregaron soporte para características orientadas a objetos como métodos, constructores, asignación de memoria dinámica, propiedades y asignación temporal.

Incluye ensamblador

Las ROM de Integer BASIC también incluían un monitor de código máquina, «mini-ensamblador», y un desensamblador para crear y depurar programas en lenguaje ensamblador.​​​

Una de las características únicas de BBC BASIC era el ensamblador en línea, que permitía a los usuarios escribir programas en lenguaje ensamblador para 6502 y, más tarde, el Zilog Z80, NS32016 y ARM. El ensamblador estaba completamente integrado en el intérprete BASIC y compartía variables con él, que podían incluirse entre los caracteres [ y ], guardarse mediante *SAVE y *LOAD, y llamarse mediante los comandos CALL o USR. Esto permitió a los desarrolladores escribir no solo código en lenguaje ensamblador, sino también código BASIC para emitir lenguaje ensamblador, haciendo posible el uso de técnicas de generación de código e incluso escribir compiladores simples en BASIC.

Ejecución

Depuración

Como en la mayoría de los BASIC, los programas se iniciaban con el comando RUN y, como era común, podía dirigirse a un número de línea particular como RUN 300.​ La ejecución se puede detener en cualquier momento usando Ctrl+C​ (o BREAK como en el TRS-80) y luego reiniciar con CONTinuar (CON en Integer BASIC).​ Aprovechando las capacidades únicas de los programas interpretados (el código se procesa en tiempo real una declaración a la vez, en contraste con los compiladores), el usuario en la consola podía examinar los datos en las variables usando la declaración PRINT y cambiar dichos datos sobre la marcha, para luego reanudar la ejecución del programa.

Para la ejecución paso a paso, la instrucción TRON o TRACE podía usarse en el símbolo del sistema o colocarse dentro del programa mismo. Cuando se activaba, se mostraban los números de línea para cada línea ejecutada por el programa. La función se puede desactivar de nuevo con TROFF o NOTRACE.​

Algunas implementaciones, como los intérpretes de Microsoft para las distintas marcas de TRS-80, incluían el comando ON ERROR GOSUB. Esto redirigiría la ejecución del programa a un número de línea específico para un manejo especial de errores.

A diferencia de la mayoría de los BASIC, Atari BASIC escaneaba la línea de programa recién ingresada e informaba de inmediato los errores de sintaxis. Si se encontraba un error, el editor volvía a mostrar la línea, resaltando el texto cerca del error en video inverso.

En muchos intérpretes, incluido Atari BASIC, los errores se muestran como códigos numéricos, con las descripciones impresas en el manual.​ Muchos MS-BASIC usaban abreviaturas de dos caracteres (p. ej., SN para ERROR DE SINTAXIS). Palo Alto Tiny BASIC y Level I BASIC usaban tres palabras para los mensajes de error: «"WHAT?"» (¿QUÉ?) para errores de sintaxis, «HOW?» (¿CÓMO?) para errores en tiempo de ejecución como GOTO a una línea que no existía o desbordamientos numéricos, y «SORRY» (LO SIENTO) para problemas de falta de memoria.

Análisis

Si bien el lenguaje BASIC tiene una sintaxis simple, las expresiones matemáticas no la tienen, y admiten diferentes reglas de precedencia para paréntesis y diferentes operadores matemáticos. Para admitir tales expresiones, se requiere implementar un analizador de descenso recursivo.​

Este analizador se puede implementar de varias maneras:

• Como una máquina virtual, como se discutió arriba para muchas implementaciones de Tiny BASIC. El valor de la iniciativa Tiny BASIC estaba en especificar una implementación de un analizador.
• Como una máquina de estado finito, como en UIUC BASIC IUC, donde se implementó como una tabla de control​
• Directamente en código, como en Palo Alto Tiny BASIC e Integer BASIC. En Integer BASIC, el intérprete de tiempo de ejecución usaba dos pilas para la ejecución: una para las palabras clave de las declaraciones y la otra para evaluar los parámetros. A cada declaración se le dieron dos prioridades: una que indicaba dónde debería ocurrir en una operación de varios pasos, como una serie de operaciones matemáticas para proporcionar orden de operaciones, y otra que sugería cuándo debería ocurrir la evaluación, por ejemplo, calcular valores internos de una fórmula de paréntesis. Cuando se encontraron variables, se analizó su nombre y luego se buscó en la tabla de símbolos. Si no se encontraba, se agregaba al final de la lista. La dirección de almacenamiento de la variable, quizás recién creada, se colocó en la pila de evaluación.​

Rendimiento

La gama de decisiones en el diseño que intervinieron en la programación de un intérprete BASIC a menudo se evidenció a través de diferencias en el rendimiento.

Las implementaciones de administración de líneas a menudo afectaban el rendimiento y, por lo general, usaban búsqueda lineal. Delimitar cada línea con un CR haría que un GOTO o GOSUB a una línea posterior tomara más tiempo, ya que el programa necesitaría iterar sobre todas las líneas para encontrar el número de línea de destino. En algunas implementaciones, como Atari BASIC, la longitud de cada línea se registraba y almacenaba después del número de línea, de modo que el programa no tenía que escanear cada carácter de la línea para encontrar el siguiente retorno de carro. Muchas implementaciones siempre buscarían un número de línea para bifurcarse desde el inicio del programa; MS-BASIC buscaría desde la línea actual, si el número de línea de destino fuera mayor. Pittman agregó un parche a su 6800 Tiny BASIC para usar una búsqueda binaria.​

Trabajar únicamente con matemáticas de enteros proporciona otro impulso importante en la velocidad. Como muchos benchmarks informáticos de la época eran pequeños y, a menudo, realizaban operaciones matemáticas sencillas que no requerían coma flotante, Integer BASIC derrotó a la mayoría de los demás BASIC.​​ En uno de los benchmarks de microcomputadora más antiguos conocidos, los benchmark Rugg/Feldman, Integer BASIC fue más del doble de rápido que Applesoft BASIC en la misma máquina.​ En la Criba de Byte, donde las matemáticas eran menos importante, pero dominaba el acceso a la matriz y el rendimiento de los bucles, Integer BASIC tardó 166 segundos mientras que Applesoft tardó 200.​ No apareció en el Creative Computing Benchmark, que se publicó por primera vez en 1983, momento en el que Integer BASIC ya no se proporcionaba de forma predeterminada.​ La siguiente serie de pruebas, tomada de los dos artículos originales de Rugg/Feldman,​​ muestran el rendimiento de Integer en relación con el BASIC derivado de MS en la misma plataforma.

System	CPU	BASIC	Prueba 1	Prueba 2	Prueba 3	Prueba 4	Prueba 5	Prueba 6	Prueba 7
Apple II	6502 @ 1 MHz	Integer BASIC	1,3	3,1	7,2	7,2	8,8	18,5	28,0
Apple II	6502 @ 1 MHz	Applesoft BASIC	1,3	8,5	16,0	17,8	19,1	28,6	44,8

En teoría, Atari BASIC debería haber funcionado más rápido que los BASIC contemporáneos basados ​​en el esquema de Microsoft. Debido a que 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 a su formato interno de 48 bits, y los valores de las variables se buscan por dirección en lugar de tener que buscarlos. A pesar de estas ventajas teóricas, en la práctica, Atari BASIC es más lento que otros BASIC de computadoras domésticas, a menudo en gran medida.​ En la práctica, esto no se tuvo en cuenta. En dos benchmarks ampliamente utilizados de la época, la Criba de Eratóstenes de la revista Byte y el Benchmark de Creative Computing escrito por David H. Ahl, el Atari terminó casi al final de la lista en términos de rendimiento, y fue mucho más lento que el Apple II contemporáneo o el Commodore PET,​ a pesar de tener la misma CPU pero ejecutándola aproximadamente al doble de la velocidad de cualquiera. Terminó detrás de máquinas relativamente lentas como la Sinclair ZX81 e incluso algunas calculadoras programables.​

La mayor parte de la lentitud del lenguaje procedía de tres problemas.​ El primero es que las rutinas matemáticas de coma flotante estaban mal optimizadas. En el benchmark de Ahl, una operación de un solo exponente, que recorre internamente la lenta función de multiplicación, fue responsable de gran parte de los resultados deficientes de la máquina.​ Segundo, la conversión entre el formato de coma flotante interno y los enteros de 16 bits usados ​​en ciertas partes del lenguaje era relativamente lento. Internamente, estos números enteros se usaban para números de línea e indexación de matrices, junto con algunas otras tareas, pero los números en el programa tokenizado siempre se almacenaban en formato decimal codificado en binario (BCD).​ Cada vez que se encuentra uno de estos, por ejemplo, en el número de línea en GOTO 100, el valor BCD tokenizado debe convertirse en un número entero, una operación que puede tardar tanto como 3500 microsegundos.​ Otros BASIC evitaron este retraso al convertir en formato especial la conversión de números que solo podían ser enteros, como el número de línea que sigue a GOTO, cambiando a un código especial de ASCII-a-entero para mejorar el rendimiento. En tercer lugar, cómo Atari BASIC implementó bifurcaciones y bucles FOR. Para realizar una bifurcación en GOTO o GOSUB, el intérprete busca en todo el programa el número de línea coincidente que necesita.​ Una mejora menor que se encuentra en la mayoría de los BASIC derivados de Microsoft es comparar el número de línea de destino con el número de línea actual y buscar hacia adelante desde ese punto si es mayor, o comenzar desde arriba si es menor. Esta mejora faltaba en Atari BASIC.​ A diferencia de casi todos los demás BASIC, que empujarían un puntero a la ubicación del FOR en una pila, por lo que cuando llegaba al NEXT podía volver fácilmente al FOR de nuevo en una sola operación de bifurcación, Atari BASIC empujó el número de línea en su lugar. Esto significaba que cada vez que se encontraba un NEXT, el sistema tenía que buscar en todo el programa para encontrar la línea FOR correspondiente. Como resultado, cualquier bucle en un programa BASIC de Atari provoca una gran pérdida de rendimiento en relación con otros BASIC.​

Véase también

• Anexo:Dialectos de BASIC
• Anexo:Computadoreas con BASIC integrado

Bibliografía

• Arnold, Mark; Wadsworth, Nat (1976). SCELBAL: A higher level language for 8008/8080 systems. SCELBI Computer Consulting. 
• The ATARI BASIC Reference Manual. Atari Inc. 1980. Archivado desde el original el 1 de mayo de 2005. 
• Crawford, Chris (1982). De Re Atari. Atari Program Exchange. 
• Cromemco 16K Extended BASIC. Cromemco. 1978. 
• Hertzfeld, Andy (June 1985). «The sad story of MacBasic». Folklore. 
• Lorenzo, Mark (2017). Endless Loop: The History of the BASIC Programming Language. Philadelphia: SE Books. ISBN 978-1974-27707-0. 
• Raskin, Jef (1978). Apple II BASIC Programming Manual. Apple Computer. 
• Vickers, Steven (1983). Sinclair ZX Spectrum BASIC Programming (2 edición). Sinclair Research. 
• Weyhrich, Steven (12 de diciembre de 2001). «History part 3: The Apple II». Consultado el 16 de septiembre de 2007. 
• Wilkinson, Bill (1982). Inside Atari DOS. Optimized Systems Software, Inc. ISBN 0-942386-02-7. Consultado el 4 de abril de 2009. 
• Wilkinson, Bill (February 1985). «INSIGHT: Atari». Creative Computing: 139-140. 
• Wilkinson, Bill; O'Brien, Kathleen; Laughton, Paul (1983). The Atari BASIC Source Book. Compute! Books. ISBN 0-942386-15-9. 
• Williams, Gregg; Moore, Rob (December 1984). «The Apple Story / Part 1: Early History». Byte: A67-A71. Consultado el 23 de octubre de 2013. 
• Wozniak, Steven (May 1977). «System Description / The Apple-II». Byte: 34-43. 
• Wozniak, Steven (1 de mayo de 2014). «How Steve Wozniak Wrote BASIC for the Original Apple From Scratch». Gizmodo. 
• Wozniak, Steven (3 de enero de 2018). «Apple BASIC». Woz.org. 

Lectrua adicional

Código fuente y documentos de diseño, en orden cronológico del lanzamiento de las implementaciones BASIC (en inglés):

• Weaver, Alfred; Tindall, Michael; Danielson, Ronald (June 1974). A BASIC Language Interpreter for the Intel 8008 Microprocessor. Department of Computer Science, University of Illinois at Urbana-Champaign (publicado el 1974). 

• Arnold, Mark (1977). SCELBAL Mathematical Functions Supplement. SCELBI Computer Consulting. 
• Arnold, Mark (1977). SCELBAL Strings Supplement. SCELBI Computer Consulting. 
• «Altair BASIC 3.2 (4K) - Annotated Disassembly». 
• Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Volume 1. People's Computer Company. 1976. 
• Rauskolb, Roger (December 1976). «Dr. Wang's Palo Alto Tiny BASIC». Interface Age: 92-108. 
• Pittman, Tom (1977). Tiny BASIC Experimenter's Kit. 
• Santa-Maria, Paul. «Apple II Integer Basic Disassembly».  (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).

Enlaces externos

• Datos: Q98099116