gnupic: gputils extension


Previous by date: 23 Sep 2004 17:27:27 +0100 Re: Proposal for gpdasm feature, Jeff
Next by date: 23 Sep 2004 17:27:27 +0100 Re: Proposal for gpdasm feature, William Couture
Previous in thread:
Next in thread: 23 Sep 2004 17:27:27 +0100 Re: gputils extension, Craig Franklin

Subject: gputils extension
From: ####@####.####
Date: 23 Sep 2004 17:27:27 +0100
Message-Id: <26484.1095956820@www33.gmx.net>

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
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.
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 i don't have the time to test it
extensivly against other software.
I have implemented solution 1 and i can offer to code solution 2.
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?




-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++


Previous by date: 23 Sep 2004 17:27:27 +0100 Re: Proposal for gpdasm feature, Jeff
Next by date: 23 Sep 2004 17:27:27 +0100 Re: Proposal for gpdasm feature, William Couture
Previous in thread:
Next in thread: 23 Sep 2004 17:27:27 +0100 Re: gputils extension, Craig Franklin


Powered by ezmlm-browse 0.20.