Minimal 64x4 Support (#31)

This is a rather large change that enables several assembly syntax features to support the Minimal 64x4 Home Computer. The major changes are:

* address operand type that support bit slicing when needed for things like local jumps and zero page addressing.
* .align directive to adjust current address to next configurable page boundary
* Support for embedded strings, which which are essentially .cstr data types without the .cstr directive.
* #mute and #unmute preprocessor directive to control the emission of byte code.
* Complete list of changes is in the CHANGELOG.

Also created the ISA configuration and sample code for the Minimal 64x4 Home Computer.

Author: michaelkamprath

.pre-commit-config.yaml

@@ -2,22 +2,26 @@
 # See https://pre-commit.com/hooks.html for more hooks
 repos:
 -   repo: https://github.com/pre-commit/pre-commit-hooks
-    rev: v4.4.0
+    rev: v4.6.0
     hooks:
     -   id: trailing-whitespace
     -   id: end-of-file-fixer
     -   id: check-yaml
     -   id: check-json
     -   id: check-toml
+    -   id: check-xml
     -   id: check-added-large-files
         args: ['--maxkb=10000']
     -   id: mixed-line-ending
+    -   id: check-docstring-first
+    -   id: double-quote-string-fixer
 -   repo: https://github.com/pycqa/flake8
     rev: '6.0.0'
     hooks:
     -   id: flake8
         args: [--max-line-length=127]
 -   repo: https://github.com/asottile/pyupgrade
-    rev: v3.6.0
+    rev: v3.15.2
     hooks:
     -   id: pyupgrade
+        args: [--py39-plus]

.vscode/launch.json

@@ -0,0 +1,13 @@
+{
+    "version": "0.2.0",
+    "configurations": [
+        {
+            "name": "Python: Current File",
+            "type": "python",
+            "request": "launch",
+            "program": "${file}",
+            "console": "integratedTerminal",
+            "justMyCode": true
+        }
+    ]
+}

CHANGELOG.md

@@ -13,8 +13,17 @@ Changes that are planned but not implemented yet:
   * Disallowed operands
   * missing `:` after labels
   * unknown labels
+* Add named label scopes. This would allow a label to be defined in a specific scope that can be shared across files.
+* Create a "align if needed" preprocessor directive paid that generates an `.align` directive is the bytecode in between the paid isn't naturally on the same page and can fit on the same page if aligned. An error would be benerated if the block of code can't fit on the same page regardless of alignment.
 
 ## [Unreleased]
+*  Added support for The Minimal 64x4 Home Computer with an example and updated assembler functionality to support it.
+*  Added `address` operand type that enables several features specific to absolute addresses, include slicing the address to support "short jump" type instructions.
+*  Added `.align` directive to align the current address to a multiple of a given value.
+*  Changed syntax highlight color theme name to be specific to the language rather than the generic "BespokeASM Theme" name.
+*  Added optional support for embedded strings in the assembly code. When enabled, strings can be ebdedded in the code withou a data directive such as `.cstr`. This is enabled by setting the `allow_embedded_strings` option in the `general` section of the configuration file to `true`.
+*  Added ability to mute byte code emission with the preprocessor directive `#mute` and unmute with `#unmute`.
+*  Improved handling of include directories  by duplicating and normalizing all search paths.
 
 ## [0.4.1]
 * added `.asciiz` as an equivalent data directive to `.cstr`

Pipfile.lock

@@ -14,14 +14,14 @@ A named memory zone is a contiguous address range in the allowable address space
 * A named memory zone must be completely contained by the allowed memory space of the configured ISA.
 * Multiple named memory zones may overlap with each other
 * When byte code is assembled, multiple byte codes assigned to the same absolute memory address is a fatal error.
-* Named memory zones are a compile time construct, and are intended to only be a means to manage memory ranges and byte code memory locations in assembly code. 
+* Named memory zones are a compile time construct, and are intended to only be a means to manage memory ranges and byte code memory locations in assembly code.
 * Memory zones have a start and end absolute memory address. Byte code assigned to that memory zone with an absolute address outside of the memory zone's range will be an error.
 * A memory zone's name cannot be also used for any label.
 
 #### Creation
 
 ##### Global Memory Zone
-By default, a memory zone named `GLOBAL` is defined to be the full range of memory addresses allowed by the instruction set configuration file. For example, if the ISA defines a 16-bit address type, then the `GLOBAL` memory zone will be addresses `0x0000` though `0xFFFF`. 
+By default, a memory zone named `GLOBAL` is defined to be the full range of memory addresses allowed by the instruction set configuration file. For example, if the ISA defines a 16-bit address type, then the `GLOBAL` memory zone will be addresses `0x0000` though `0xFFFF`.
 
 The `GLOBAL` memory zone can be redefined in the ISA configuration to be a subset of what is permitted by the memory address bit size.
 
@@ -34,7 +34,7 @@ A memory zone can be defined with the following directive
 
 Where `<memory zone name>` is an alphanumeric string with no spaces which will serve as the memory zone name, `<start address>` is the absolute address of the start of the memory zone, and `<end address>` is the absolute address of the end of the memory zone. Both `<start address>` and `<end address>` must be defined with integer literals.
 
-Any defined memory zone must be fully contained in the `GLOBAL` memory zone. 
+Any defined memory zone must be fully contained in the `GLOBAL` memory zone.
 
 ##### ISA Configuration
 A predefined memory zone can be defined in the instruction set configuration file. In the `predefined` section, a subsection named `memory_zones` can be defined. That second contains a list of dictionaries with the following keys:
@@ -56,7 +56,7 @@ By default, code in any given source file is assembled into the `GLOBAL` memory
 .memzone <memory zone name>
 ```
 
-Note that the `GLOBAL` memory zone name can be used this directive. Subsequent assembly code lines will be compiled into the indicated memory zone scope until the end of the current assembly file or another directive that changes the memory zone scope. Addresses assigned to the byte code will be per the code ordering. 
+Note that the `GLOBAL` memory zone name can be used this directive. Subsequent assembly code lines will be compiled into the indicated memory zone scope until the end of the current assembly file or another directive that changes the memory zone scope. Addresses assigned to the byte code will be per the code ordering.
 
 Non-contiguous uses of a given memory zone scope will be compiled as if the assembly code in each use instance was concatenated together in the order processed by the assembler.
 
@@ -75,7 +75,7 @@ Where `<address offset value>` is the positive offset from the start of the spec
 .org 0x0100 "variables"
 ```
 
-Would be the same as setting the current origin to `0x2100` in the `GLOBAL` scope. 
+Would be the same as setting the current origin to `0x2100` in the `GLOBAL` scope.
 
 Not specifying a `<memory zone name>` will cause the `<address offset value>` to be interpreted as an absolute address. So:
 
@@ -85,7 +85,7 @@ Not specifying a `<memory zone name>` will cause the `<address offset value>` to
 
 Will set the current address to $3400. This absolute address interpretation is regardless of how the `GLOBAL` memory zone is defined.
 
-When using `GLOBAL` as the `<memory zone name>` then `<address offset value>` will be interpreted as an offset form the start of the `GLOBAL` memory zone as it would with any other named memory zone. If the `GLOBAL` memory zone has not be redefined, the net effect is the same as using `.org` with an absolute address. However, if the start address of the `GLOBAL` memory zone has been redefined, then `<address offset value>` will be applied as an offset from the redefined start of `GLOBAL`. 
+When using `GLOBAL` as the `<memory zone name>` then `<address offset value>` will be interpreted as an offset form the start of the `GLOBAL` memory zone as it would with any other named memory zone. If the `GLOBAL` memory zone has not be redefined, the net effect is the same as using `.org` with an absolute address. However, if the start address of the `GLOBAL` memory zone has been redefined, then `<address offset value>` will be applied as an offset from the redefined start of `GLOBAL`.
 
 
 ### Memory Zone Error Conditions
@@ -94,4 +94,4 @@ The following conditions will be considered an error:
 * A defined memory zone not fully contained by the `GLOBAL` memory zone.
 * A memory zone defined more than once.
 * Byte code that get assigned to the same absolute memory address.
-* Memory zone names that have spaces or non-alphanumeric characters. 
+* Memory zone names that have spaces or non-alphanumeric characters.

docs/named-memory-zones-requirements.md

@@ -46,4 +46,3 @@ bespokeasm compile -p -c eater-sap1-isa.yaml my_code.sap1
 
 ### Syntax Highlighting
 BespokeASM has the ability to generate for various popular text editors a syntax highlighting language extension specific to this Ben Easter SAP-1 instruction set. [See the documentation](https://github.com/michaelkamprath/bespokeasm/wiki/Installation-and-Usage#installing-language-extensions) for information for on how to install and use the language extensions.
-

examples/ben-eater-sap1/README.md

@@ -31,4 +31,3 @@ done:
     lda result          ; Load final product value
     out                 ; Display product value
     hlt                 ; Halt
-

examples/ben-eater-sap1/multiplication.sap1

@@ -1,10 +1,10 @@
 ; LED Chaser
 ;
-; This program causes the LEDs on the KENBAK-1 display to "bounce" between the 
+; This program causes the LEDs on the KENBAK-1 display to "bounce" between the
 ; edges or between positions corresponding to pressed input buttons. The
-; bouncing algorithm doesn't handle being too tightly contaied and so 
+; bouncing algorithm doesn't handle being too tightly contaied and so
 ; the boucing will "tunnel" through the barrier in those cases ;-)
-; 
+;
 
 start:
     ld a, 1
@@ -68,7 +68,7 @@ wall_bounce:
 .bounce_right:
     ld a, %01000000             ; load A with new ball position
     ld [ball_position], a       ; update ball position variable
-    jp main_loop 
+    jp main_loop
 
 
 ; toggle_direction
@@ -90,7 +90,7 @@ toggle_direction:
 ; update_display
 ;   Updates the display register to have a combination of the ball poisiton
 ;   and the buttons pressed based on PWM status.
-; 
+;
 PWM_MASK = %00000111
 update_display:
 	.byte 0					   ; return address storage
@@ -113,4 +113,4 @@ loop_counter:
 ball_position:
     .byte 0
 left_right:
-    .byte 0
+    .byte 0

examples/kenbak-1/led-bouncer.kb1

@@ -57,4 +57,4 @@ delay:
     sub b, 1                    ; subtract one from B
     jpnz b, .loop               ; if B is not zero, continue with loop
 .end:
-    jp [[delay]]                ; return to caller
+    jp [[delay]]                ; return to caller