gnupic: Re: [gnupic] local labels
Subject:
Re: [gnupic] local labels
From:
####@####.####
Date:
16 May 2008 17:49:40 -0000
Message-Id: <051620081749.6489.482DC930000215FF000019592206998499CEC9CA9B020E04040E0909@comcast.net>
David,
1. We already have local labels in the macros
2. If you don't have to use them
3. Every assembler in the GNU suite supports some form of local labels.
I would much perfer GNU compatability over MicroChip.
4. As for not being ready yet, I'm supplying the code.
Perhaps someone at MicroChip reads this list and think it would be a nice featue.
-------------- Original message ----------------------
From: David ####@####.####
> On Fri, 16 May 2008 08:46:49 -0400
> "George M. Gallant" ####@####.#### wrote:
>
> > To me, local symbols are a must for large projects written in
> > assembler.
> > ...
> > The downside is that the code is not usable by MPASM. As I am Linux
> > based and of the attitude that tools should not be limited to the
> > popular offering,
> > this is not a problem for me.
>
> For me it's a question of priorities. There are many, many rough edges
> on gputils that aren't problems in MPASM, etc. I see it as a big jump
> breaking compatibility with MPASM, and having a "preprocessor mode" as
> Peter mentioned would be a must for me before I would go for it. In
> fact, I would really like to have an "output canonical assembly" option
> on gpasm, because there are several features I would like to add that
> would break compatibility.
>
> I hate to be hard-nosed about it, but I really, really don't want to
> make it hard for everyone to create compatible code in the process of
> adding features. To me, it's a huge problem having code that can only
> be built with one tool. But there are several other options for you:
> * keep a patch over the official gputils to allow local labels
> * use m4 or some other macro processor on top of gputils
> * help create a "preprocessor/canonical output" mode for the
> official gpasm
>
> Please understand that I'm not against local labels, we're just not
> quite ready yet.
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
