gnupic: Re: [gnupic] gputils development
Subject:
Re: [gnupic] gputils development
From:
David ####@####.####
Date:
26 May 2007 00:17:22 +0100
Message-Id: <20070525181241.6cda49de@DEEPTHOUGHT.BARNET.net>
On Fri, 25 May 2007 14:19:05 -0700
Scott Dattalo ####@####.#### wrote:
> David Barnett wrote:
> > ...
>
> I don't think the pcode-based architecture eliminates the need for
> two passes. There are still things like forward references that have
> to be known before the pcode can operate. Now it could be that the
> second pass is completely different.
Yes, that's exactly what I meant. If we add any optimization, there
will probably be *more* than 2 passes over the data, but each will be
completely distinct. The reason the two-pass property is so central to
gpasm now is it parses the same input twice and calls several functions
twice. If we translate to pcode, we won't call many major functions
twice, and I think that will have a big impact on the design.
> ...
>
> Speaking of expressions, a common way I emulate structures in gpasm
> is by defining EQU's that index into the structure.
> ...
> In other words, parenthesis are required around the expressions that
> are added to memory addresses. Weird! gpasm doesn't care about
> parenthesis here.
I assume it gives you a "label too complex" error? That's one of the
cases where MPASM shows all the intelligence of a brick =). I know I've
complained about that on their forums before.
> So, the only reason I bring this up is that the behavior of the two
> assemblers depends on the parsing. I don't think gpasm should imitate
> MPASM's idiosyncrasies!
Definitely not in general. I'm pretty sure I've mentioned to you before
how much of a cop-out I think their 8-pass limit for macro
substitutions is. We could have a compatibility check flag that would
throw warnings on things that MPLAB would choke on where there's a
difference. Anyway, I think we're of the same mind as far as
compatibility: priorities are functionality, then compatibility, and
discuss first if there's any question.
However, with those differences I mentioned, I think MPASM is
significantly more powerful, and I can't see any benefit in the gpasm
way, even if well-written asm code maybe shouldn't take advantage of
them. I'd be glad to have a second opinion, but I'm pretty confident
that a few people will be glad to see those two changes made and nobody
else will notice.
David Barnett
