assembly compression forth 6502

assembly - 6502 algoritmos de compresión livianos



compression forth (1)

Si lo que más le preocupa es el código fuente de Forth, puede restringir el conjunto de caracteres a 48 que Chuck Moore elija para colorForth y utilizar su esquema de codificación de Shannon, que da como resultado 5.2 bits por carácter en promedio. También afirma que la fuente de colorForth es solo aproximadamente el doble del tamaño del código objeto. Por cierto, parece que el conjunto de caracteres es ligeramente diferente en conjunto en adelante (ver la página 47 del Manual del usuario - orden diferente para los dígitos, apóstrofo en lugar de dos puntos, etc.).

Usar la codificación Shannon no tiene nada que ver necesariamente con las palabras coloreadas, por supuesto. Si querías recorrer todo el camino y almacenar palabras pre-analizadas como en colorForth, podrías usar su esquema aquí .

No da muchos detalles, pero para etherForth abandonó la codificación de Shannon y optó por una codificación simple de 6 bits para el mismo juego de caracteres con 11xxxx que además indica una etiqueta de 16 bits que usa para los colores y las fichas, incluido el F18 instrucciones y algunas primitivas del ensamblador (comenzar, finalizar, luego, para). Ese es un esquema realmente genial (y especialmente en el F18 de 18 bits con espacio para 3 por palabra). Extremadamente simple y bastante compacto.

De todos modos, hay algunas ideas. No es realmente una respuesta directa a su pregunta de compresión, sino algunas formas de almacenar Forth source en una forma bien comprimida. ¡Que te diviertas!

Estoy implementando memoria virtual en casetes de casetes duales en un Commodore PET (por diversión) para un Forth que estoy escribiendo. Lo que tengo hasta ahora es en http://github.com/chitselb/pettil si te interesa.

Estoy planeando utilizar el formato de archivo de datos nativo de cassette de 192 bytes de PET. Oh sí, solo 32K de RAM para todo . Incluí el excelente intérprete de Sweet-16 de Woz en el lenguaje.

Un bloque Forth es (típicamente) 1024 bytes. Agregar dos bytes para la ID del bloque limita el espacio de direcciones virtuales disponible a 64 megas, mucho más de lo que cabría en una cinta. Habría un mazo de "reproducción" (dispositivo 1) y un mazo de "grabación" (dispositivo 2) y el FLUSH implicaría copiar toda la memoria virtual de una unidad a la otra. ¿Por qué inclinarse en los molinos de viento? Porque en el pasado, la cinta de cassette es lo que la mayoría de los propietarios de PET tenían, incluido uno mismo.

La mayoría de los datos serán pantallas de código Forth, que en esta implementación serán 1000 bytes de texto y una tabla de ajuste de línea de 24 bytes, ya que estoy aprovechando el editor de pantalla PET ROM también. Lo que estoy buscando son sugerencias para cualquier cosa que (probablemente) supere la codificación de longitud de ejecución simple para este propósito, pero sin la CPU y la sobrecarga de memoria de algo tan complejo como Lempel-Ziv. Se agradecen todas las sugerencias que no sean "solo olvídate".