stringtranslate.com

Guerra del núcleo

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 abstractollamado Redcode . Los estándares para el lenguaje y la máquina virtual fueron establecidos inicialmente por la International Core Wars Society (ICWS), pero más tarde los estándares fueron determinados por consenso de la comunidad.

Jugabilidad

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 los procesos de los programas oponentes finalicen (lo que sucede 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 que se utiliza actualmente tiene 16 instrucciones. Sin embargo, Redcode admite varios modos de direccionamiento diferentes y (a partir del borrador de estándar de 1994) modificadores de instrucciones que aumentan el número real de operaciones posibles a 7168. El estándar Redcode deja sin definir la representación de la instrucción subyacente 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 propios códigos de instrucción son copiar y comparar para determinar la igualdad.

Duración y duración de instrucción constantes
Cada instrucción Redcode ocupa exactamente una ranura de memoria y tarda exactamente un ciclo en ejecutarse. Sin embargo, la velocidad a la que un proceso ejecuta las 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 solo se utiliza 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 la dirección se establece en uno menos que el número de ubicaciones de memoria y se reinicia si es necesario. Como resultado, existe una correspondencia uno a uno entre las direcciones y las ubicaciones de memoria, pero es imposible para un programa Redcode determinar una dirección absoluta. Un proceso que no encuentra instrucciones no válidas o de salto continuará ejecutando instrucciones sucesivas sin fin, 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 procesos para cada programa que contiene una cantidad variable de punteros de instrucción que el simulador recorre en ciclos. Cada programa comienza con un solo proceso, pero se pueden agregar nuevos procesos a la cola utilizando 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, en el que 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 tenían procesos supervivientes. Por supuesto, el simulador 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 que se usa más comúnmente en la actualidad 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 dejado de existir en ese momento. 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 pueden combinar a menudo 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 rendimiento entre sí se aproxima al de sus homónimos en el conocido juego de patio de recreo. [3]

Papel (o replicador)
Un replicador hace copias repetidas de sí mismo y las ejecuta en paralelo, hasta que finalmente llena todo el núcleo con copias de su código. Los replicadores son difíciles de matar, pero a menudo tienen dificultades para matar a sus oponentes. Por lo tanto, los replicadores tienden a lograr muchos empates, en particular contra otros replicadores.
Un Silk es un tipo especial de replicador muy rápido, llamado así por Silk Warrior [4] de Juha Pohjalainen. La mayoría de los replicadores modernos son de este tipo. Los replicadores Silk utilizan la ejecución paralela para copiar todo su código con una instrucción y comienzan la ejecución de la copia antes de que finalice. [5]
Tijeras (o escáner)
Un escáner está diseñado para derrotar 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 generalmente 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 son 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 una limpieza del núcleo. 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 alcanzar al enemigo. La bomba suele ser una instrucción DAT , aunque se pueden utilizar otras instrucciones o incluso bombas con 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 imp para ganar resistencia adicional contra los replicadores.
Vampiro (o cazador de fosas)
Un vampiro intenta hacer que los procesos de su oponente salten a un fragmento de su propio código llamado "pozo". Los vampiros pueden estar basados ​​en bombarderos o escáneres. Una debilidad importante de los vampiros es que pueden ser atacados indirectamente con facilidad, ya que deben, por necesidad, esparcir punteros a su código por todo el núcleo. Sus ataques también son lentos, ya que los procesos necesitan una ronda adicional para llegar al pozo. myVamp [8] de Paulsson es un ejemplo de vampiro.
Diablillo
Los imps reciben su nombre del primer guerrero publicado, Imp [9] de AK Dewdney , un trivial guerrero móvil de una sola instrucción que copia continuamente su única instrucción justo delante de su puntero de instrucción . Los imps son difíciles de matar, pero casi inútiles para la ofensiva. Su utilidad radica en el hecho de que pueden generarse fácilmente en grandes cantidades y pueden sobrevivir incluso si el resto de los guerreros mueren.
Un anillo de imps (o espiral de imps ) consiste en imps espaciados a intervalos iguales alrededor del núcleo y ejecutándose alternativamente. Los imps en cada brazo del anillo/espiral copian sus instrucciones al siguiente brazo, donde se ejecutan de nuevo inmediatamente. Los anillos y espirales son incluso más difíciles de matar que los imps simples, 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 o espiral de imps 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 de forma temprana mediante un bucle de escaneo desenrollado muy rápido. El escaneo rápido es una estrategia de inicio del juego y siempre requiere alguna otra estrategia como respaldo. Agregar un componente de escaneo rápido a un guerrero puede mejorar su puntaje contra guerreros largos como otros escáneres rápidos. Sin embargo, el escaneo desenrollado solo puede apuntar a una cantidad limitada de ubicaciones y es poco probable que atrape a un oponente pequeño.
Núcleo claro
La limpieza del núcleo sobrescribe secuencialmente todas las instrucciones del núcleo, a veces incluso incluyéndose a sí misma. La limpieza del núcleo no es muy común como guerrero independiente, pero los bombarderos y los escáneres suelen utilizarla como estrategia de final de partida.

Guerra del núcleoProgramació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. Con optimizadores como OptiMax o herramientas de optimización de Core-Step, se puede crear un guerrero más efectivo.

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 evolucionistas . La comunidad de Core War introdujo varios evolucionistas que tienden a centrarse en generar guerreros para entornos de núcleo más pequeños. El último evolucionista con un éxito significativo fue μGP [10] [11] , que produjo algunos de los guerreros nano y diminutos más exitosos. Sin embargo, la estrategia evolutiva aún necesita demostrar su eficacia en entornos de núcleo más grandes. [12]

Desarrollo

Core War se inspiró en un programa autorreplicante llamado Creeper y un programa posterior llamado Reaper que destruía copias de Creeper. [13] Creeper fue creado por Bob Thomas en BBN . ​​[14] Dewdney no estaba al tanto del origen de Creeper y Reaper y se refiere a ellos como un rumor originado en Darwin y los experimentos con gusanos de Shoch y Hupp. El artículo de Scientific American de 1984 sobre Core War [13], sin embargo, cita el juego Darwin , jugado por Victor A. Vyssotsky , Robert Morris y Douglas McIlroy en Bell Labs 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 que se usa para los volcados de núcleo en dichos sistemas suele ser "core" o contiene la palabra core.

La primera descripción del lenguaje Redcode fue publicada en marzo de 1984, en Core War Guidelines por 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, [15] y nuevamente en enero de 1987. [16]

La International Core Wars Society (ICWS) fue fundada en 1985, un año después del artículo original de Dewdney. La 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. [17] No obstante, el borrador de 1994 fue adoptado y ampliado por todos, y forma la base del estándar de facto para Redcode en la actualidad. La ICWS fue dirigida por Mark Clarkson (1985-1987), William R. Buckley (1987-1992) y Jon Newman (1992-); actualmente [ ¿cuándo? ] la ICWS está extinta. [18]

Código rojo

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

Redcode es el lenguaje de programación utilizado en Core War . Se ejecuta mediante una máquina virtual conocida como Memory Array Redcode Simulator o MARS . El diseño de Redcode se basa vagamente en los lenguajes ensambladores CISC reales de principios de los años 80, pero contiene varias características [ vagas ] que no se encuentran habitualmente 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 está pensado para parecerse a un lenguaje ensamblador CISC común, es bastante simplificado en relación con el ensamblador "real" y no tiene direccionamiento de memoria absoluto.

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

Código de operación Mnemónico Argumento (s) Acción ------- --------- ----- ----- ---------------------------------- 0 DAT B Inicializar la ubicación al valor B . 1 MOV A B Mover A a la ubicación B . 2 ADD A B Agregar el operando A al contenido de la ubicación B y almacenar el resultado en la ubicación B . 3 SUB A B Restar el operando A del contenido de la ubicación B y almacenar el resultado en la ubicación B . 4 JMP B Saltar a la ubicación B . 5 JMZ A B Si el operando A es 0 , saltar a la ubicación B ; de lo contrario continuar con la siguiente instrucción . 6 DJZ A B Decrementar el contenido de la ubicación A en 1 . Si la ubicación A ahora contiene 0 , saltar a la ubicación B ; de lo contrario continuar con la siguiente instrucción . 7 CMP A B Comparar el operando A con el operando B . Si no son iguales , omitir la siguiente instrucción ; de lo contrario ejecutar la siguiente instrucción .

El borrador estándar ICWS '94 agregó más modos de direccionamiento, principalmente para lidiar con la indirección 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, [20] adaptadas a varias plataformas. Por ejemplo, pMARS , que es un software de código abierto con código fuente en SourceForge , [21] o el SDL pMARS para Windows basado en SDL . [22]

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

Referencias

  1. ^ ab Jones, DG; Dewdney, AK (marzo de 1984). "Core War Guidelines" (Directrices básicas de la guerra) . Consultado el 27 de mayo de 2023 .
  2. ^ "rec.games.corewar en Google Groups" . Consultado el 29 de mayo de 2023 .
  3. ^ Wangsaw, Mintardjo. "Introducción al arte en 1988: trilogía Papel, piedra y tijera" . 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: una 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 "Imp" . Consultado el 27 de mayo de 2023 .
  10. ^ Squillero, Giovanni. "μGP (MicroGP v2)". GitHub . Consultado el 10 de septiembre de 2018 .
  11. ^ Corno, F.; Sanchez, E.; Squillero, G. (2005). "Evolución de programas ensambladores: cómo los juegos ayudan a la validación de microprocesadores". IEEE Transactions on Evolutionary Computation . 9 (6): 695–706. doi :10.1109/TEVC.2005.856207. ISSN  1089-778X.
  12. ^ Vowk, Barkley; Wait, Alexander; Schmidt, Christian. "Un enfoque evolutivo genera programas humanos competitivos de guerra central" (PDF) . Consultado el 27 de mayo de 2023 .
  13. ^ ab Dewdney, AK (mayo de 1984). "En el juego llamado Core War, los programas hostiles participan en una batalla de bits". Scientific American . Consultado el 27 de mayo de 2023 .
  14. ^ Shoch, J. ; Hupp, J. (marzo de 1982). "Los programas 'Worm' - Experiencia temprana con computación distribuida". Comunicaciones de la ACM . 25 (3): 172–180. doi : 10.1145/358453.358455 . S2CID  1639205.
  15. ^ Dewdney, A. K. (marzo de 1985). "Un bestiario de virus, gusanos y otras amenazas a las memorias de las computadoras de Core War". Scientific American . Consultado el 27 de mayo de 2023 .
  16. ^ Dewdney, A. K. (enero de 1987). "Un programa llamado MICE se abre camino hacia la victoria en el primer torneo de Core War". Scientific American . Consultado el 27 de mayo de 2023 .
  17. ^ Doligez, Damien; Durham, Mark (8 de noviembre de 1995). "Borrador anotado de la propuesta de norma básica de guerra de 1994" . Consultado el 27 de mayo de 2023 .
  18. ^ Metcalf, John. "Una breve historia de Corewar" . Consultado el 27 de mayo de 2023 .
  19. ^ "La guía para principiantes de Redcode, v1.23".
  20. ^ Los emuladores de Corewar en corewar.info
  21. ^ corewar en SourceForge
  22. ^ pMARS-SDL en corewar.co.uk por Joonas Pihlaja (7 de mayo de 2003)
  23. ^ descargar números corewar en SourceForge (acceso 2021-06-07)

Enlaces externos