[Scummvm-cvs-logs] SF.net SVN: scummvm:[52051] tools/branches/gsoc2010-decompiler/decompiler/ doc

pidgeot at users.sourceforge.net pidgeot at users.sourceforge.net
Fri Aug 13 01:51:49 CEST 2010


Revision: 52051
          http://scummvm.svn.sourceforge.net/scummvm/?rev=52051&view=rev
Author:   pidgeot
Date:     2010-08-12 23:51:49 +0000 (Thu, 12 Aug 2010)

Log Message:
-----------
DECOMPILER: Add todo list to documentation

Modified Paths:
--------------
    tools/branches/gsoc2010-decompiler/decompiler/doc/doc.tex
    tools/branches/gsoc2010-decompiler/decompiler/doc/restrictions.tex

Added Paths:
-----------
    tools/branches/gsoc2010-decompiler/decompiler/doc/todo.tex

Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/doc.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/doc.tex	2010-08-12 23:50:20 UTC (rev 52050)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/doc.tex	2010-08-12 23:51:49 UTC (rev 52051)
@@ -14,6 +14,7 @@
 \input{cfg}
 \input{codegen}
 \input{restrictions}
+\input{todo}
 %\newpage\listoffixmes
 
 \end{document}

Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/restrictions.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/restrictions.tex	2010-08-12 23:50:20 UTC (rev 52050)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/restrictions.tex	2010-08-12 23:51:49 UTC (rev 52051)
@@ -2,7 +2,7 @@
 This section describes restrictions and limitations that are currently placed on the individual engines that have been implemented.
 
 \subsection{SCUMMv6}
-roomObj scripts have a header specifying offsets for various verbs. This is currently ignored, and the script is treated as a single piece of code.
+roomObj scripts have a header specifying offsets for various verbs. This is currently ignored, and the script is treated as a single piece of code; it would be more appropriate to create functions from these and properly treat stopObjectCodeA/B as returns.
 
 \subsection{KYRA2}
 The decompiler has only been tested with English scripts (.EMC files) from the Kyra 2 demo. It is possible that some scripts from the full version misbehave somehow; as I do not own the game, I cannot be sure of this.

Added: tools/branches/gsoc2010-decompiler/decompiler/doc/todo.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/todo.tex	                        (rev 0)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/todo.tex	2010-08-12 23:51:49 UTC (rev 52051)
@@ -0,0 +1,43 @@
+\section{To-do list}
+During the course of developing the decompiler, various ideas have been considered for implementation in the decompiler, but not all of them could be implemented within the given timeframe.
+
+Following is a description of known issues and enhancements that would be nice to see in the decompiler at some point in time.
+
+Note that the order of the issues is not necessarily indicative of the priority that should be given to each issue.
+
+\subsection{Allow conditional jumps to be used for break/continue}
+Currently, only unconditional jumps are allowed for break/continue. However, where the code is similar to \code{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 is not used in SCUMMv6 (there is 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\textbackslash skull.emc, 0x0578) - but it did not look like a loop. That, however, does not 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 is not used in Kyra, so this will have to be deferred until we have an engine which needs it.
+
+\subsection{Engine-specific arguments}
+It would be good to replace the current --is-talkie flag and make this engine-specific so it is clear what is supported where. Simliar things may be needed for other engines, e.g. a platform switch for Kyra1.
+
+One way to do this is to parse arguments in two passes; one for the generic arguments and one for arguments specific to the specified engine. The engine will then have to pass some information to us so we can use Boost.ProgramOptions to do the actual parsing.
+
+For help texts, we can require that if an engine is specified when using -h, we output the help text for that specific engine. This will avoid output from engines other than the one the user is looking for.
+
+\subsection{Re-enable short-circuit detection}
+Currently the short-circuit detection is disabled because it requires some extra handling in code generation which is not there yet (you have to analyze each jump more closely).
+
+\subsection{Reduce number of parentheses}
+Right now, the decompiler is completely paranoid about parentheses, inserting them pretty much anywhere it can get away with it. This should be improved, so we reduce the number of them; e.g. by checking the type of operands and only adding parentheses if the operand type can cause problems.
+
+\subsection{Refactor design}
+While a decompiler is almost by nature going to be somewhat complex, the current design might be a little too complex in a few places.
+
+When time permits, it would be a good idea to take another look at the design and see if and where improvements can be made.
+
+\subsection{Refactor disassemblers to accept a SeekableReadStream}
+It would be desirable if disassemblers accepted a \code{Common::SeekableReadStream} instead of a \code{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 \code{ReadStream}, \code{WriteStream}, and \code{SeekableReadStream} to begin with, and make \code{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.
+
+\subsection{SCUMM: Rewrite jump 0 at end of script to infinite loop}
+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 cannot.


Property changes on: tools/branches/gsoc2010-decompiler/decompiler/doc/todo.tex
___________________________________________________________________
Added: svn:mime-type
   + text/plain
Added: svn:keywords
   + Date Rev Author URL Id
Added: svn:eol-style
   + native


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.




More information about the Scummvm-git-logs mailing list