Possible Instruction Prefix Support for XO-CHIP about octo HOT 4 CLOSED

One other point to consider:

On XO-CHIP, overwriting the address part of an i := long NNNN instruction is a common idiom for achieving pointer-indirection. Using prefix instructions means the 16-bit address would be spread across 4 non-contiguous bytes. Modifying such code in-place at runtime is quite tricky, and may involve shifts and masks, rendering self-modifying code impractical.

from octo.

Thanks for letting me know about this idea.

In the case of FXB1, I don't think the feature adds much to the programming model. Due to the mechanics of load and save, register v0 is commonly used as a temporary working register in practice; it simply isn't much of a convenience to be able to specify a different register as the offset. As you note yourself, despite the intention of generality, the feature only composes naturally with one existing chip8 instruction.

As for FNB0, while having a wider immediate operand for jump/jump0/call/i:= is potentially useful in light of a 16-bit addressing space, it poses many subtle problems. In effect, prefixes produce a collection of four (five, counting FXB1) new double-width instructions (in addition to XO-CHIP's existing i := long NNNN). This in turn requires either further complication to the conditional-skip instructions or very error-prone behavior in their presence. Instruction selection for assemblers offering structured control constructs (like Octo) become much more complex and harder for programmers to reason about. The functional overlap with i := NNNN also leads to potential confusion for programmers and implementors alike.

Having written a large number of complex XO-CHIP programs, I'm not convinced that expanding "code ram" is all that important. There are already many approaches to overcome the limit in software, including software bank-switching and writing interpreters. I feel that in many ways, the limits on code space produce interesting creative constraints for the platform.

Please keep in mind that adding instructions always comes with costs: complexity for documentation, complexity for interpreters, complexity for tooling, complexity for understanding. These costs are multiplied across every implementation and every programmer who wishes to use the platform. History is littered with dozens of attempts at extending CHIP-8 which were only used for a single program, or sometimes never used at all! I feel that it is very important to ensure that any extension to the programming model is strongly justified in a practical need, and even then, chosen in aesthetic balance with the creative limitations and intellectual challenges offered to programmers.

For these reasons, I do not intend to adopt your proposed prefixes as part of XO-CHIP.

from octo.

That is perfectly understandable. In regards to the skip instructions, that's why I chose to limit the checks to the F?B? range in a loop. When the F000 NNNN instruction is encountered, it breaks the loop to prevent strange bugs from happening in the event it happens to match said prefixes.

I found the best and easy way to handle instruction prefixes in my implementation is just treat them like normal instructions (which they consume cycle). Whatever prefix is decoded, a bit in the prefix flag (8-bit currently) is enabled. In some ways, this method can be slower than the F000 NNNN instruction since it makes a compromise. I thought about putting it together in one cycle, but does lead to a more complex implementation.

Regardless though, I respect your decision to not adopt it.

from octo.

After discussing with a few others on this subject and thinking about what you said, I've decided to go ahead and scrap the instruction prefix concept from my specification (and other projects currently utilizing it). I'll need to remove it from my emulator and my assembler (to my knowledge, I'm probably the only one who has created any program using these prefixes to begin with anyway).

Fortunately, I do have two other methods for jumping and calling to 16-bit memory addresses (in fact, can be very complimentary to self modifying code). I actually introduced those variants first before I ever thought of using instruction prefixes.

from octo.