gnupic: Re: [gnupic] gpsim --"invalid file register" error


Previous by date: 6 Feb 2007 19:49:23 +0000 Re: [gnupic] in-circuit debugger, Robert Pearce
Next by date: 6 Feb 2007 19:49:23 +0000 gpvc -I argument, Don Wooton
Previous in thread: 6 Feb 2007 19:49:23 +0000 Re: [gnupic] gpsim --"invalid file register" error, Robert Pearce
Next in thread:

Subject: Re: [gnupic] gpsim --"invalid file register" error
From: Ralph Corderoy ####@####.####
Date: 6 Feb 2007 19:49:23 +0000
Message-Id: <20070206194828.9A5AB1492E2@blake.inputplus.co.uk>

Hi David,

> As I see it, there are a few options.  I believe it would be trivial
> to write a run-once script in Python or what-have-you to prepend such
> a bank-checking assertion to every register access.

That appeals to me too, but I'm used to file inclusion and macros being
handled by a macro processor, e.g. m4, which spits out assembler with
all files included, conditional expressions evaluated, and macros
expanded.  This could then be the subject of the Python .assert inserter
before being passed to the assembler.  I think gpasm may not work to
this model, instead performing file inclusion and macro expansion
internally in addition to the assembly.  Trying to preprocess the source
to insert .asserts in the presence of macros would be prone to failure.

> That option would be very unobtrusive for other users since they
> wouldn't even have to know about it, and you could also make it smart
> enough to deal with the exception cases (like unbanked RAM).  You
> could add it into your toolchain for building and keep an unchanged
> and mangled version separate for readability.  You could also include
> some kind of explicit assertion to the script to disable checking for
> certain symbols or addresses and supply the script with the unbanked
> addresses, etc.  Lots of ways to do this sort of thing.

Yes.  And if I'm right about how gpasm works, i.e. it's difficult to get
an "expanded" listing from it such that it can be fed back into gpasm
after .assert insertion, then it is still possible to do what you
suggest if gpasm is used as a "dumb" assembler in the traditional Unix
vein, and something else is used for the macros, include, if-else, etc.,
and .assert insertion beforehand.

I guess a side effect of the DOS assembler model of it doing everything
is that whenever you think of something extra it has to be done by that
one program whereas the Unix model is "do one thing and do it well" with
a lingua franca of text files.

Cheers,


Ralph.



Previous by date: 6 Feb 2007 19:49:23 +0000 Re: [gnupic] in-circuit debugger, Robert Pearce
Next by date: 6 Feb 2007 19:49:23 +0000 gpvc -I argument, Don Wooton
Previous in thread: 6 Feb 2007 19:49:23 +0000 Re: [gnupic] gpsim --"invalid file register" error, Robert Pearce
Next in thread:


Powered by ezmlm-browse 0.20.