Resolve two versions of disassembler interfaces

[emustudio]

Resolve two versions of disassembler interfaces

[vbmacher]

In my opinion, calling the disassembler as "Decoder" is more general. In fact, if we would have only real CPUs that will really want to disassemble instructions, "Disassembler" is cleaner and more correct name.

By trying to resolve the problem, we can now think about emuStudio purpose - to support not only real architectures, but also abstract ones. We cannot speak about disassembling an instruction in terms of abstract machines, because the instruction itself is very abstract and does not have composed (assembled) binary form. Therefore, decoding is more appropriate term - and can be used instead of disassembling without loosing the meaning.

Therefore, I suggest to "import" methods located inside IDisassembler into IDecoder interface, remove the origin and the same do with CPUInstruction. Also, SimpleDisassembler class should be renamed to SimpleDecoder, implementing as many methods as it can without loosing generality. Within edigen project, the decoder should then inherit from the SimpleDecoder class.

[sulir]

(Edited) OK, now I have read this once again and it seems like a good idea.

[vbmacher]

But we might want to still think about possible breaking Single Responsibility principle (SRP). There are in fact two places where the disassembler/decoder is used. The first one is directly in emulation - new ability to use decoder generated by edigen, and the second one is in displaying disassembled instructions. Merging these interfaces into single one can therefore break the SRP.

If the way how disassembling is done changes in future, we would need to change the same interface/class for decoder as well. The same holds for the decoder changes. There is a good thing in Java - we can inherit from multiple interfaces.

I think we are now challenging the issue for defining correct naming or terms - disassembling vs. decoding. We must take into account both real and abstract machines and their way of instruction processing. The other point of view is when the instruction is displayed. Now I have to go, but we can discuss this.

[vbmacher]

Everything solves commit 0fe9d63. Please have a look at it and tell your opinion.

[sulir]

The changes are good, especially the use of annotations.

But why do AbstractDisassembler implement both Disassembler and Decoder? I think that implementing the Disassembler interface would be sufficient. Decoder and disassembler should be separated, because we have DecodedInstruction and DisassembledInstruction.

[vbmacher]

Yes, I thought about it. Therefore I asked, I was deciding between this variant and about what you suggested. The reason why I finally chose this one was that Edigen can generate disassembler as well and probably it will be a single class, because disassembler will use decoder tables to do its work. Therefore I thought it won't do much harm to have a class implementing two interfaces.

But I agree it's not good to have AbstractDisassembler implementing Decoder. Either it should have different name, or there should be two classes.

Let's think. Can be disassembler implemented using only decoder interface generally? If yes so, the abstract disassembler can become DisassemblerImpl and there won't be a reason for user to implement one. However - in either way - disassembler uses Decoder.., so there is a relationship between the two, disassembler is not decoder. So you are right, and it need to be changed.