It would be desirable if disassemblers accepted a Common::SeekableReadStream instead of a Common::File, for easier integration with other tools and possibly ScummVM itself.

Unfortunately, streams do not currently exist in the tools repository. To get around this, it should be enough to move over ReadStream, WriteStream, and SeekableReadStream to begin with, and make Common::File subclass from the required streams.

This is very much an *optional* task, and only to be done near the end, if time permits - it is not really within the scope of the project, and it would be fairly easy to make the switch after GSoC.

Currently, only unconditional jumps are allowed for break/continue. However, where the code is similar to

if (...) break;

it is a simple and obvious optimization to not output an unconditional jump and just make the proper address the target of the conditional jump from the if.

Support for this should be added to the analysis. Should be doable by also checking destinations of unmarked conditional jumps, since ifs are marked after breaks and continues - so simply add that to the initial filter and make sure we process the right (non-sequential) target vertex.

Classifying as an enhancement since it appears this optimization isn't used in SCUMMv6 (there's an if (...) break in tentacle/room-13-206, but the break is a separate jump). Not sure if KYRA uses it - a cursory scan of the KYRA2 demo suggests that it could use an optimization, as I found only 1 occurence of a c1_ifNotJmp immediately followed by a c1_jump (skull\skull.emc, 0x0578) - but it didn't look like a loop. That, however, doesn't prove that KYRA actually uses the optimization - it could simply be that such a piece of code was never used.

As far as I have been able to tell, this optimization really isn't used in Kyra, so this will have to be deferred until we have an engine which needs it.

Currently the short-circuit detection is disabled because it requires some extra handling in code generation which isn't there yet (you have to analyze each jump more closely).

This appears to be quite complex, and given the situation, it seems more sensible to postpone this until after GSoC.

After redesigning the CFG, I should look at this again and see if that has made it simpler to implement.

Several SCUMM scripts end with a jump 0, making them infinite loops.

It would be nice if this could be expressed accordingly, but this does not appear to be a trivial task; some jump 0s in a script could be expressed as a continue, others can't.

The CFG anaylsis, while certainly functional, is not entirely pretty right now.

It would be a good idea to go over this and see if it can be made better somehow, e.g. by incorporating more of the syntax as nodes in the graph.

For non-stack-based engines, it would be a bit nicer if they could just give us a condition to use in an if/while/do-while, instead of currently requiring that the value is on the top of the stack.

A very simple way to do this would be to simply define a getCondition on Value that takes the same parameters as processInst, with a default implementation that just calls processInst and pops and returns the top value from the stack - this means no changes would be required to exisiting engines, and new engines can override this method as they see fit.