Possible Instruction Prefix Support for XO-CHIP

[Bandock]

Thought I would bring up an interesting concept I would like to share from something I thought up about some time ago when I was working on my own extension (which is HyperCHIP-64). Before I talk about it, I would like to mention in the earlier draft of my extension (from 2020), it was suggesting the use of bank switching for operating data and code as a method of 16-bit addressing. That's where I would like to talk about the Instruction Prefix concept.

As you probably already know from earlier experience, instruction prefixes can be very useful where they can affect whatever instruction follows it (depending on what kind of instruction it is). This draws inspiration from the x86 platform as it has many prefixes (with the operand size prefix being a common one). My HyperCHIP-64 extension currently has two functioning instruction prefixes. The first one (which resides at FNB0) extends the absolute address operand by 4 bits, which is perfectly compatible with several instructions (such as 1NNN (Jump), 2NNN (Call), ANNN (i := NNN), and BNNN (Jump NNN + V0)). The second instruction prefix I introduced (which resides at FXB1) allows overriding the default register operand (which in this case, affects only the BNNN (Jump NNN + VX) instruction at present).

Definitely do not need to replace the F000 NNNN instruction (in fact, I recently added it to my extension for compatibility with XO-CHIP) as it can be faster (at least with how my emulator/interpreter currently handles prefixes). This is just a concept I thought I would share while I was working on my own extension. Main purposes behind these prefixes is it helps preserve compatibility with the original instructions while extending their functionality. Also working out details for future prefixes (one for a possible secondary delay timer).

You do not have to accept this idea. Thought I would share it like I said in case you do want to implement it. ;)

[JohnEarnest]

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.

[JohnEarnest]

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.

[Bandock]

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.

[Bandock]

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.