gnupic: gputils linker/assembler integration in higher level language
Subject:
re: Re: gputils linker/assembler integration in higher level language
From:
Scott Dattalo ####@####.####
Date:
22 Sep 2004 15:32:39 +0100
Message-Id: <Pine.LNX.4.60.0409220711430.3793@ruckus.brouhaha.com>
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.
>> These look like the HI-TECH directives.
>> Am I correct?
> Yes
>
>> We have planned to add directions for high level languages. The line
>> number directives were added, but nothing else. It hasn't been a
>> priority. I have looked at other directive sets, but was never
>> completely happy with any of them.
>
>> Are you suggesting this directive set because it is the best in your
>> opinion or because you are familiar with them?
> I have proposed it because this are just a starting point and the mnemonic
> is already in use, so it probably don't have naming problems.
> This matches the requirements.
I'm not completely sure what the end goal is here, but at times I've (not
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
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 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
about these. Finally, in your case, the linker would have to be modified
to accept these new changes. (And that's something I definitely know
little about.)
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.
Scott
