gnupic: Re: [gnupic] SPASM - a MPASM behave alike
Subject:
Re: [gnupic] SPASM - a MPASM behave alike
From:
Holger Rapp ####@####.####
Date:
6 Jun 2009 23:36:31 -0000
Message-Id: <844055D2-441D-4B2C-8A44-3291A24AE662@gmx.net>
Hello David,
> Haven't run the program itself, but from the description it sounds
> nice.
> I've been trying for a while to split out gpasm's preprocessor from
> the
> assembler (to support several of the features you've implemented),
> but I
> kept running into quirks of lex and yacc and getting stuck (e.g.
> there's
> some kind of magic to having multiple parsers in one project).
Oohh, it's the same with PLY (the python lex yacc lib I was using). It
is quite
troublesome to keep partial parsers around (like parsers for
expressions) so I
used a number of work arounds and hacks. Also the language of MPASM is
not very
regular; it is (nearly?) impossible to build a non ambiguos parser.
Nevertheless, glad you like my efforts. As I mentioned this can only
be seen as
a first step. The Assembler is not usable in the current state, but
all features
that are missing are non crucial (from an implementation perspective);
that is
all language features are implemented in the parser/lexer. Adding new
features
should be a quite enjoyable task right now. But features need to be
added to
code on 18* devices; I am quite confident that 16* devices work pretty
well
since virtually all test cases in the mchip test set are for those
devices.
The whole development happened test driven (which was easy with so
many tests).
I think this was the only reason that I managed to rework the parser/
lexer
several time when I learned from another MPASM language quirk/feature
(my
favorite by far are string literals: data "A" and data "A"*1 yield
different
byte code. pretty! ;) ). whoever picks up the development should be
willing to
also write test cases to keep the code healthy.
SPASM is also not running over the code twice as MPASM and gpasm do;
instead I
implemented backtracking for opcodes with undefined jump labels. I am
not sure
that this works in all cases, but if not - implementing going over the
code
twice is makable though not too easy I guess.
> A lot of people want the portability of pure C, so it's good that
> gputils
> exists. However, I think with MCU development you want to do
> everything you
> can on the host and get a small, optimized binary, and it seems like
> there's
> only so far you can go down that path implementing the assembler in
> C before
> it gets completely unmaintainable. I'm a Python guy myself, and I'm
> hoping
> that using Python will help lift some of those burdens that have held
> gputils back.
Is there a FOSS compiler solution for PICs with gplink as linker? I
wasn't aware
of this.
Cheers,
Holger
Am 06.06.2009 um 23:03 schrieb David Barnett:
> Holger,
>
>
>
>
> I'm excited to see some progress, at any rate. Thanks for pitching in!
>
> David
>
> On Sat, Jun 6, 2009 at 8:51 AM, Holger Rapp ####@####.####
> wrote:
>
>> Hi,
>>
>> I spent some time hacking on a PIC assembler implementation in pure
>> python.
>> You can find my efforts here:
>> https://code.launchpad.net/spasm
>>
>> I'd really like opinions from you guys. You did a terrific job with
>> gpasm
>> which helped me a lot. But I needed complete
>> macro support and #defines with arguments.
>>
>> Following are the feature list and how to install it as python
>> newbie.
>>
>> Feature list:
>> - Support for all chips that gpasm supports
>> - Support for #defines with arguments
>> - Full support of Macro definitions
>> - Full support of #v(val) substitutions
>>
>> No implemented:
>> - Support for EEPROM device programming. EEPROM8s might work,
>> EEPROMS16
>> quite
>> surely not
>> - Support for LIST file generation
>> - Support for relocatable output
>> - 18* support is very sparse, since there weren't many test cases
>> in the
>> testsuite of microchip. Things like
>> config A=1 are not supported but could easily be added.
>>
>> How to install:
>> - have python installed
>> - get the PLY library (under mac os/linux try $ ./easy_install ply),
>> python-ply package in debian/ubuntu; You need a recent version (>3.0)
>> - get bzr (versioning tool like svn; also try $ ./easy_install bzr),
>> package bzr in debian/ubuntu.
>> - get spasm: $ bzr get lp:spasm
>> - $ cd spasm
>> - $ python setup.py build (this might take a while)
>> - $./spasm.py <your assembler file>
>>
>>
>> I won't have time to continue development in the nearer future,
>> therefore I
>> release it as is into the public with the hope someone
>> will continue on it. I will obviously provide any help I can.
>>
>> Cheers,
>> Holger
>>
>>
>>
