On 2008-10-03, Mark Marshall wrote:
> First a bug report ;-)
Thanks :-) And it's great you figured out the assembler.
> The assembler doesn't support '%' so It's hard to
> load 32-bit constants. Or am I missing something? I came up with this,
> but it also relies on me knowing that the low half is greater than 32767.
>
> ; load r6 with 123000000
> move ((123000000)/65536)+1, r6
> shiftu r6, 16, r6
> add r6, 54464-65536, r6 ; ((123000000)%65536)
>
> ; (We cant use 'or' because the constant is sign extended)
I've added a binary % operator (modulus) as well as 3 unary integer
functions: abs, cst_high and cst_low. The latter two are meant to be
used as
let c = 123000000
move cst_high c, r6
shiftu r6, 16, r6
xor r6, cst_low c, r6
Note that it assumes "xor" rather than "add", simply because it's a
cheaper operation in hardware. (I think it makes no different currently
since the add-logic triggers regardless, but one might imagine some HQ
implementation where xor uses less power than add.)
If there is many big constants involved, we should put them in the
memory BRAM instead. I'm just not quite sure how we will initialise it
yet.
It's easy to add more integer functions if needed.
> I think, from my reading of the other code mainly, that there is a delay
> when we read from an external port? Is there also a delay when we read
> from local memory?
That is correct, there is a one instruction delay for both port and
memory reads.
> For instance, if we assume that G_VID_SCREEN_WIDTH is local memory, I think
> that this will fail because r0 does not have the value read from memory
> until after the add.
>
> move [G_VID_SCREEN_WIDTH], r0
> add q0, r0, q0
>
> So this could be re-written:
>
> move [G_VID_SCREEN_WIDTH], r0
> noop
> add q0, r0, q0
>
> Is this correct?
Exactly.
One thing which I haven't documented in the manual yet is that if you
start a label with and underscore the assembler will prefix an optional
name specified after "frame". So, given
frame foo
...
_loop:
...
jump _loop
endframe
the actual label defined and used is "foo_label". That makes it easier
to deal with local labels.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
