gnupic: question - GPDASM and register names
Subject:
Re: question - GPDASM and register names
From:
Craig Franklin ####@####.####
Date:
3 Nov 2004 14:26:54 +0000
Message-Id: <418896B1.8070602@users.sourceforge.net>
####@####.#### wrote:
>For the compiler writer, this is a additional utility like objdump.
>
>
Looks like your archive is missing at least one file, picdis.h. I can't
compile it.
Did you create this tool? It looks the author combined the source of
three existing tools, picdis, djgpp source code, and a simple COFF
object file viewer.
>It's not intended to replace the gpvo. Currently, only the 16xxx range
>processors are supported. The tool disassembles a absolute or relative
>object file in a human readable form ( nolist option ).
>
>
I can't compile it, but judging by the source code I don't see many
capabilities beyond gpvo. What am I missing?
I am curious. What was your motivation for creating the new tool?
>The processor specific file include is supposed to be present in the current
>directory. If the automatic building of the include file name fails, the
>default p16f628.inc is used.
>You can use the command line option
>-p/usr/local/share/gputils/include/p16f877a.inc
>if you don't want copy the header file in the local directory.
>Because this tool is a hack, some errors on the
>variable name selection based on bank switching is present.
>Bit operators using relative variables is not supported in the current
>stage.
>Example:
> extern foo
> extern bar
> bsf foo,bar
>The result is:
> bsf foo,0
>or similar, i don't have tested it, but i can say, the decompiler don't
>decode bit
>variables, only byte variables.
>No excessive error checking are performed.
>The delay is normal and is a relict of the decompiler.
>All files are released using the gpl licence.
>
>
>
>>Jeff wrote:
>>
>>
>>
>>>On Wednesday 27 October 2004 07:58 pm, David McNab wrote:
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>Is there any way to persuade gpdasm to output register names instead of
>>>>numbers?
>>>>
>>>>Eg:
>>>> BSF STATUS,RP1
>>>>instead of:
>>>> BSF 0x3, 0x6
>>>>?
>>>>
>>>>gpdasm demands a '-p proctype' argument when it runs, so I thought it
>>>>would exploit processor-specific knowledge to look up the names for
>>>>registers and bits
>>>>
>>>>
>>>>
>>>>
>>>I'm privately working on modifications to gpdasm to output
>>>
>>>
>>assembler-ready
>>
>>
>>>code.
>>>
>>>
>>>
>>Human readable would probably be more accurate, because gpdasm's output
>>can be assembled now.
>>
>>
>>
>>>What you suggest is similar to what I do in my 8052 disassembler, so it
>>>should be doable for gpdasm (although more complex that what's required
>>>
>>>
>>for
>>
>>
>>>the 8052). I'll add it to my TODO list ;-)
>>>
>>>
>>>
>>>
>>>
>>Good.
>>
>>Before you start on this change, lets talk. I want to make sure all the
>>tools (gplink, gpvo, ...) can take advantage of your changes.
>>
>>I am especially interested in gplink's list file output. SDCC and gpal
>>would both benefit from this change. It would make it easier to see
>>what code the compilers generated. I am starting to change my mind and
>>think this is a priority for me. When do think you might start this task?
>>
>>We should probably consider using the disassembler in the COD file
>>viewer too (gpvc). Probably would be simple to do. I will add it to
>>gputils TODO list.
>>
>>
>>
>>>Jeff
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ####@####.####
>>>For additional commands, e-mail: ####@####.####
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ####@####.####
>>For additional commands, e-mail: ####@####.####
>>
>>
>>
>
>
>
