From: Philipp K. K. <pk...@sp...> - 2006-05-01 18:27:13
|
Does anyone know about a Z80 decompiler? Philipp |
From: Zik S. <zik...@gm...> - 2006-05-01 23:33:36
|
Disassembler? That's relatively easy. If you want a decompiler what language do you want it to decompile to? Cheers, Zik On 02/05/06, Philipp Klaus Krause <pk...@sp...> wrote: > Does anyone know about a Z80 decompiler? > > Philipp > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Peter <pl...@ac...> - 2006-05-02 14:08:48
|
On Tue, 2 May 2006, Zik Saleeba wrote: > Disassembler? That's relatively easy. > > If you want a decompiler what language do you want it to decompile to? You have three guesses (hint: this is the sdcc list ...) Peter |
From: Richard E. <ed...@id...> - 2006-05-02 17:23:46
|
Have you ever looked at the code that the compiler produces? How useful would it be to have that same level of "logic" used to reverse the process? Have you ever encountered a "decompiler" of any sort for any CPU? Why do you suppose that is? Just try disassembling the executable code produced by the compiler. Does that produce code that you'd like to use? regards, Richard Erlacher ----- Original Message ----- From: "Peter" <pl...@ac...> To: <sdc...@li...> Sent: Tuesday, May 02, 2006 8:08 AM Subject: Re: [Sdcc-user] Z80 decompiler? > > > On Tue, 2 May 2006, Zik Saleeba wrote: > >> Disassembler? That's relatively easy. >> >> If you want a decompiler what language do you want it to decompile to? > > You have three guesses (hint: this is the sdcc list ...) > > Peter > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Peter <pl...@ac...> - 2006-05-02 17:35:19
|
On Tue, 2 May 2006, Richard Erlacher wrote: > Have you ever looked at the code that the compiler produces? How useful > would it be to have that same level of "logic" used to reverse the process? > > Have you ever encountered a "decompiler" of any sort for any CPU? Why do you > suppose that is? Just try disassembling the executable code produced by the > compiler. Does that produce code that you'd like to use? Such things exist and they work as long as the compiler is not optimizing. The result may not resemble exactly the source, and all symbols will be 'obfuscated'. The tools rely on knowledge of the code that the compiler emits, by construct. Peter |
From: <Ant...@se...> - 2006-05-02 18:17:42
|
DCC is the only real C decompiler I've seen. It's for 8086 It knows the signatures for very few compilers. I don't think optimization is a problem. Obviously it can't put back code that did nothing and the compiler threw away! But tracking variables through the basic ALU operations applied to registers will work whatever optimisation occurs. The C code you get back might be more optimised C code, or less portable C code. OTOH it's source is GPL. http://www.itee.uq.edu.au/~cristina/dcc.html When I looked at it, it was of no practical use for my needs unless I spent a lot of work "porting" it. It probably requires a a lot of work to "teach" it about a new compiler and library, which is OK for major static distributions like Microsoft C. But embedded tools like SDCC change frequently and the users often recompile the library to suit their taste. Some will make major changes to the emitted code depending on switches like re-entrancy, banking, or memory type of the C stack. Even memory layout of an executable is usually customised to the job. Here is another interesting decompiler which appears to be developed from DCC concepts but not code: http://www.backerstreet.com/rec/rec.htm Ant ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel. |
From: Peter <pl...@ac...> - 2006-05-02 17:40:00
|
On Tue, 2 May 2006, Richard Erlacher wrote: > compiler. Does that produce code that you'd like to use? Let's say I would hate to use it but I would probably lack choices and take it as is to add my functionality as required, or to revive a long-dead apparatus and interface to it (hopefully). Peter |
From: Richard E. <ed...@id...> - 2006-05-02 17:51:38
|
Peter, It depends on the "apparatus" in question, of course, but for Z80/8080 there are LOTS of tools available. I've not seen a compiler worth its salt that doesn't offer optimizations of one sort or another, and if they're available, one should probably use them. The result will be that you'll have to deal with the optimizations regardless. However, the Z80 is very easy to program in ASM, and, since it has only a small memory map, as well as a distinct I/O map, it shouldn't be hard to write driver software for nearly any device. I still deal with that sort of thing from time to time, and find that there are perfectly useable tools that run under CP/M directly on the Z80 (or a simulated version on the PC) and will readily produce useable results. However, you should also know that much of this code, i.e. the code that was, in fact, written in 'C', which language was not readily available until quite late in the Z80's market life, was not written in what's now considered standard 'C'. When I was a "serious" Z80 user, BDS 'C' was probably the most popular compiler. What is this long-dead apparatus? You never know ... perhaps someone on this list has dealt with it too. regards, Richard Erlacher ----- Original Message ----- From: "Peter" <pl...@ac...> To: <sdc...@li...> Sent: Tuesday, May 02, 2006 11:39 AM Subject: Re: [Sdcc-user] Z80 decompiler? > > On Tue, 2 May 2006, Richard Erlacher wrote: > >> compiler. Does that produce code that you'd like to use? > > Let's say I would hate to use it but I would probably lack choices and > take it as is to add my functionality as required, or to revive a > long-dead apparatus and interface to it (hopefully). > > Peter > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Peter <pl...@ac...> - 2006-05-02 19:46:49
|
On Tue, 2 May 2006, Richard Erlacher wrote: > late in the Z80's market life, was not written in what's now considered > standard 'C'. When I was a "serious" Z80 user, BDS 'C' was probably the most > popular compiler. It is now available for free I think (public domain). One can run it in a simulator and collect data for 'decompilation'. > What is this long-dead apparatus? You never know ... perhaps someone on this > list has dealt with it too. This time, it was not my request. There are a lot of Z80 based industrial controls and CNC boards that still have some life in them. Peter |
From: Philipp K. K. <pk...@sp...> - 2006-05-02 18:15:41
|
Richard Erlacher wrote: > What is this long-dead apparatus? You never know ... perhaps someone on > this list has dealt with it too. For me the problem at hand is rather simple: I have the .c file, I have the .asm generated by sdcc. Depending on the --noinduction option used the binary behaves totally different. The .asm generated by sdcc is 512 lines for the simplest test case I found and looks totally different to the one generated without --noinduction. So, I'm trying to find out, what the result of compilation by sdcc would be like when translated back to C. Maybe the difference would be easier to spot in the decompiled form than in the .asm. Philipp |
From: Richard E. <ed...@id...> - 2006-05-02 18:25:15
|
see below, plz. regards, Richard Erlacher ----- Original Message ----- From: "Philipp Klaus Krause" <pk...@sp...> To: <sdc...@li...> Sent: Tuesday, May 02, 2006 12:15 PM Subject: Re: [Sdcc-user] Z80 decompiler? > Richard Erlacher wrote: > >> What is this long-dead apparatus? You never know ... perhaps someone on >> this list has dealt with it too. > > For me the problem at hand is rather simple: > I have the .c file, I have the .asm generated by sdcc. > Depending on the --noinduction option used the binary behaves totally > different. > The .asm generated by sdcc is 512 lines for the simplest test case I > found and looks totally different to the one generated without > --noinduction. > So, I'm trying to find out, what the result of compilation by sdcc would > be like when translated back to C. > It's not clear to me what you're trying to accomplish if you have the .C file. Is that the .C file the original from which the code you wish to decompile was generated? Do you want to compare the output from different compilers? Where do you hope that will lead? Is this an "academic" exercise? I thought you were trying to rework or resurrect a driver for an obsolete bit of hardware. > > Maybe the difference would be easier to spot in the decompiled form than > in the .asm. > If you were confident that you could reverse the compilation, then perhaps. > > Philipp > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Philipp K. K. <pk...@sp...> - 2006-05-02 18:50:17
|
Richard Erlacher wrote: > It's not clear to me what you're trying to accomplish if you have the .C > file. Is that the .C file the original from which the code you wish to > decompile was generated? Do you want to compare the output from > different compilers? Where do you hope that will lead? Is this an > "academic" exercise? There's a code generation bug in sdcc (#1479882). When the --noinduction option is not used the output behaves wrong. I want to compare the output with and without --noinduction. I hope finding the bug will be easier that way, since I otherwise have to work through a thousand lines of sdcc assembler output. Philipp |
From: Ken J. <Ken...@ie...> - 2006-05-02 20:05:34
|
Those looking for a decompiler might check out boomerang: <http://boomerang.sourceforge.net/> It apparently works to a limited degree for x86 and sparc, but it's intent is to be retargetable. So in theory, a motivated developer could extend it to work with Z80 code. But it won't be complete tomorrow. -Ken Jackson |
From: Peter <pl...@ac...> - 2006-05-02 20:05:51
|
On Tue, 2 May 2006, Philipp Klaus Krause wrote: > Richard Erlacher wrote: > >> What is this long-dead apparatus? You never know ... perhaps someone on >> this list has dealt with it too. > > For me the problem at hand is rather simple: > I have the .c file, I have the .asm generated by sdcc. > Depending on the --noinduction option used the binary behaves totally > different. > The .asm generated by sdcc is 512 lines for the simplest test case I > found and looks totally different to the one generated without > --noinduction. > So, I'm trying to find out, what the result of compilation by sdcc would > be like when translated back to C. > Maybe the difference would be easier to spot in the decompiled form than > in the .asm. Understood. I don't think that there is a decompiler for sdcc but one that is easily tweaked could be found. Some links: http://www.google.com/search?hl=en&lr=&q=decompiler&btnG=Search http://boomerang.sourceforge.net/ a pretty good example as to what you can expect: http://boomerang.sourceforge.net/cando.php?hidemenu (this is for x86). Of course it would help a lot if the compiler authors (who did the back end) would collaborate with this. In my limited experience, undoing the loophole optimizer's work is the hardest, after that it is relatively straightforward to make sense of the spagetti. The key part about a decompiled program is, imho, that it can be recompiled and debugged (step by step, breakpoints etc). Peter |
From: Zik S. <zik...@gm...> - 2006-05-02 22:01:10
|
I co-wrote a decompiler a couple of years ago. My experience when working on this project was that it's essentially impossible to output code that looks much like the original source code at all. What you get tends to be messy code with strange looking constructs, somewhere between the original source code, the optimised version and something else the decompiler has created. Decompilers are useful for making the nightmare of recovering lost source code easier but personally I wouldn't recommend them for your application - you'll probably lose the detail you're looking for in the decompliation process. Overall I think it'd probably be easier for you to use the .asm file. But YMMV. Cheers, Zik On 03/05/06, Philipp Klaus Krause <pk...@sp...> wrote: > > For me the problem at hand is rather simple: > I have the .c file, I have the .asm generated by sdcc. > Depending on the --noinduction option used the binary behaves totally > different. > The .asm generated by sdcc is 512 lines for the simplest test case I > found and looks totally different to the one generated without > --noinduction. > So, I'm trying to find out, what the result of compilation by sdcc would > be like when translated back to C. > Maybe the difference would be easier to spot in the decompiled form than > in the .asm. > > Philipp |
From: <Ant...@se...> - 2006-05-02 15:10:28
|
There is only one "experimental" working example of a decompiler (hexfile to C) that I ever found. Start with a disassembly listing and work from there. You quickly learn how the compiler did things and then it just takes time. Errors creep in and it has to be debugged over again. It is rewarding, both in what you can learn and the power it gives to change the program. Reverse-engineering is unlikely to be easier than writing from scratch and not as useful, where all the inputs and outputs known. But there is usually some part of operation of a program that is not documented. In one case the only way I could keep my EPROM programmer working on a modern PC was to reverse the software into source and fix it. To reverse Z80 or 8051the best tool is IDA4.1 I used it for 16-bit 8086 DOS code, and the automated analysis that IDA can do is very impressive. It identified switch-statement constructs and function arguaments, and recognised and named all the library functions. You can shell out cash for the latest MS-Windows version of IDA Pro, but IDA4.1 is free, un-knobbled, and includes Z80 & 8051. But it's a DOS program. If you want IDA4.1 I'll e-mail it as it only seems to be found now on warez & crackz sites and visiting them will give you viruses, trojans & spyware unless your PC is very well protected. And no download of IDA. Ant ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel. |
From: Peter <pl...@ac...> - 2006-05-04 07:15:38
|
On Tue, 2 May 2006 Ant...@se... wrote: > > There is only one "experimental" working example of a decompiler > (hexfile to C) that I ever found. Start with a disassembly listing and work > from there. You quickly learn how the compiler did things and then it > just takes time. Errors creep in and it has to be debugged over again. > > It is rewarding, both in what you can learn and the power it gives to > change the program. Reverse-engineering is unlikely to be easier > than writing from scratch and not as useful, where all the inputs and > outputs known. But there is usually some part of operation of a > program that is not documented. In one case the only way I could > keep my EPROM programmer working on a modern PC was to > reverse the software into source and fix it. > > To reverse Z80 or 8051the best tool is IDA4.1 > I used it for 16-bit 8086 DOS code, and the automated analysis > that IDA can do is very impressive. It identified switch-statement > constructs and function arguaments, and recognised and named > all the library functions. > > You can shell out cash for the latest MS-Windows version of > IDA Pro, but IDA4.1 is free, un-knobbled, and includes Z80 & 8051. > But it's a DOS program. dosemu. But an open source program that can be debugged and improved would be better. Peter |