rzumer / dez80 Goto Github PK

It is currently easy to generate and format invalid instructions. Since this can result in oddly-formatted output or crashes due to hitting unimplemented!() match arms, it would be best to restrict instructions to standard ones.

One way would be to make the fields pub(self) with public accessors, add validation through the new() constructor, and ensure that from_bytes() generates instructions directly to prevent redundant validation.

Only one of them is needed.

It is preferable to rely on as few 3rd-party services as possible.

This encoding is invalid and is semantically equivalent to NOP NOP. According to this resource there is no such instruction if I'm reading this right.

Still the function returns Ok(some_instruction).

Is it possible I've found a bug?

And anything else that is generally useful to simplify imports.

It can be a pain to identify where we are in the decoding process when implementing an emulator, and this would avoid having to store fetched bytes elsewhere temporarily. For example DJNZ has an extended M1 cycle followed by an operand read, so at the stage where the extension has to be inserted, the decoder result is still an error, and we can't blindly fetch the operand; cycle timing is critical, because some input lines are sampled regularly at a certain clock (edge) of every machine cycle.

When fetching the opcode byte, it's not possible to identify DJNZ definitely unless we know both the opcode and the decoder state from a try_decode() call either before or after it. It can be too restrictive depending on how low-level the emulator gets.

Another example is LD (IX/IY+d), n. This is the only indexed instruction that is not in the bitwise instruction table and does not end with the displacement fetch. When this occurs, the displacement computation overlaps with the final fetch cycle. But since the decoder state (when invoking try_decode() with each pushed byte) goes RootOpcode, IndexedOpcode, IndexedOperand, IndexedOperand, we can't distinguish between other indexed 4-byte instructions unless we know the full context of the decoding process. So we either need to save some more intermediary information or add IndexedDisplacement to replace IndexedOperand when the next value that the decoder needs is the displacement.

Instead of returning an Option<Instruction> from Instruction::decode(), a Result would allow providing the user more details on where an error may have occurred (e.g. differentiating read errors from decoding errors).

The current one is a bit convoluted. Instruction::from_bytes() is more intuitive in comparison, so the public single-instruction decode function should be similar, and abstract the conversion from Read to Peekable<Bytes>.

Unlike the other "Memory"-prefixed operands, it does not imply immediate access to the memory. It is used for relative jumps, so only the program counter is evaluated and modified. For CPU implementations this can be confusing.

Invalid indexed instructions (i.e. instructions that have a 0xDD or 0xFD prefix, but for which no valid instruction can be decoded using the following opcode byte) ignore the index prefix and restart decoding from the next byte. This behavior is correct, but if decoding the prefix and its following instruction requires additional cycles compared to decoding the instruction without the invalid prefix, an implementation using DeZ80 may not be able to accurately calculate the length of such an instruction. If so, we should provide additional data, probably in the form of a new instruction type, such as the recently-removed Noni.

Reference: https://clrhome.org/table/

Definitely Debug as well.

Instructions are now all defined and the model is specific enough that it is possible to losslessly re-assemble decoded (or manually generated) instructions. This could be useful for debugging or other use cases, so it is a feature worth adding.

Since the instruction module is getting very large, it might be a good idea to extract the decoder to its own module, and do the same with the encoder.

It can be difficult for implementations to separate 8- and 16-bit paths without operands providing that information. One way to do this would be to have two operand types defined, one for 8-bit operations and the other for 16-bit ones, for those addressing modes that can support both.

Basically feed a stream of raw bytes that should decode to at least one instance of every instruction.

All members of decoded instructions should be tested.