Tom,

Your point about the difference between "code conversion" and
"syntax modification" is an excellent one; as is your example...
the complexity required of a translator that could figure out
that a variable EQU'd to "2" really ought to be defined as a
bit address is nothing if not daunting, especially since there
would be no guarantee that the variable EQU'd to "2" would be
used only once, e.g.:

      Data    EQU     0x20
      UBits   EQU     0x21
      XBits   EQU     0x22
      BIT1    EQU     1
      BIT2    EQU     2
      Limit   EQU     B'01010101'
              BTFSS   UBits,BIT1
              BCF     XBits,BIT1
              BTFSC   UBits,BIT2
              BSF     XBits,BIT2
              BTFSS   STATUS,Z
              GOTO    Label1
              MOVLW   Limit
              SUBWF   Data,W
              BTFSC   STATUS,C
              GOTO    Label2

Yeah, that's some really nasty code, but you kinda gotta plan
for nasty code. :-(

Gpasm is the GPL'd assembler for MPASM code, done mostly by
James Bowman, and recently enhanced by Scott Dattalo and others
to, among other things, generate .cod output.

For more information, you probably want to browse around among
the following links:

http://reality.sgi.com/jamesb/gpasm/
http://interstice.com/~sdattalo/gnupic/gpsim.html
http://reality.sgi.com/jamesb/gnupic/

Scott's gpasm distribution is more recent than what
is on James' site; Scott has posted recently that
he has not been able to contact James for some time.

Scott of course is a frequent poster on this list and can
give much better information on these issues than can I.
But I'm guessing that a lot of the gnarly work you would
be facing in defining the front end MPASM lexer/parser
would be done for you; you could then focus on what to
generate on the output side. BTW, here is a caution Scott
sent me earlier:

   "gpasm actually handles macros separate from
   the lexer. There's a file called 'special.inc'
   that consists of the special/common macros like
   'skpc'. It would be trivial to add paralax
   mnemonics as a set of macros to gpasm. OTOH,
   the logic for parsing macros IS part of the
   lexer/parser."

His point about handling the paralax mnemonics is an
interesting one. Clearly, in a syntax conversion
approach as you suggest, you could pretty much pass
paralax mnemonics through untouched. Thus, if you
were to build a utility that could (a) convert
MPASM syntax to CVASM syntax, (b) unroll MPASM
macros and conditional, *and* (c) pass paralax
syntax and mnemonics through unmolested, then you
might well be able to make the first step of having
general-purpose macro capability in CVASM.

You should also be aware that all the gpasm stuff is
GPL'd, which would make it pretty close to impossible
to use the gpasm parser without your result being
GPL'd as well.

If you have been away from Unix for several years
you may want to grab the Cygnus Cygwin distribution...
see http://sourceware.cygnus.com/cygwin/ Beware, however,
because gpasm does not yet compile under Cygwin (at least,
I tried under NT and Cygwin b20 last week, and the compile
hung up on a call to getopt). That was something I was
thinking about working on; I may have some time this
week to fool with it. But still, cygwin would give you
a working, recent copy of yacc and lex (bison and flex,
actually) without having to get access to a Unix/Linux
machine.

--Bob

On Sat, May 15, 1999 at 04:36:31AM -0700, Tom Handley wrote:
>    Bob, when Jerry brought this up the first thing that came to mind is
> yacc/lex. I've been away from UNIX for several years. Can you give me a
> pointer to the generic C code? I'm sure I can track it down but if you have
> a preference (you mentioned GPASM), I'd appreciate it.
>
...
>
>    Even a `syntax modifier' would still be a challenge as you have to deal
> with MPASM's directives and conditionals as well as the macros, radix, etc.
> Normally, converting from MPASM to CVASM is fairly easy for most example
> code from Microchip and the public domain.
>
>    - Tom

--
============================================================
Bob Drzyzgula                             It's not a problem
bob@drzyzgula.org                until something bad happens
============================================================