Xpantastic!

Hi Jeremy,

Yes, that looks great. The indentation alone is a massive help. Is that some sort of VB-like format it's generating? Can you output a more abstract, structured format (e.g. in XML)?

We're drifting somewhat off-topic for this list, so feel free to email me privately if you like.

Cheers,

John :^P  

On Tuesday, 3 April 2012 at 16:52, Jeremy Smith wrote:

>  
> I wasn't very clear about my decompiler and what it does, etc, so I'll  
> explain.
>  
> Example here:
>  
> http://www.decompiler.org/zol.usub_4BE6.txt [original 6502 code]
> http://www.decompiler.org/zol.usub_4be6.code.txt [decompiled code]
>  
> The whole idea is to get rid of all register assignments, and also  
> eliminate the use of the stack. Also, it deals with CPU flags.
>  
> It does this by having 3 kinds of variable:
>  
> *LLocal (a register used as a loop counter)
> *BLocal (branch local; a register or stack is assigned in an If or  
> If/Else block)
> *FLocal (a register or stack is the return value from a function)
>  
> Any Global variable, which in most CPUs is just RAM, is not filtered out.
>  
> Loops are found, as are any amount of nested If/Else's, and Goto's are  
> eliminated. (except for jumps from inside a loop).
>  
> The point of my decompiler, then, is not to output code that would  
> compile in a C compiler, but to make assembly code much easier to read -  
> and much faster to understand. Then you modify the assembly code to do  
> what you want.
>  
> As an example, I've decompiled a game and I could see what the function  
> (which draws the game screen) did, and how it worked, very quickly.
>  
> Also, it can output annotated assembly language, and it can output  
> addresses before each line of code, so you can load the decompiled code  
> into a disassembler, and it shows you the code alongside the code in memory.
>  
> As for the 6809, I'll look into getting a disassembler for it and get to  
> writing a module.
>  
> Cheers,
>  
> Jeremy.
>  
>