Post by thread:[PIC] new disassembler

Hi, Just started to write a new disassembler for Microchip PICs. The project is called unPIC and the main goal of this is that all disassembler I have seen so far just made a very poor in results so I wanted to make a better one. This tool would be useful to everyone that lost his/her source or just wonderin what is in the HEX file (testing compilers / linkers for example). Currently it is in alpha state and already have some features: - loads HEX files and INC files which is coming from MPLAB - produces ASM from it with meaningful names for register files and for jump / call labels. - creates subroutine definitions - follows program logic so it understands CPU state which is important to determine which bank is used for the current instruction (later on might be followed other CPU states as well) - currently only 14bit PIC is supported, will be added 12bit very soon The tool is written in Perl script, therefore platform independent, hence need Perl to be installed. You would also need INC files from MPLAB. It is free to use, GPL, and has naturaly source (as it is a Perl script). http://sourceforge.net/projects/unpic/ I would appreciate if some of you could play with it and send back some feedback. Cheers, Tamas

1) I had to change your code a bit, because it otherwise gave a strange error message ([error] Constant name 'HASH(...)' has invalid characters). I changed the: use constant ({ INC_NOTHING => '-nothing-', INC_REGFILES => 'RegFiles', }) Into: use constant INC_NOTHING => '-nothing-'; use constant INC_REGFILES => 'RegFiles'; And then it worked fine. 2) You should probably recognize a sequence of retlw statements as a table, the way it looks now, with a comment before each retlw, makes it difficult to see what is actually happening. 3) Similar with a series of gotos: that would be a jumptable. You could even change the labels of that to read "jumptable_<>" if you want to. In general, I think it looks good... Not that my code becomes more readable with it, but it seems to do the job of disassembling. Greetings, Maarten Hofman.

Thanks for that! I do not know why I keep put '{' instead of '(' when defining hash constants :-) That will create an unnamed hash inside the real one, so that's why you had that strange message -- I am not sure why was that ok for me. So it should work like this: use constant ( # states for loading INC files INC_NOTHING => '-nothing-', INC_REGFILES => 'RegFiles', ); Will change it anyway :-) 2. The recognition of retlw and goto tables are very good idea, will work on it. Forgot to mention how to use it but presumably you had been figured it out already: > unPIC.pl p16xxx.inc yourhexfile.hex > yourasmfile.asm So that if you choose the correct INC file it has a chance to determine register files. Are all the register files were reversed correctly? Thanks, Tamas On 14/07/06, Maarten Hofman <spam_OUTcashimorTakeThisOuTgmail.com> wrote: {Quote hidden}> > 1) I had to change your code a bit, because it otherwise gave a strange > error message ([error] Constant name 'HASH(...)' has invalid characters). > I > changed the: > > use constant ({ INC_NOTHING => '-nothing-', > INC_REGFILES => 'RegFiles', > }) > > Into: > > use constant INC_NOTHING => '-nothing-'; > use constant INC_REGFILES => 'RegFiles'; > > And then it worked fine. > > 2) You should probably recognize a sequence of retlw statements as a > table, > the way it looks now, with a comment before each retlw, makes it difficult > to see what is actually happening. > > 3) Similar with a series of gotos: that would be a jumptable. You could > even > change the labels of that to read "jumptable_<>" if you want to. > > In general, I think it looks good... Not that my code becomes more > readable > with it, but it seems to do the job of disassembling. > > Greetings, > Maarten Hofman. > -

Hi, Updated in sourceforge, so now it handles those jump tables -- thanks Maarten for the ideas! Also now you can recompile the code using MPLAB. I had no problem by doing it so with my test package -- got back almost the same HEX file. But if you can't build the disassembled code or if the HEX differs, please raise your hand :-) I have a new idea but I am not sure if it worth the effort: I was wondering if it would be useful to write a tool that automatically translates a HEX file to another PIC. So that you have a HEX file for 16F683 and would like to use it for a different chip than that, you just apply this tool and program it to your desired chip. You do not even have to modify / recompile your source or the disassembled code. What do you recon? Regards, Tamas http://sourceforge.net/projects/unpic On 14/07/06, Tamas Rudnai <.....tamas.rudnaiKILLspam@spam@gmail.com> wrote: {Quote hidden}> > Thanks for that! > > I do not know why I keep put '{' instead of '(' when defining hash > constants :-) That will create an unnamed hash inside the real one, so > that's why you had that strange message -- I am not sure why was that ok for > me. > > So it should work like this: > > use constant ( > # states for loading INC files > > INC_NOTHING => '-nothing-', > INC_REGFILES => 'RegFiles', > ); > > Will change it anyway :-) > > 2. The recognition of retlw and goto tables are very good idea, will work > on it. > > Forgot to mention how to use it but presumably you had been figured it out > already: > > > unPIC.pl p16xxx.inc yourhexfile.hex > yourasmfile.asm > > So that if you choose the correct INC file it has a chance to determine > register files. > Are all the register files were reversed correctly? > > Thanks, > Tamas > > > > > On 14/07/06, Maarten Hofman <cashimorKILLspamgmail.com> wrote: > > > > 1) I had to change your code a bit, because it otherwise gave a strange > > error message ([error] Constant name 'HASH(...)' has invalid > > characters). I > > changed the: > > > > use constant ({ INC_NOTHING => '-nothing-', > > INC_REGFILES => 'RegFiles', > > }) > > > > Into: > > > > use constant INC_NOTHING => '-nothing-'; > > use constant INC_REGFILES => 'RegFiles'; > > > > And then it worked fine. > > > > 2) You should probably recognize a sequence of retlw statements as a > > table, > > the way it looks now, with a comment before each retlw, makes it > > difficult > > to see what is actually happening. > > > > 3) Similar with a series of gotos: that would be a jumptable. You could > > even > > change the labels of that to read "jumptable_<>" if you want to. > > > > In general, I think it looks good... Not that my code becomes more > > readable > > with it, but it seems to do the job of disassembling. > > > > Greetings, > > Maarten Hofman. > > --

> I have a new idea but I am not sure if it worth the effort: I was wondering > if it would be useful to write a tool that automatically translates a HEX > file to another PIC. So that you have a HEX file for 16F683 and would like > to use it for a different chip than that, you just apply this tool and > program it to your desired chip. You do not even have to modify / recompile > your source or the disassembled code. What do you recon? > > Sounds very interesting, if ... ... you could translate a 16F hex file to a 18F hex file. Why, some compilers don't support (yet) the 18F series, and although you wouldn't benefit (at least that's what I guess) of the extended instruction set of the 18F, you could use things like larger memory, faster clock etc. I've played with this idea myself, but other things have higher priority ;-) cheers, Stef Mientki

> I have a new idea but I am not sure if it worth the effort: I > was wondering > if it would be useful to write a tool that automatically > translates a HEX > file to another PIC. So that you have a HEX file for 16F683 > and would like > to use it for a different chip than that, you just apply this tool and > program it to your desired chip. You do not even have to > modify / recompile > your source or the disassembled code. What do you recon? I don't see how you could do that, or you must restrict the source/target pics so that a verbatim copy does the job. For instance: the EEPROM registers can be in different banks, so you'd have to add/remove bank switching, which might shift the code, so you might have to add code page switching, etc. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

and then you're basically looking at a PIC supercompiler. That might be interesting. On 7/16/06, Wouter van Ooijen <.....wouterKILLspam.....voti.nl> wrote: {Quote hidden}> > > I have a new idea but I am not sure if it worth the effort: I > > was wondering > > if it would be useful to write a tool that automatically > > translates a HEX > > file to another PIC. So that you have a HEX file for 16F683 > > and would like > > to use it for a different chip than that, you just apply this tool and > > program it to your desired chip. You do not even have to > > modify / recompile > > your source or the disassembled code. What do you recon? > > I don't see how you could do that, or you must restrict the > source/target pics so that a verbatim copy does the job. > > For instance: the EEPROM registers can be in different banks, so you'd > have to add/remove bank switching, which might shift the code, so you > might have to add code page switching, etc. > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > -

The basic idea was that this disassembler I started to work on could find all relevant places, bank switchings etc. It knows which address is referenced by what instruction. For this one the tool has to know which register file is what -- this part is already done. So I thought that if I know these info about the other PIC than it should not be a big trouble to change all of these info -- I may wrong on this, tough. Basically it is a kind of compiler, except that the input is not an ASM file (aka text file) nor a C or whatever else but a binary. My doubt about this is that the other chip may have a different clock freq so that all time related stuff would fail. For example you might have to change time scaler for watchdog or timer interrupt, and also if the code based on instruction cycles (aka an iteration calculating time, make delays etc) then you have to put nops or change values for that. And that's very hard to tell by a stupid tool which of these values have to be changed to what. Regards, Tamas On 16/07/06, Wouter van Ooijen <EraseMEwouterspam_OUTTakeThisOuTvoti.nl> wrote: {Quote hidden}> > > and then you're basically looking at a PIC supercompiler. > > That might be interesting. > > Only to check its algorithms and design a program that it would chocke > on. > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > > -

> My doubt about this is that the other chip may have a > different clock freq > so that all time related stuff would fail. For example you > might have to > change time scaler for watchdog or timer interrupt, and also > if the code > based on instruction cycles (aka an iteration calculating > time, make delays > etc) then you have to put nops or change values for that. And > that's very > hard to tell by a stupid tool which of these values have to > be changed to > what. Plenty more chances to make it fail. Just a few: - A/D acquisition time varies, also depending on source impedance - self-write algorithms are vastly different - read all erata, some chips need interesting work-arounds in some situations - peripheral control structure varies (distribution of bits over bytes, semantics of bits, etc) - stack depth: 2/8/32 - interrupts: 0/1/2 - A/D resolution: 8/10 etc etc Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

On 17/07/06, Wouter van Ooijen <wouterspam_OUTvoti.nl> wrote: > > > Plenty more chances to make it fail. Just a few: > - A/D acquisition time varies, also depending on source impedance Yes, it could be the same problem as the timer one, isn't it? - self-write algorithms are vastly different I am not sure what do you mean by? - read all erata, some chips need interesting work-arounds in some > situations I think it could be done by a 'knowladge database', so that if it is known that you should do something special to read data form here or there then it could automatically rewrite / extand that piece of code. - peripheral control structure varies (distribution of bits over bytes, > semantics of bits, etc) As long as those described in the INC file I think it is not a problem as it disassembles the code completly so you will get a 'meaning' of the code. So 'btfss INTCON, T0IE' is always that and as long as INTCON and T0IE definitions exists on both chips' INC file it could be translated fine. There might be some problem if ANDLW or similar applied to test / change more than one bits at a time. > - stack depth: 2/8/32 The basic principle was to reuse a code in a higher PIC rather than in a lower, but it might be possible to check the depth of a call flow if the code is not recursive. > - interrupts: 0/1/2 > - A/D resolution: 8/10 > etc etc Yep, those are more hard to do. Maybe that's why it is not worth the effort :-) Regards, Tamas

> > - A/D acquisition time varies, also depending on source impedance > Yes, it could be the same problem as the timer one, isn't it? no. (most?) 16F's PICs have a recommended maximum source impedance of 10k, for (most?) 18F's this is 2.5k (IIRC). IIRC (but you might need to check this) 18F's can still get the full accurcay but the acquisition time needs to be (much?) longer. So whether the program's timing needs to be changed depends on the circuit oustide the PIC. > - self-write algorithms are vastly different > I am not sure what do you mean by? read a few datasheets, for instance 16F877 and 16F877A, check how writing to the program flash is done from a running program. {Quote hidden}> - peripheral control structure varies (distribution of bits > over bytes, > > semantics of bits, etc) > > As long as those described in the INC file I think it is not > a problem as it > disassembles the code completly so you will get a 'meaning' > of the code. So > 'btfss INTCON, T0IE' is always that and as long as INTCON and T0IE > definitions exists on both chips' INC file it could be > translated fine. That's an easy one, because the semantics don't change. Now read the various A/D modules. > > - A/D resolution: 8/10 > > etc etc > > Yep, those are more hard to do. Maybe that's why it is not > worth the effort > :-) That's my idea too. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Tamas Rudnai wrote: > My doubt about this is that the other chip may have a different clock > freq so that all time related stuff would fail. That's only one of many problems. I think it would be impossible to properly track indirect addressing references. Since often run time math is used to calculate the target address, you don't know what is ultimately being addressed. This means you have to keep all RAM at exactly the same addresses on the new machine, but of course that is either impossible or leads to other problems. I'm having a hard time thinking of purpose for this tool, even if it could convert the code reliably. Why would you want to convert PIC 16 code to run on a PIC 18 at the *binary* level? With properly written source code it's not that hard but still takes some human intervention. But even if this tool worked mostly, how do you then fix the remaining bugs without source code? Normally I would say this is an answer to a question nobody asked, but in this case it doesn't even seem to be an answer. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

On 7/17/06, Olin Lathrop <@spam@olin_piclistKILLspamembedinc.com> wrote: > Tamas Rudnai wrote: > > My doubt about this is that the other chip may have a different clock > > freq so that all time related stuff would fail. > > That's only one of many problems. I think it would be impossible to > properly track indirect addressing references. Since often run time math is > used to calculate the target address, you don't know what is ultimately > being addressed. This means you have to keep all RAM at exactly the same > addresses on the new machine, but of course that is either impossible or > leads to other problems. > C compile will be quite good at this even though some people may not opt for C. Regards, Xiaofan

On 7/16/06, Tamas Rudnai <RemoveMEtamas.rudnaiTakeThisOuTgmail.com> wrote: > > Updated in sourceforge, so now it handles those jump tables -- thanks > Maarten for the ideas! Also now you can recompile the code using MPLAB. I > had no problem by doing it so with my test package -- got back almost the > same HEX file. But if you can't build the disassembled code or if the HEX > differs, please raise your hand :-) I've written a PIC disassembler (PICDIS at http://www.picemualtor.com), and would like to try yours. However, I'm running a Win2K system. What would I have to install to try it? Bill -- Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org

All the thing is that C generates larger and slower code which does not always meet the target (lack of space or timing). But once again, my original approach was that you do not have the source, not C, nor Assembly. In my case I have downloaded a HEX file and wanted to make tiny app for my RC airplane model for a safer flying. That original project used a 12F683 and I was wondering if I could put it into a 10F200 or 202. (smaller, lighter and cheaper) It seems that the original prog was written in C as I have written that disassembler to see what is going inside. It tured out that this code was full of with redundancy, and could not fit into smaller equipment -- so I have to rewrite it from scratch, anyway. But because that disassembler works fine and I am sure it could be extend it to produce even better job I thought I could go further -- but it seems that it is far from possible. Maybe just put as many comments to the disassembled code as possible to make such an implementation easier by the engeneer. I mean I could put comments like "This routine seems to be EEPROM writing" or "delay loop takes 5 cycles / 5 ms per iteration". So that using those info the engeneer could find relevant places faster. And then he/she could compile that disassembled and reimplemented source. On 17/07/06, Xiaofan Chen <spamBeGonexiaofancspamBeGonegmail.com> wrote: {Quote hidden}> > On 7/17/06, Marcel Birthelmer <TakeThisOuTmarcelb.listsEraseMEspam_OUTgmail.com> wrote: > > and then you're basically looking at a PIC supercompiler. That might be > > interesting. > > > > C is good enough, right? For example, it is relatively easier (comparing > to > port PIC16F assembly to PIC18F assembly) to port Hi-Tech PICC code to > Hi-Tech PICC18. > > Regards, > Xiaofan > -

I have written it in Perl, so it is platform independet (..or Perl dependent :-), so as long as you have Perl 5.x installed should work fine. Maybe later on will compile to Win32 exe from it as well. It is in Alpha stage and works with 14bit PICs only at the moment. You can download it from http://sourceforge.net/projects/unpic However, I am having trouble to access your web site, could you check the url please? Thanks, Tamas On 17/07/06, William Couture <RemoveMEbcoutureTakeThisOuTgmail.com> wrote: {Quote hidden}> > On 7/16/06, Tamas Rudnai <tamas.rudnaiEraseME.....gmail.com> wrote: > > > > Updated in sourceforge, so now it handles those jump tables -- thanks > > Maarten for the ideas! Also now you can recompile the code using MPLAB. > I > > had no problem by doing it so with my test package -- got back almost > the > > same HEX file. But if you can't build the disassembled code or if the > HEX > > differs, please raise your hand :-) > > I've written a PIC disassembler (PICDIS at http://www.picemualtor.com), and would > like to try yours. > > However, I'm running a Win2K system. What would I have to install to try > it? > > Bill > > -- > Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org > -

Xiaofan Chen wrote: >> That's only one of many problems. I think it would be impossible to >> properly track indirect addressing references. Since often run time >> math is used to calculate the target address, you don't know what is >> ultimately being addressed. This means you have to keep all RAM at >> exactly the same addresses on the new machine, but of course that is >> either impossible or leads to other problems. > > C compile will be quite good at this even though some people may not > opt for C. I think you are missing the point that the OP is trying to convert just the raw binary from one PIC type to another. This therefore has nothing to do with whatever language was used to create the code in the first place. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

To answer to myself: the correct URL of William's site is: http://www.picemulator.com/ PS: I was too lazy to see the typo in the URL at the first glance :-) On 17/07/06, Tamas Rudnai <EraseMEtamas.rudnaigmail.com> wrote: {Quote hidden}> > I have written it in Perl, so it is platform independet (..or Perl > dependent :-), so as long as you have Perl 5.x installed should work fine. > Maybe later on will compile to Win32 exe from it as well. It is in Alpha > stage and works with 14bit PICs only at the moment. > > You can download it from > > http://sourceforge.net/projects/unpic > > However, I am having trouble to access your web site, could you check the > url please? > > Thanks, > Tamas > > > > On 17/07/06, William Couture <RemoveMEbcoutureEraseMEEraseMEgmail.com> wrote: > > > > On 7/16/06, Tamas Rudnai <RemoveMEtamas.rudnaispam_OUTKILLspamgmail.com> wrote: > > > > > > Updated in sourceforge, so now it handles those jump tables -- thanks > > > Maarten for the ideas! Also now you can recompile the code using > > MPLAB. I > > > had no problem by doing it so with my test package -- got back almost > > the > > > same HEX file. But if you can't build the disassembled code or if the > > HEX > > > differs, please raise your hand :-) > > > > I've written a PIC disassembler (PICDIS at http://www.picemualtor.com ), and > > would > > like to try yours. > > > > However, I'm running a Win2K system. What would I have to install to > > try it? > > > > Bill > > > > -- > > Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org > > --