Articulo de referencia

Guerra central

Core War es un juego de programación creado en 1984 por DG Jones y AK Dewdney . En el juego, dos o más programas de batalla, conocidos como guerreros , compiten por el control d...

Core War es un juego de programación creado en 1984 por DG Jones y AK Dewdney . En el juego, dos o más programas de batalla, conocidos como guerreros , compiten por el control de una computadora virtual . Estos programas están escritos en un lenguaje ensamblador abstracto llamado Redcode . Los estándares iniciales para Redcode y la máquina virtual fueron establecidos por la International Core Wars Society (ICWS), y las revisiones posteriores se basaron en el consenso de la comunidad.

Jugabilidad

Al inicio de una partida, cada guerrero se carga en una ubicación de memoria aleatoria. Los programas se turnan para ejecutar una instrucción a la vez. Un programa gana al eliminar a todos sus oponentes, generalmente provocando que ejecuten instrucciones inválidas, lo que le otorga el control exclusivo de la máquina.

Las primeras versiones de Redcode solo incluían ocho instrucciones. Este número aumentó a 10 en el estándar ICWS-86, a 11 en ICWS-88 y a 16 en el borrador de 1994, que aún se utiliza ampliamente. Con los diversos modos de direccionamiento y modificadores de instrucciones introducidos en el borrador de 1994, el número total de operaciones posibles es de 7168. Redcode no define cómo se representan las instrucciones en memoria, ni permite que los programas inspeccionen su propia estructura de código más allá de la copia y las comparaciones de igualdad. Las operaciones aritméticas se limitan a los dos campos de dirección de la instrucción.

Duración y tiempo de instrucción constantes
Cada instrucción de Redcode ocupa exactamente una ranura de memoria y tarda exactamente un ciclo en ejecutarse. Sin embargo, la velocidad a la que un proceso ejecuta instrucciones depende del número 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, la dirección 1 a la siguiente, y así sucesivamente. El valor máximo de la dirección se establece en uno menos que el número de posiciones de memoria y se reinicia si es necesario. Como resultado, existe una correspondencia uno a uno entre las direcciones y las posiciones de 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 indefinidamente, hasta que finalmente regrese a la instrucción donde comenzó.
Multiprocesamiento de bajo nivel
En lugar de un único puntero de instrucción, un simulador Redcode dispone de una cola de procesos para cada programa, que contiene un número variable de punteros de instrucción que el simulador recorre cíclicamente. Cada programa comienza con un único proceso, pero se pueden añadir nuevos procesos a la cola mediante la SPLinstrucción. Un proceso finaliza cuando ejecuta una instrucción DAT o realiza una división por cero . Un programa se considera finalizado cuando ya no tiene más procesos.
No se permite el acceso externo.
Redcode y la arquitectura MARS no ofrecen funciones de entrada ni de 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 lograron mantener procesos activos. Por supuesto, el simulador aún puede permitir inspecciones externas y la modificación de la memoria mientras se ejecuta la simulación.

Versiones de Redcode

Existen varias versiones de Redcode. La versión más antigua 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 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 prácticamente había desaparecido por aquel entonces. 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 combinan el comportamiento de dos o más de ellas. Tres de las estrategias comunes ( replicador , escáner y bombardero ) también se conocen como piedra, papel o tijera , ya que su desempeño entre sí se asemeja al de sus homónimos en el conocido juego infantil. [ 3 ]

Papel (o replicador)
Un replicador crea copias repetidas de sí mismo y las ejecuta en paralelo, llenando finalmente todo el núcleo con copias de su código. Los replicadores son difíciles de eliminar, pero a menudo tienen dificultades para eliminar a sus oponentes. Por lo tanto, los replicadores tienden a obtener muchos empates, especialmente contra otros replicadores.
Un replicador de seda es un tipo especial de replicador ultrarrápido, que recibe su nombre de Silk Warrior [ 4 ] de Juha Pohjalainen. La mayoría de los replicadores modernos son de este tipo. Los replicadores de seda utilizan la ejecución paralela para copiar todo su código con una sola instrucción y comienzan la ejecución de la copia antes de que esta 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 eliminar 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 provoca 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 es incapaz de hacer nada útil, la memoria es bombardeada con instrucciones DAT . Los escáneres también suelen ser más complejos y, por lo tanto, más grandes y 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 para despejar el 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 también se pueden usar 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 imp para obtener mayor resistencia contra los replicadores.
Vampiro (o cazador de trampas)
Un vampiro intenta hacer que los procesos de su oponente salten a una parte de su propio código llamada "pozo". Los vampiros pueden basarse en bombarderos o escáneres. Una debilidad importante de los vampiros es que pueden ser atacados fácilmente de forma indirecta, ya que necesariamente deben dispersar 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 un vampiro.
Diablillo
Los diablillos reciben su 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 prácticamente inútiles para el ataque. Su utilidad radica en que pueden generarse fácilmente en grandes cantidades y pueden sobrevivir incluso si el resto de los guerreros mueren.
Un anillo de diablillos (o espiral de diablillos ) consiste en diablillos espaciados a intervalos iguales alrededor del núcleo, que se ejecutan alternativamente. Los diablillos de cada brazo del anillo/espiral copian sus instrucciones al siguiente brazo, donde se ejecutan inmediatamente de nuevo. Los anillos y espirales son aún más difíciles de destruir que los diablillos simples, e incluso tienen una pequeña probabilidad de matar a guerreros que no estén protegidos contra ellos. El número de brazos en un anillo o espiral de diablillos debe ser relativamente primo con el tamaño del núcleo.
Hidra
Las hidras lanzan múltiples copias de pequeños bombarderos o despejadores de núcleos. [ 10 ]
Escáner rápido (o q-scan)
Un explorador rápido intenta sorprender a su oponente con un bucle de escaneo desplegado muy veloz. El escaneo rápido es una estrategia inicial y siempre requiere otra estrategia de respaldo. Añadir un componente de escaneo rápido a un guerrero puede mejorar su puntuación contra guerreros de largo alcance, como otros exploradores rápidos. Sin embargo, el escaneo desplegado solo puede apuntar a un número limitado de ubicaciones y es poco probable que alcance a un oponente pequeño.
Oreja
Bootstraps copia uno o más de sus componentes fuera de su ubicación original, dejando un señuelo para atraer a Scanners y Quickscanners. [ 11 ]
guerreros mestizos
Algunos guerreros emplean diferentes estrategias en el mismo momento o en momentos diferentes.
Por ejemplo, Piedra/Impacto . Las Piedras/Impactos son Imps que se han emparejado con Piedras para reducir algunas de las pérdidas contra el papel.
Algunos de los guerreros más exitosos de todos los tiempos son los Stone/Imps.
Núcleo limpio
Un borrado de núcleo sobrescribe secuencialmente todas las instrucciones del núcleo, a veces incluso la suya propia. Los borrados de núcleo no son muy comunes como acciones independientes, pero suelen ser una estrategia de final de partida para bombarderos y escáneres.

Programación de la Guerra Central

Conociendo 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 principales, 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 la generación de guerreros para entornos de núcleo más pequeños. El evolucionador más reciente con un éxito significativo fue μGP [ 12 ] [ 13 ] , que produjo algunos de los nanoguerreros y guerreros diminutos más exitosos. Sin embargo, la estrategia evolutiva aún necesita demostrar su eficacia en entornos de núcleo más grandes. [ 14 ]

Desarrollo

Core War se inspiró en un programa autorreplicante llamado Creeper y un programa posterior llamado Reaper que destruía copias de Creeper. [ 15 ] Creeper fue creado por Bob Thomas en BBN . ​​[ 16 ] Dewdney desconocía el origen de Creeper y Reaper y se refiere a ellos como un rumor originado por Darwin y los experimentos con gusanos de Shoch y Hupp. El artículo de Scientific American de 1984 sobre Core War [ 15 ] cita, sin embargo, 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 aún hoy, para referirse a la memoria de trabajo en los volcados de memoria, llamados volcados de núcleo , en Unix y la mayoría de los sistemas similares a Unix. Además, el nombre de archivo predeterminado para los volcados de núcleo 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 se presentó al público en mayo de 1984, en un artículo escrito por Dewdney en Scientific American . Dewdney volvió a hablar de Core War en su columna "Computer Recreations" en marzo de 1985, [ 17 ] y de nuevo en enero de 1987. [ 18 ]

La International Core Wars Society (ICWS) se fundó 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. [ 19 ] No obstante, el borrador de 1994 fue comúnmente adoptado y ampliado, y constituye la base del estándar de facto para Redcode en la actualidad. La ICWS estuvo dirigida por Mark Clarkson (1985–1987), William R. Buckley (1987–1992) y Jon Newman (1992–); actualmente la ICWS está desaparecida. [ 20 ]

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 Simulador de Redcode de Matriz de Memoria ( MARS) . El diseño de Redcode se basa libremente en lenguajes ensambladores CISC reales de principios de la década de 1980, pero contiene varias características que no suelen encontrarse en los sistemas informáticos actuales.

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 absoluto.

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

El borrador del estándar ICWS '94 añadió más modos de direccionamiento, principalmente para abordar la indirección del campo A, para dar un total de 8 modos:

Implementaciones

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

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

Referencias

  1. 1 2 Jones, DG; Dewdney, AK (marzo de 1984). "Directrices básicas de la guerra" . Recuperado 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 el 88: Trilogía de papel, piedra y tijeras" . Consultado el 27 de mayo de 2023 .
  4. ^ Pohjalainen, Jippo. "Guerrero de Seda 1.3" . Consultado el 2 de marzo de 2025 .
  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" . Recuperado el 27 de mayo de 2023 .
  7. ^ van Rijn, Roy. "Mirmidón" . Consultado el 2 de marzo de 2025 .
  8. Paulsson, Magnus. "miVamp v3.7" . Consultado el 2 de marzo de 2025 .
  9. ^ Dewdney, AK "Diablillo" . Consultado el 2 de marzo de 2025 .
  10. "Guía de estrategia de guerra básica" . Consultado el 12 de mayo de 2024 .
  11. "Guía de estrategia de guerra básica" . Consultado el 12 de mayo de 2025 .
  12. Squillero, Giovanni. "μGP (MicroGP v2)" . GitHub . Consultado el 10 de septiembre de 2018 .
  13. Corno, F.; Sanchez, E.; Squillero, G. (2005). "Evolución de programas en lenguaje ensamblador: 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 . 
  14. Vowk, Barkley; Wait, Alexander; Schmidt, Christian. "Un enfoque evolutivo genera programas de guerra central competitiva humana" (PDF) . Consultado el 27 de mayo de 2023 .
  15. 1 2 Dewdney, AK (mayo de 1984). "En el juego llamado Guerra del Núcleo, los programas hostiles se enfrentan en una batalla de bits" . Scientific American . Recuperado el 27 de mayo de 2023 .
  16. Shoch, J. ; Hupp, J. (marzo de 1982). "Los programas 'gusano': primeras experiencias con computación distribuida" . Communications of the ACM . 25 (3): 172– 180. doi : 10.1145/358453.358455 . S2CID 1639205 . 
  17. Dewdney, A. K. (marzo de 1985). "Un bestiario de virus, gusanos y otras amenazas a las memorias de las computadoras en la Guerra del Núcleo" . Scientific American . Recuperado el 27 de mayo de 2023 . 
  18. Dewdney, A. K. (enero de 1987). "Un programa llamado MICE avanza lentamente hacia la victoria en el primer torneo de la Guerra del Núcleo" . Scientific American . Recuperado el 27 de mayo de 2023 . 
  19. Doligez, Damien; Durham, Mark (8 de noviembre de 1995). "Borrador anotado del estándar de guerra básico propuesto para 1994" . Recuperado el 27 de mayo de 2023 .
  20. Metcalf, John. "Una breve historia de la guerra del centro" . Recuperado el 27 de mayo de 2023 .
  21. "Guía para principiantes de Redcode, v1.23" .
  22. Los emuladores de Corewar en corewar.info
  23. corewar en SourceForge
  24. ^ pMARS-SDL en corewar.co.uk por Joonas Pihlaja (7 de mayo de 2003)
  25. Descarga el corewar de numbers en SourceForge (acceso 07/06/2021)
  • Core War: el juego de programación definitivo
  • La página de información sobre la guerra principal
  • La guía para principiantes de Redcode
  • Borrador anotado del Estándar Básico de Guerra propuesto para 1994
  • Bibliografía de la Guerra de Secesión
Obtenido de " https://en.wikipedia.org/w/index.php?title=Core_War&oldid=1320067265 "