stringtranslate.com

Guerra central

Core War es un juego de programación de 1984 creado por DG Jones y AK Dewdney en el que dos o más programas de batalla (llamados "guerreros") compiten por el control de una computadora virtual . Estos programas de batalla están escritos en un lenguaje ensamblador abstracto llamado Redcode . Los estándares para el lenguaje y la máquina virtual fueron establecidos inicialmente por la International Core Wars Society (ICWS), pero posteriormente los estándares fueron determinados por el consenso de la comunidad.

Como se Juega

Al comienzo de un juego, cada programa de batalla se carga en la memoria en una ubicación aleatoria, después de lo cual cada programa ejecuta una instrucción por turno. El objetivo del juego es hacer que finalicen los procesos de los programas contrarios (lo que ocurre si ejecutan una instrucción no válida), dejando al programa victorioso en posesión exclusiva de la máquina.

La primera versión publicada de Redcode definía sólo ocho instrucciones. El estándar ICWS-86 aumentó el número a 10, mientras que el estándar ICWS-88 lo aumentó a 11. El borrador de estándar de 1994 actualmente utilizado tiene 16 instrucciones. Sin embargo, Redcode admite varios modos de direccionamiento diferentes y (a partir del borrador del estándar de 1994) modificadores de instrucciones que aumentan el número real de operaciones posibles a 7168. El estándar Redcode deja la representación de la instrucción subyacente sin definir y no proporciona ningún medio para que los programas accedan a ella. . Se pueden realizar operaciones aritméticas en los dos campos de dirección contenidos en cada instrucción, pero las únicas operaciones admitidas en los códigos de instrucción son copiar y comparar para determinar la igualdad.

Duración y tiempo de instrucción constantes
Cada instrucción Redcode ocupa exactamente una ranura de memoria y requiere exactamente un ciclo para ejecutarse. Sin embargo, la velocidad a la que un proceso ejecuta instrucciones depende de la cantidad de otros procesos en la cola, ya que el tiempo de procesamiento se comparte equitativamente.
memoria circular
La memoria se direcciona en unidades de una instrucción. El espacio de memoria (o núcleo ) es de tamaño finito, pero sólo se utiliza el direccionamiento relativo , es decir, la dirección 0 siempre se refiere a la instrucción que se está ejecutando actualmente, la dirección 1 a la instrucción posterior, y así sucesivamente. El valor máximo de dirección se establece en uno menos que el número de ubicaciones de memoria y se ajustará si es necesario. Como resultado, existe una correspondencia uno a uno entre las direcciones y las ubicaciones de la memoria, pero es imposible que un programa Redcode determine una dirección absoluta. Un proceso que no encuentra instrucciones inválidas o de salto continuará ejecutando instrucciones sucesivas sin cesar y eventualmente regresará a la instrucción donde comenzó.
Multiprocesamiento de bajo nivel
En lugar de un único puntero de instrucción, un simulador Redcode tiene una cola de proceso para cada programa que contiene un número variable de punteros de instrucción por los que pasa el simulador. Cada programa comienza con un solo proceso, pero se pueden agregar nuevos procesos a la cola usando la SPLinstrucción. Un proceso muere cuando ejecuta una instrucción DAT o realiza una división por cero. Un programa se considera muerto cuando no le quedan más procesos.
Sin acceso externo
Redcode y la arquitectura MARS no proporcionan funciones de entrada o salida. El simulador es un sistema cerrado, donde la única entrada son los valores iniciales de la memoria y las colas de procesos, y la única salida es el resultado de la batalla, es decir, qué programas tuvieron procesos supervivientes. Por supuesto, el simulador aún puede permitir inspecciones externas y modificaciones de la memoria mientras se ejecuta la simulación.

Versiones de Redcode

Existen varias versiones de Redcode. La primera versión descrita por AK Dewdney [1] difiere en muchos aspectos de los estándares posteriores establecidos por la International Core War Society, y podría considerarse un lenguaje diferente, aunque relacionado. La forma de Redcode más comúnmente utilizada hoy en día se basa en un borrador de estándar presentado a la ICWS en 1994 que nunca fue aceptado formalmente, ya que la ICWS había desaparecido efectivamente en esa época. Sin embargo, el desarrollo de Redcode ha continuado de manera informal, principalmente a través de foros en línea como el grupo de noticias rec.games.corewar[2] .

Estrategia

Los guerreros suelen dividirse en varias categorías amplias, aunque los guerreros reales a menudo pueden combinar el comportamiento de dos o más de ellas. Tres de las estrategias comunes ( replicador , escáner y bombardero ) también se conocen como papel, tijera y piedra , ya que su desempeño entre sí se aproxima al de sus homónimos en el conocido juego de patio. [3]

Papel (o replicador)
Un replicador hace copias repetidas de sí mismo y las ejecuta en paralelo, llenando eventualmente todo el núcleo con copias de su código. Los replicantes son difíciles de matar, pero a menudo tienen dificultades para matar a sus oponentes. Por lo tanto, los replicadores tienden a conseguir muchos empates, particularmente contra otros replicadores.
La seda es un tipo especial de replicador muy rápido, que lleva el nombre del Guerrero de la Seda [4] de Juha Pohjalainen. La mayoría de los replicadores modernos son de este tipo. Los replicadores de Silk utilizan la ejecución paralela para copiar todo su código con una instrucción y comenzar la ejecución de la copia antes de que finalice. [5]
Tijeras (o escáner)
Un escáner está diseñado para vencer a los replicadores. Un escáner no ataca a ciegas, sino que intenta localizar a su enemigo antes de lanzar un ataque dirigido. Esto lo hace más efectivo contra oponentes difíciles de matar, como los replicadores, pero también lo deja vulnerable a los señuelos. Un escáner normalmente bombardea la memoria con instrucciones SPL 0 . Esto hace que el enemigo cree una gran cantidad de procesos que no hacen más que crear más procesos, ralentizando los procesos útiles. Cuando el enemigo se vuelve tan lento que no puede hacer nada útil, la memoria es bombardeada con instrucciones DAT . Los escáneres también son generalmente más complejos y, por lo tanto, más grandes y más frágiles que otros tipos de guerreros. [6]
Un one-shot es un escáner muy simple que solo escanea el núcleo hasta que encuentra el primer objetivo y luego cambia permanentemente a una estrategia de ataque, generalmente un núcleo limpio. Myrmidon [7] de Roy van Rijn es un ejemplo de one-shot.
Piedra (o bombardero)
Un bombardero copia ciegamente una "bomba" a intervalos regulares en el núcleo, con la esperanza de impactar al enemigo. La bomba suele ser una instrucción DAT , aunque se pueden utilizar otras instrucciones, o incluso bombas de múltiples instrucciones. Un bombardero puede ser pequeño y rápido, y obtiene una ventaja adicional sobre los oponentes que escanean, ya que las bombas también sirven como distracciones convenientes. Los bombarderos a menudo se combinan con espirales de diablillos para ganar resistencia adicional contra los replicadores.
Vampiro (o trampero)
Un vampiro intenta hacer que los procesos de su oponente salten a una parte de su propio código llamado "pozo". Los vampiros pueden basarse en bombarderos o escáneres. Una debilidad importante de los vampiros es que pueden ser fácilmente atacados indirectamente, ya que necesariamente deben esparcir punteros a su código por todo el núcleo. Sus ataques también son lentos, ya que se necesita una ronda adicional para que los procesos lleguen al pozo. myVamp [8] de Paulsson es un ejemplo de vampiro.
Diablillo
Los diablillos llevan el nombre del primer guerrero publicado, Imp [9] de AK Dewdney , un guerrero móvil trivial de una sola instrucción que copia continuamente su única instrucción justo delante de su puntero de instrucción . Los diablillos son difíciles de matar, pero casi inútiles para atacar. Su uso radica en el hecho de que pueden aparecer fácilmente en grandes cantidades y pueden sobrevivir incluso si el resto de los guerreros mueren.
Un anillo de diablillo (o espiral de diablillo ) consta de diablillos espaciados a intervalos iguales alrededor del núcleo y que se ejecutan alternativamente. Los diablillos en cada brazo del anillo/espiral copian sus instrucciones al siguiente brazo, donde se ejecutan nuevamente inmediatamente. Los anillos y las espirales son incluso más difíciles de matar que los simples diablillos, e incluso tienen una (pequeña) posibilidad de matar a guerreros que no están protegidos contra ellos. El número de brazos en un anillo imp o espiral debe ser relativamente primo con el tamaño del núcleo.
Quickscanner (o q-scan)
Un escáner rápido intenta atrapar a su oponente temprano utilizando un bucle de escaneo desenrollado muy rápido. El escaneo rápido es una estrategia al principio del juego y siempre requiere alguna otra estrategia como respaldo. Agregar un componente de escaneo rápido a un guerrero puede mejorar su puntuación contra guerreros largos, como otros escáneres rápidos. Sin embargo, el escaneo desenrollado sólo puede apuntar a un número limitado de ubicaciones y es poco probable que atrape a un oponente pequeño.
Núcleo claro
Un núcleo claro sobrescribe secuencialmente todas las instrucciones del núcleo, a veces incluso incluyéndose a sí mismo. Los despejes de núcleos no son muy comunes como guerreros independientes, pero los bombarderos y escáneres los utilizan a menudo como estrategia de final de juego.

Guerra centralProgramación

Con una comprensión de las estrategias de Core War , un programador puede crear un guerrero para lograr ciertos objetivos. Las ideas revolucionarias surgen de vez en cuando; Sin embargo, la mayoría de las veces los programadores basan sus programas en guerreros ya publicados. Utilizando optimizadores como OptiMax o herramientas de optimización de pasos centrales, se puede crear un guerrero más eficaz.

Los guerreros también pueden generarse mediante algoritmos genéticos o programación genética . Los programas que integran esta técnica evolutiva se conocen como evolucionadores . La comunidad de Core War introdujo varios evolucionadores que tienden a centrarse en generar guerreros para entornos centrales más pequeños. El último evolucionador con un éxito significativo fue μGP [10], que produjo algunos de los guerreros nano y diminutos más exitosos. Sin embargo, la estrategia evolutiva todavía necesita demostrar su eficacia en entornos centrales más amplios. [11]

Desarrollo

Core War se inspiró en un programa autorreplicante llamado Creeper y un programa posterior llamado Reaper que destruyó copias de Creeper. [12] Creeper fue creado por Bob Thomas en BBN . [13] Dewdney no estaba al tanto del origen de Creeper y Reaper y se refiere a ellos como un rumor proveniente de Darwin y los experimentos con gusanos de Shoch y Hupp. Sin embargo, el artículo de Scientific American de 1984 sobre Core War [12] cita el juego Darwin , jugado por Victor A. Vyssotsky , Robert Morris y Douglas McIlroy en los Laboratorios Bell en 1961.

La palabra "Core" en el nombre proviene de la memoria de núcleo magnético , una tecnología de memoria de acceso aleatorio obsoleta . Este término se usaba entonces, y todavía hoy, como término para la memoria de trabajo en volcados de memoria de trabajo, llamados volcados de núcleo , en Unix y la mayoría de los sistemas similares a Unix. Además, el nombre de archivo predeterminado utilizado para los volcados de memoria en dichos sistemas suele ser "core" o contiene la palabra core.

La primera descripción del lenguaje Redcode se publicó en marzo de 1984, en Core War Guidelines de DG Jones y AK Dewdney . [1] El juego fue presentado al público en mayo de 1984, en un artículo escrito por Dewdney en Scientific American . Dewdney volvió a visitar Core War en su columna "Computer Recreations" en marzo de 1985, [14] y nuevamente en enero de 1987. [15]

La Sociedad Internacional de Guerras Centrales (ICWS) se fundó en 1985, un año después del artículo original de Dewdney. El ICWS publicó nuevos estándares para el lenguaje Redcode en 1986 y 1988, y propuso una actualización en 1994 que nunca se estableció formalmente como el nuevo estándar. [16] No obstante, el borrador de 1994 fue adoptado y ampliado en común, y constituye la base del estándar de facto para Redcode en la actualidad. El ICWS fue dirigido por Mark Clarkson (1985–1987), William R. Buckley (1987–1992) y Jon Newman (1992–); actualmente [ ¿cuándo? ] el ICWS ha desaparecido. [17]

Código Rojo

0000 : AÑADIR . AB # 4 , $ 3 0001 : MOV . F $ 2 , @ 2 0002 : JMP . B $ -2 , $ 00003 : DAT .​​ F # 0 , # 0
Redcode estilo ICWS-94 ensamblado

Redcode es el lenguaje de programación utilizado en Core War . Es ejecutado por una máquina virtual conocida como Memory Array Redcode Simulator , o MARS . El diseño de Redcode se basa libremente en los lenguajes ensambladores CISC reales de principios de la década de 1980, pero contiene varias características [ vagas ] que normalmente no se encuentran en los sistemas informáticos reales.

Tanto Redcode como el entorno MARS están diseñados para proporcionar una plataforma simple y abstracta sin la complejidad de las computadoras y procesadores reales. Aunque Redcode pretende parecerse a un lenguaje ensamblador CISC ordinario, está bastante simplificado en relación con el ensamblador "real" y no tiene direccionamiento de memoria absoluta.

Las 8 instrucciones originales se describen a continuación. Las versiones posteriores agregaron NOP, multiplicación y comparaciones más complejas. [18]

Código de operación Argumento mnemotécnico Acción ------- --------- ----- ----- ----------------- ----------------- 0 DAT B Inicializa la ubicación al valor B . 1 MOV A B Mueva A a la ubicación B. 2 ADD A B Agregue el operando A al contenido de la ubicación B y almacene el resultado en la ubicación B. 3 SUB A B Reste el operando A del contenido de la ubicación B y almacene el resultado en la ubicación B. 4 JMP B Salta a la ubicación B. 5 JMZ A B Si el operando A es 0 , salte a la ubicación B ; De lo contrario, continúe con la siguiente instrucción . 6 DJZ A B Disminuye el contenido de la ubicación A en 1 . Si la ubicación A ahora tiene 0 , salte a la ubicación B ; De lo contrario, continúe con la siguiente instrucción . 7 CMP A B Compare el operando A con el operando B. Si no son iguales , omita la siguiente instrucción ; de lo contrario, ejecute la siguiente instrucción .

El borrador del estándar ICWS '94 agregó más modos de direccionamiento, principalmente para lidiar con la dirección indirecta del campo A, para dar un total de 8 modos de direccionamiento:

 # — inmediato $ — directo ( el $ puede omitirse ) * — A - campo indirecto @ — B - campo indirecto { — A - campo indirecto con predecremento < — B - campo indirecto con predecremento } — A - campo indirecto con postincremento >​ — B - campo indirecto con postincremento

Implementaciones

El desarrollo de implementaciones del juego continuó a lo largo de los años por parte de varios autores. Hay varias versiones del juego disponibles, [19] adaptadas a varias plataformas. Por ejemplo, pMARS, que es un software de código abierto con código fuente en SourceForge , [20] o SDL pMARS basado en SDL para Windows. [21]

La implementación común pMars se descargó más de 35.000 veces entre 2000 y 2021 desde SourceForge . [22]

Referencias

  1. ^ ab Jones, director general; Dewdney, AK (marzo de 1984). "Pautas básicas de guerra" . Consultado el 27 de mayo de 2023 .
  2. ^ "rec.games.corewar en Grupos de Google" . Consultado el 29 de mayo de 2023 .
  3. ^ Wangsaw, Mintardjo. "Introducción al arte en el 88: Trilogía Papel - Piedra - Tijeras" . Consultado el 27 de mayo de 2023 .
  4. ^ Pohjalainen, Jippo. "Guerrero de Seda 1.3" . Consultado el 27 de mayo de 2023 .
  5. ^ Pohjalainen, Jippo (abril de 1995). "¿replicantes? -> Phoenix y TimeScapesource" . Consultado el 27 de mayo de 2023 .
  6. ^ Metcalf, John (abril de 2004). "Anatomía del escáner, introducción básica" . Consultado el 27 de mayo de 2023 .
  7. ^ van Rijn, Roy. "Mirmidón" . Consultado el 27 de mayo de 2023 .
  8. ^ Paulsson, Magnus. "miVamp v3.7" . Consultado el 27 de mayo de 2023 .
  9. ^ Dewdney, AK "Diablillo" . Consultado el 27 de mayo de 2023 .
  10. ^ Squillero, Giovanni. "μGP (MicroGP v2)". GitHub . Consultado el 10 de septiembre de 2018 .
  11. ^ Voto, Barkley; Espera, Alejandro; Schmidt, cristiano. "Un enfoque evolutivo genera programas de guerra central competitivos humanos" (PDF) . Consultado el 27 de mayo de 2023 .
  12. ^ ab Dewdney, AK (mayo de 1984). "En el juego llamado Core War, los programas hostiles participan en una batalla de bits". Científico americano . Consultado el 27 de mayo de 2023 .
  13. ^ Shoch, J .; Hupp, J. (marzo de 1982). "Los programas 'gusano': experiencia temprana con una computación distribuida". Comunicaciones de la ACM . 25 (3): 172–180. doi : 10.1145/358453.358455 . S2CID  1639205.
  14. ^ Dewdney, AK (marzo de 1985). "Un bestiario de virus, gusanos y otras amenazas a la memoria de la computadora de Core War". Científico americano . Consultado el 27 de mayo de 2023 .
  15. ^ Dewdney, AK (enero de 1987). "Un programa llamado MICE se abre camino hacia la victoria en el primer torneo Core War". Científico americano . Consultado el 27 de mayo de 2023 .
  16. ^ Doligez, Damián; Durham, Mark (8 de noviembre de 1995). "Borrador comentado del estándar básico de guerra propuesto de 1994" . Consultado el 27 de mayo de 2023 .
  17. ^ Metcalf, John. "Una breve historia de Corewar" . Consultado el 27 de mayo de 2023 .
  18. ^ "La guía para principiantes de Redcode, v1.23".
  19. ^ Los emuladores de Corewar en corewar.info
  20. ^ guerra central en SourceForge
  21. ^ pMARS-SDL en corewar.co.uk por Joonas Pihlaja (7 de mayo de 2003)
  22. ^ descargar números corewar en SourceForge (acceso 2021-06-07)

enlaces externos