Access LOCAL ByteArray with EDI

[jj2007]

Results on an AMD-

85      cycles for call ClearLocals, ALL regs preserved
72      cycles for JimG

:U

Note: stosd relies upon direction flag being set normally, otherwise a fatal error occurs.  Perhaps not the best design.

I wouldn't worry about that one, people who set the direction flag know that they must reset it immediately after. Same for pushfd/popfd: You rarely would test flags that were set before the call. But normal regs should imho be preserved. Many people pass parameters in registers...

[AgentSmithers]

Ha Alwsome! I wanted to find a way to messure Cycles =D, How do you guys do that?

[hutch--]

There is something wrong with the base assumption level in addressing the original question. If it is a BYTE array for string data, then almost exclusively the string data will have a terminating zero so all you need to do is write zero at the first byte. Something like,

Code Select Expand


lea eax, btArray
mov [eax], 0     ; dword write


If it is a fixed length buffer that has NON ZERO TERMINATED data written to it then the buffer length is known by the programmer and a required write length can be worked out and overwritten with a dedicated routine.

If the buffer is small < 512 bytes or so, write a simple incremented pointer zero write for it, preferrably as DWORD writes, once it gets much bigger us REP MOVSD /REP MOVSB and in the very rare circumstances where real speed matters there is an MMX byte fill method that is faster still.

This stuff has been bashed to death in the Lab so it may be worth looking for it if speed matters.

[Jimg]

Note: stosd relies upon direction flag being set normally, otherwise a fatal error occurs.  Perhaps not the best design.

I wouldn't worry about that one, people who set the direction flag know that they must reset it immediately after. Same for pushfd/popfd: You rarely would test flags that were set before the call. But normal regs should imho be preserved. Many people pass parameters in registers...

As a general purpose prologue replacement, I try not to make any assumptions.  In fact, I have code that sets the direction flag before calling a sorting proc that can work either direction.
As for saving the flags, that too can be a problem for procs that test the flags they receive, so I changed the prologue to use lea rather than add, so the flags are preserved.

[dedndave]

this brings to mind an interesting question (for a n00b32, at least)
back in the day, we used LAHF/SAHF if it was practical, as it was a bit faster than PUSHF/POPF
i see that a few of the "newer" processors do not support LAHF/SAHF
are there 32-bit versions of the instructions?
or - do we just not use them anymore because a few processors didn't support them

[Damos]

i'm suprised to here that lahf & sahf aren't supported by some proccesors, especially as I use sahf a lot when using the FPU. Are you sure your correct with this. ho, hi by the way I not new to this forum, I monitor reguarly, but rarely talk. :green2

[dedndave]

from what i can gather by googling, some early p4's with em64t do not support it
and, some amd cpus do not support it in 64-bit mode
i was looking for a list of processors
as always, nothing is clear-cut
i have to route through a bunch of sites to find the info i want
it makes no sense - the instructions are simple enough

[Damos]

E^cube wrote:

lea edi,buf
of mov edi,offset buf should work, they're pretty much the same, I use them interchangably 32bit

but, you cannot use offset with local variables because the address depends upon the value of ebp which is only nown at runtime.
mov edi,[ebp+4] is valid
mov edi,ebp+4 is not
which is essencially what you are trying to do with mov edi,offset buf
offset can only be used to generate a value at compile time.

[Damos]

debndave:
no it doesn't make sense, a lot of material teaching assembly programming shows a sahf after a fnstsw ax it's as though it is the standard way to do this ( though not the only way, or the optimal), also, i'm sure i've seen sahf used in the disassembly of c code from a current c compiler.  :toothy

[dedndave]

some early p4's with em64t do not support it

perhaps this applies to 64-bit mode only, as well
hard to find precise details, but if you google something like "sahf/lahf not supported", you will see what i mean
in fact, there is a bit in cpuid that tells whether the cpu supports them (amd)

[Damos]

it seems intel have seen the error of there ways:

Intel has always admitted EM64T isn't 100 per cent compatible with AMD64, but it has maintained that the incompatibility is negligible. It has presumably decided now that sufficient quantities of software out there use LAHF and SAHF, so it needs to take them on board.

This highlights another reason why 'they' don't like us to use assembly, because it makes it hard work for them to keep up with compatibility issues. So today m**rosoft stop supporting masm, tomorrow processor manufacturers use whatever opcodes they desire. Am I being paranoid or do 'they' really not want us to program in assembly anymore!

[dedndave]

as for em64t support, it appears that early norwoods and prescotts (prior to revision F) are affected
it applies only to 64-bit mode only for those processors
if you code in 32-bit, sahf/lahf seem to be supported no matter which cpu you have (whew)
why anyone would leave them out ??? - what a headache for 64-bit code - i think someone gets a dunce cap for that one