Timothy Miller wrote:
On 7/9/06, Patrick McNamara <[EMAIL PROTECTED]> wrote:
So I sat down this afternoon and flushed this out a bit. Here is
Timothy's original program (bugs and all, plus my new ones :) ) in the
new instruction syntax. This assumes a sync polarity register. Flags
are asserted if specified.
One of the reasons I designed this controller is to make the hardware
simpler. So having this config register seems to run counter to that.
Similarly, with Jared's work-around for the lack of a double-return,
I'm inclined to remove that logic too. I'm also thinking about
removing the initial starting address register (and hardcoding to
zero). We should also look for other ways to shrink the design.
The hardware should be just bare minimum for us to do what we need.
Convenience to the assembly programmer is irrelevant.
I think what we should have is some assembler metadata. In the
assembly, we can indicate the polarity of assertion, and the assember
does the inversion as necessary.
That should be quite doable. Something like
.polarity v=+, h=-, d=+ ...
For readability sake, I would allow for multiple polarity macros. In
the case of duplicates, the last one take precedence with a warning.
For disassembly, we can store some
metadata past the end of the last instruction of the vertical program
(inserted after the first instruction that is a JUMP or has the ret
flag set and before the first subroutine so the disassembler can look
for it). This data will indicate the assembler source metadata so
that on disassembly, the polarities will be right. (Or, you can
detect the polarities by scanning the program and determining which
levels are most common, which is what I did in this one video chip
that had to automatically detect polarity with no configuration).
In the vein of the KISS principle, I would let the user specify polarity
on the disassembler command line and assume all positive if the argument
is missing. Trying to put it in the binary leads to all sorts of
problems trying to figure out where it is and if we let the disassembler
guess, we have to allow the user to override those guesses anyway as it
will invariably get it wrong at times.
Patric M
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
