gnupic: Re: [gnupic] gpdasm 0.13.6 alpha question
Subject:
Re: [gnupic] gpdasm 0.13.6 alpha question
From:
Peter Keller ####@####.####
Date:
13 Mar 2009 02:52:33 -0000
Message-Id: <20090313025128.GA5669@cs.wisc.edu>
On Thu, Mar 12, 2009 at 07:31:04PM -0400, David Barnett wrote:
> If you're interested in problems like this then there's plenty to work on.
> Have a look at the wiki (feel free to add/edit), then look through the bugs
> and feature requests on SourceForge and see if anything catches your
> attention.
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?
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.
> I've been thinking long and hard about how to make gputils development less
> painful, so if you have any thoughts, put them on the wiki and/or email me.
> I'm not sure how much something like doxygen would help, but I've noticed in
> my experience that it's hard to mentally trace data through the program, and
> most of our remaining bugs seem to be caused by stubborn design limitations.
Are the maintainers and developers opposed to more radical ideas, 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? Then if there was a good enough specification language
for a processor (which doesn't appear to be *that* much information
from looking at the source), then people could hand write a processor
description for somthing new that shows up, submit it via a tool, just
like when you put in a CD into audacity or something, and see if there
is one already there? If you're the first, it gets labeled "experimental
definition" until it is vetted by a group or somthing and becomes cannon.
I've written some compilers in my life too, maybe I could help with the
lexer/parser situation gputils finds itself in.
Those are the types of things I'm thinking about...
Of course, all of this is dependant on the time I have available. :)
You could get a lot out of me in a month, or nothing for a year. It's
how it goes.
Thanks.
-pete
