Re: gpdasm 0.13.6 alpha question

On Thu, Mar 12, 2009 at 10:51 PM, Peter Keller <psilord@...> wrote:

> I suppose I'd be interested in writing codes for a regression test suite,
> mostly because for whatever reason I find that fun, it teaches me all
> of the wierd edge cases in the tools, and it always benefits a project.
> What does your current test framework look like?

That's a great place to start. We have some real issues with our testing
framework (which is just a few shell scripts), so do whatever you'd like to
the test system as long as we're still testing everything our current tests
do. Have a look at gputils/gpasm/testsuite/README, and there are also
testsuite directories in gputils/gplink and gputils/gputils (for gpdasm,
gpvo, etc.). I just wrote up some info on the wiki to get you started if
that's where you want to start (
http://gputils.wiki.sourceforge.net/RegressionTests).


> I'd also like to make the output of gpdasm(especially)/gpvo more human
> readable. For example, actually showing me the real configuration bits
> (instead of a 16-bit value) and what it means to a human when they are
> on or off, having the disassembler show an ascii dump of the EEPROM
> sections as a comment (so you could reassemble it without trouble),
> things like that.

You could take a look at FR #1897673 ("Disassemble configuration memory").
It seems pretty manageable.

Are the maintainers and developers opposed to more radical ideas...

Depends on the idea. I think we're fairly open to new approaches, but
backwards compatibility is pretty important to us. I'd say we have a lot of
leeway with any implementation details that aren't very visible to the
users.

> ...like using sqlite to store all of the data for all of the
> processors/eeproms,
> or having a centralized repository for prcessor data, and you can ask
> gputils tool to query it to get new processor defines and shove it into
> a per user cache which augments the database downloaded when you got the
> installation?

With this upcoming release, we've knocked out most of our processor
compatibility issues. We'll be able to stay in sync with MPLAB as far as
supported processors, so unless you're talking about a lot of customized
non-Microchip devices, that particular problem has been solved already.

My pet radical ideas for gputils are making banking/paging instructions
obsolete and adding a relocatable bit type. However, MPASM/MPLINK
compatibility is my top priority, so for any extensions we make to Microchip
assembly syntax, I'd really like to add an "output canonical assembly"
option to gpasm that would dump Microchip-compatible assembly. It's great to
have selling points over MPASM, but I don't want to lock people into using
gputils if possible.

I've written some compilers in my life too, maybe I could help with the
> lexer/parser situation gputils finds itself in.

We can collaborate closely on that if you'd like. I got started on it once
but never got back to a clean state. I think I still have a copy of some
half-finished changes if you'd like to wade through them, but it might be
best to start from scratch.

I was working on untangling a separate lexer/parser for the preprocessor,
because the way we try to expand macros and #defines in the same pass as the
assembler seems to be a big part of our problems.

Let me know if you need something from me to get going if/when you get time.
You can put nitty-gritty details on the wiki or email me directly if you'd
like.

Good luck.
David