gnupic: Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch)


Previous by date: 17 Jan 2006 19:34:10 +0000 Re: [gnupic] gplink throws away configuration (PIC18F458), Ian Jackson
Next by date: 17 Jan 2006 19:34:10 +0000 Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch), Ian Jackson
Previous in thread: 17 Jan 2006 19:34:10 +0000 Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch), Chen Xiao Fan
Next in thread: 17 Jan 2006 19:34:10 +0000 Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch), Ian Jackson

Subject: Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch)
From: Ian Jackson ####@####.####
Date: 17 Jan 2006 19:34:10 +0000
Message-Id: <17357.17956.226634.379950@davenant.relativity.greenend.org.uk>

Scott Dattalo writes ("Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch)"):
> On Fri, 2005-12-16 at 12:26 +0000, Ian Jackson wrote:
> > I've been using my patched 0.13.3-1 gputils for the past few months
> > and this has been working well.  I would like to suggest that my
> > patch, or something like it, be included in the next gputils release.
> 
> I like the idea of your patch. I too dislike having to doubly define
> everything. The only concern I have with your patch is that it makes gpasm
> incompatible with MPASM in some way. It doesn't appear that this is the
> case, but do you know for sure? Just to be clear, your patch allows one to
> write:
> 
>   EXTERN some_variable
>
> This statement may reside in an include file which can be included by all
> sources in the project; even the one that declares 'some_variable'.

That's right.  The `extern' has to come after the definition,
unfortunately, but that's not _too_ inconvenient to manage usually -
just have a single file which you include everywhere at the end, with
all the `extern's.

> Without your patch, gpasm will produce an error if the "EXTERN
> some_variable" and "GLOBAL some_variable" statements are seen while
> assembling a file.

Exactly.

> I suppose if you write code for gpasm making use of this feature and then
> attempt to assemble it with MPASM that it will fail? Is this true? Does it
> matter?

Yes, it will fail (as has been reported by others).  That means that
code using this feature is not compatible with MPASM.  I don't see why
that should be an impediment to adding this feature ?  Many things
that make programming easier will not necessarily be supported by
MPASM.

Ian.

Previous by date: 17 Jan 2006 19:34:10 +0000 Re: [gnupic] gplink throws away configuration (PIC18F458), Ian Jackson
Next by date: 17 Jan 2006 19:34:10 +0000 Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch), Ian Jackson
Previous in thread: 17 Jan 2006 19:34:10 +0000 Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch), Chen Xiao Fan
Next in thread: 17 Jan 2006 19:34:10 +0000 Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch), Ian Jackson


Powered by ezmlm-browse 0.20.