gnupic: gputils linker/assembler integration in higher level language
Subject:
re: Re: gputils linker/assembler integration in higher level language
From:
####@####.####
Date:
22 Sep 2004 17:37:49 +0100
Message-Id: <17343.1095871041@www55.gmx.net>
> On Wed, 22 Sep 2004 ####@####.#### wrote:
>
> >> Do you also post to this list as "pico"? I don't want to get confused
> >> about who I am talking to.
> > No, pico is away (sicc), i using his outlook account and finish some
> > projects.
>
> If you're not pico, do you also post under the alias Charles? I think pico
> got offended when I asked him for his real name. Oh well.
I don't think, but i cannot be sure.
>
> I'm not completely sure what the end goal is here, but at times I've (not
Every optimizing higher level compiler need to optimize the temporary
variables in order to reuse the space for not overlapping calls.
On a register based MCU, this is more critical.
There exists two choices. Let the compiler produce a optimized hex file
without or generating a .obj file with enought informations to the linker.
In the second case, the linker can optimize the variable with the
possibility to use external library's.
> too seriously) thought about extending gpasm with custom 'mnemonics' or
> more properly, custom directives. I think your suggestion of using the
> '#pragram' qualifier to demarcate gpasm specific stuff versus third party
> stuff is a good one. In my case, I'd like to instrument the source
> assembly code with simulator directives. For example, the most powerful
> one would be an assert directive. Imagine being able to write code like:
>
>
> #define CURRENT_BANK (STATUS & ( (1<<RP0)| (1<<RP1)))
>
> ...
>
> ;; Some where along the line, bank 1 has been selected. So there's
> ;; no need to re-select it, but you want to make sure that you're
> ;; assumption is true - just in case you change the code leading
> ;; up to here gets changed in the future.
>
> movlw PORTA_DIRECTION_BITS
>
> #assert CURRENT_BANK == (1<<RP0)
> movwf TRISA ^ 0x80
>
> Now, as far as implementation details, there are several hoops through
> which you have to jump. The first is gpasm's parser/lexer. This one is
simple, because for custom mnemonics, the command table can be used.
using mnemonics like FNCALL , no changes to the lex/yacc is necessary.
For the pragma syntax, changes in lex/yacc is necessary.
> straight forward once the grammer has been defined. The next one is how
> the information is to be encoded into the output files. I think Craig may
> more to offer. I know for .COD files that there is a debugger specific
> section.
I'm intend coff (obj) files. Linking infos inside coff files is very
usual.
The cod file is a already linked or prelinked file with a map file inside.
Inside the cod file, there exist a link table with source file/line infos,
source lines itself, and a special section for the source level simulator
/ debugger containing break points preselect, print or log statements,
asserts and so on. No room for the link specific infos, but why, the linking
process must be passed before generating ony .cod file.
> I don't know if there's a generic 'external tool' section. But
> the .coff files would be more appropriate I'd imagine - and I know nothing
>
> If you guys decide to move forward something along these lines, then it'd
> be really nice if the interface is flexible enough to support both the
> linker and the simulator.
What you want ?
--
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
