From: marcov@stack.nl
On 2006-03-20, Jim Leonard wrote:
> Marco van de Voort wrote:
>> Always try to write something in pascal notation for your assembler. Then
>> you'll se that what you did is roughly equal to precalc[x+y] not
>> precalc[x][y]
>>
>> Try something that looks more like precalc[x*maxy+y]
>
> Yeah, I figured this out after I sent the message... Unfortunately the
> whole purpose of the precalc table is to eliminate MULs :-) so I'll
> have to figure something out.
I can't help that you didn't eliminate the muls :-)
(muls are btw not as slow as they used to be Be sure to verify if it
actually matters)
Note that it might hurt if you do 32-bits mul's in BP though. Some inline
32-bit code might help then in that case. Another classic solution is to
make maxy a 2-power so you can use shifts (see above expression).
> I'm afraid I don't follow you regarding "pascal notation for your
> assembler" -- I'm using in-line assembler with TP7.
All compiler symbols have a position in memory. Usually at a fixed distance
from some other symbol. I meant noting down the expression you are
calculating in TP just like that before you start coding assembler.
If you do some research (see Femme's code) you'll see that a
multidimensional array typically stores a series of uni dimensional after
eachother. Tha iss what I meant to express by precalc[x*maxy+y]; the x'ed
nested array is at x*maxy*sizeof(word) from the start of the precalc symbol.
> Are you saying
> it's possible to do something like "mov ax,[bx][si]" and the compiled
> will "figure it out"?
No. For small numbers (2,3,5,8 and maybe a few more), you can use 32-bit
lea, but that is about it.
What are you doing that is so speed starved, and should you be doing in in
TP then? :-)
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
