Hi,
On Tue, 14 Dec 1999, Dmitry Jemerov wrote:
> BTW, I'm very eager to hear your feedback about scidisasm. Does it work at
> all?
Yes, it works nicely. Spams a whole directory with script files, though
;-)
> Is it useful for you?
See below...
> What improvements can you suggest?
First, you might get rid of the libsciconsole dependancy and use a printf
implementation of sciprintf in scidisasm. This might require moving some
disassembly code from src/console to src/core, where it belongs, but it
would also remove the requirement to provide graph_update_box() (which
shouldn't have been required in the first place; as you pointed out, this
is dependancy is only due to braindead design).
Considering that some parts of it are an integral part of FreeSCI now, I'd
suggest slicing src/console into two parts and dividing them up between
src/core and src/graphics. Unless you really want to do that, I'll take
care of it.
Second, the output behaviour is *very* complete right now; my
recommendation would be to allow disassembling of selected scripts, or
even specific classes or class selectors, for debugging purposes.
Providing a target file- possibly stdout- should be an option, too. Also,
I'm not sure whether the file suffix .script is very descriptive;
something like .sci, .scis or .scs (or whatever) might be better. I'm not
sure about that one, though.
Third, the output is currently set to provide as much information as
possible. This creates redundancies; I'd suggest removing (or providing
options to remove) the opcode offsets and jump target addresses (replacing
them with jump labels should be better).
Also, I'd recommend displaying the data sizes ([B], [W]) differently
(maybe a simple suffix or prefix notation, like ldi_W), to ease tokenizing
for assemblers. Tabifying the output code and providing extra information
(redundant data) as comments should help further.
Personally, I'd like to see the output cooperate with Lars' assembler
(though the assembler will need some more work, as pointed out in the
TODO file).
> I'm not yet
> done with it, so expect more features and still better quality of
> disassembled code.
The disassembler will be an excellent tool to have around. My guess is
that the people wanting to develop SCI games will like it even more, but
I'm confident that it will help us in our debugging/sci research efforts,
too.
llap,
Christoph
