gnupic: gputils linker/assembler integration in higher level language
Subject:
Re: gputils linker/assembler integration in higher level language
From:
Craig Franklin ####@####.####
Date:
24 Sep 2004 06:51:40 +0100
Message-Id: <41536F91.5050104@users.sourceforge.net>
####@####.#### 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.
>
>
>
>>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.
>
>
That is a good reason.
>It's possible to define a interface from the asm to the obj files, that
>contains linker informations.
>This can be
>#pragma link ...
>or
> opt link ...
>or
> list l="xxxx nn"
>or .link or whatever.
>All the proposed opcode can be a macro of the new linker directive.
>
>
>
I was considering a more "as" like interface. Mainly because the
directives were created with COFF in mind (.def, .dim, .endef, ...)
It would be general purpose. The assembler wouldn't be aware of what
some of the data does, only where it goes. Maybe the a debug definition
file could be included during assembly. Common macros would define what
goes between the .def and .endef. That way gpsim could change or add
features without requiring a new version of gputils.
>I need a hint from you, how this should be implemented.
>ie: what asm opcode i can/should choose in order to generate a
>comment in the obj file, that are prepend to the linker lkr file before
>parsing the lkr specifications.
>
>
>
If we follow the "as" method .ident. It is a little old fashion, but
that is its purpose.
>
>
>
>
