Timothy Miller wrote:
On 7/9/06, Jared Putnam <[EMAIL PROTECTED]> wrote:
I'm confused about the mnemonics of the assembly. A typical statement
looks like
NOOP [-v,-h,-d] #640
Am I correct in concluding that -v and -h refer to the vblank and
hblank assertions? In the program Timothy posted, every instruction
has the -d modifier. Does this mean that some programs will never need
to assert the data line, or is this an oversight? Also, how is cursor
control reflected in the mnemonics?
Actually, the syntax was just something I made up on the spot and is
perhaps something we should change.
What I meant to express was that -v means that the vertical sync is
low, while +v means the signal is high. Sometimes, a given VESA mode
wants active low (high always except during the pulse), and sometimes
a mode wants active high (low always except during pulse).
My gut reaction would be to define it as:
NOOP [v=0,h=0,d=0] #640
NOOP [v=0,h=1,d=0] #640
etc
Our video circuitry doesn't care about the polarities of v and h.
They're just whatever we program into the code. So, if you want to
change from active high to active low, you actually have to reload the
whole program. :)
Hence the explicitly defining the state of V and H.
In fact, however, it would require virtually no extra logic to include
a polarity xor gate for each of these flags in a config register (for
an FPGA anyhow). Is there a way that having this configuration would
not be redundant? If we had some other logic that looked at the
syncs, then we may have to program THAT logic with appropriate
polarity info.
This does have it's benefits. It allows the video controller program to
be abstracted from some of the finer details of the video mode. You
would no longer have to worry about whether a mode uses ++sync, --sync,
etc. All the program has to worry about is when to activate the sync
signals. It also makes it easier to modify the sync modes from user
space. A single register sets the sync mode and changing that register
would immediately change the output sync. It allows us to do something
very similar to the ATI advanced monitor properties where you can change
the sync polarities on the fly. If we have to update the program to
change sync, then we will glitch the display because the program will reset.
Finally, is it really a good idea for the mnemonics to reflect hardware
details? I'm referring to the part in brackets here. All a programmer
cares about is whether the signals are asserted; he shouldn't have to
care whether they are active low or active high. I'm proposing
something like
NOOP [v,h] #640
Assuming we have a separate register to control sync polarity, then I
would agree. Otherwise the programmer is required to know the exact
polarity requirements for the controller program he is writing.
where only the asserted signals are listed between the brackets instead
of stating whether the lines are high or low. Timothy's program
already does this for returns.
Honestly, the reason I didn't do it the way you suggest is because I
wanted to make sure people understood what I was describing. I'd much
rather just include the flags (in arbitrary order) when the bits are
set.
As a suggestion, how about we name the flags this way:
h - hsync is high
v - vsync is high
d - data enable is high
x - reset cursor x
y - reset cursor y
r - return from subroutine
i - assert video interrupt
z - [yet-unassigned bit 24]
[If x is present without y, cursor y advances by 1 line.]
My next suggestion is to remove the commas, just stringing them
together in any order.
And then perhaps we can remove the brackets. If any flags are set,
they're separated from the mnemonic by a dot. So NOOP with +v and +h
looks like this:
NOOP.vh
Is that good, or would that confuse people, since it's the same syntax
that some assemblers use for operand size? Do we care, since almost
no one will ever see the assembly code or even use it indirectly (ie.
compiler goes directly to binary)?
I think we can retain # to indicate a count and an unadorned number is
an address (program or memory). Or perhaps we can put an address in
parentheses with the count being a prefix. So, for instance, if we
wanted to call address 200 a count of 40 times, it would look like
this:
CALL.rvh 40(200)
Or would that confuse people, making them think it's an offset?
Having done a fair amount of low level assembly, I can say I would find
it quite confusing. I like the brackets idea for the flags. Strikes me
as a good way to specify them. It also would allow the compiler to
easily identify the flags anywhere in the instruction. For the call
commands, I would format them something like:
CALL <address> <count> [flags]
CALL [flags] <address> <count>
After looking at the lines above, I would probably go for this as a
general format:
CMD OP1 OP2 [flags] for two operand instructions
CMD OP1 [flags] for one operand instructions
CMD [flags] for zero operand instructions
Though really, this is a kind of academic discussion. For as simple a
syntax as this will have, setting up a compiler that access a
configurable definition for line syntax would not be terribly hard.
Still, having a single syntax will make it much easier for people other
than the author to read and understand programs.
Patrick 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)
