gnupic: gputils extension
Subject:
Re: gputils extension
From:
Craig Franklin ####@####.####
Date:
24 Sep 2004 07:12:17 +0100
Message-Id: <41537468.2070709@users.sourceforge.net>
####@####.#### wrote:
>I have implemented this pragmas to gputils
>#pragma assert(expr)
>#pragma debug c,(string)
>#pragma emulator(string)
>#pragma log("string",args)
>#pragma printf("string",args)
>#pragma ident(string)
>#pragma clock(start,id)
>#pragma clock(stop,id)
>#pragma clock(reset,id)
>#pragma clock(print,id)
>#pragma function(enter,id)
>#pragma function(exit,id)
>#pragma function(marker,id)
>#pragma option(...)
>#pragma source(...)
>#pragma ident
>#pragma linker ...
>
>This can be made in two solutions:
>1)
>.cod file cannot be produced by the assembler anymore.
>The assembler can produce only .obj files
>
>
Many people use gpasm in absolute mode. So this would be a step back.
>The obj files have a propietary format (similar to the cod files).
>The gpvc is modified in order to be a obj2hex for executable obj
>files.
>
>
Why change formats? Did you have a problem with COFF?
>A generic utility convert between different file formats
>(hex/cod/mcoff/...) including faking local symbols (mplab debugging).
>The gplink executable is updated in order to handle the new obj format.
>A frontend drives the single commands, similar to the gcc frontend.
>
>2)
>The alternative is generating a separate .sdb file.
>This file can be merged with the cod file in order to update the debugging
>infos.
>
>3)
>rewrite the cod/coff/linker interfaces for .cod .mcoff files.
>The hard part is the conversion for debug infos between object/lib files
>and cod files. The interface to cod files and coff files must be upgraded
>and some currently missing thing must be added in order to allow some
>interworking.
>---------------------------
>I'm not interrested in making solution 3, because i don't have a official
>reference of the mcoff format and
>
There is a COFF reference on the gputils website. Some pretty good
documentation online. I bought a book, Understanding and Using COFF by
Gircys.
>i don't have the time to test it
>extensivly against other software.
>
>
I would think completely rewriting the relocatable sections of gputils
would take more time.
>I have implemented solution 1 and i can offer to code solution 2.
>
>
Wow. You have completed all the work for #1. I'm impressed.
>The BCDEBUG syntax is currently not implemented in gpsim. but i'm
>sure that this can be made quickly.
>The reason for choosing a solution of type 1 is basically to implement
>the same as hitech or bytecraft have made with his compilers/assemblers
>allowing agressive compiler optimisation after the final linking stage.
>
>What type of modification should be submitted into the official gputils
>release?
>
>
>
>
4) (like 3 I think)
Use the existing features in COFF to pass data from the assembler to the
linker and simulator. Adding the data to the COFF files is trivial. If
we do it right, no changes will be required to gpvo, gplink, or gplib to
keep them working. Of course when optimization is added gplink will
need work. Need to add COFF file support to gpsim.
This is a priority for me. I am willing to spend some time on it. I
will also look at Scott's pcode optimizer. We have talked about using
it in the linker. Need to make sure we can support its input needs
within COFF.
>
>
>
