Re: [hatari-devel] Debugger features ideas/wishes

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


> in the case of this disasm in ST ROM for example :
> 
> 00FC058A 196f 0003 860d           MOVE.B (A7,$0003) == $00003789 [bc],(A4,-$79f3) == $00fb8c5f [ff]
> 
> do you think it could be possible to not just return a 'char *' with the whole line, but maybe a way to return several char * :
>  - the bytes for the opcode : 196f 0003 860d
>  - the 'raw' disasm : MOVE.B (A7,$0003),(A4,-$79f3)
>  - the 'evaluated' content of source : $00003789 [bc]
>  - the 'evaluated' content of dest : $00fb8c5f [ff]
> 
> this way, we could display the disasm with the raw part that can be copied directly into a text editor and assembled if needed.
> And evaluated content of source/dest can be shown elsewhere on the disassembly line if needed
> 
> instead of a simple text window, one could even imagine a GUI for the disasm with 5 colums (address, bytes opcodes, disasm, evaluated source, evaluated dest), which is not possible at the moment because everything is merged into a single char *
> 
> I don't remember if there's a GUI for disasm in WinUAE, but as someone is working on such thing for hatari, it could be a useful addition to be able to split the disasm into several columns.
> 
> what do you think ?

It sounds not worth the trouble, also I don't think it can work in all situations because for example some instructions can have multiple "temporary effective addresses" (like 68020+ new addressing modes), some FPU and 68030 MMU instructions also can be quite "non-standard".

It would be relatively easy to "mark" different parts of disassembly string (with some special values or in a separate array) and let the GUI to do the parsing.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/