Is this really true or is it just my P200..

I been using bitRAKE cleanbuffer code for the day i saw it. I always thought you have to give it the amount of bytes in that buffer in-order to clear it.

Come to just find out just minutes ago, as long as you use the number one and not zero it will clear the WHOLE buffer out no matter how many bytes is in
there.


xor eax,eax
mov edi, offset BUFFER
mov ecx, 1
rep stosb

No need to use ;;;;;;;

xor eax,eax
mov edi, offset BUFFER
mov ecx, 64 ;;;or whatever
rep stosb

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

One more but strange question.

Where of what do stosb or stosd do with those bytes. do it really clear them or do it reloctate them and put it somewhere else processer related.

I am just wondering about this now. stor could it mean STORE it somewhere else. Why not Erasb Just Erace it !!!

Thanks in advance
Posted on 2003-07-07 02:22:06 by cmax
I just SHUT DOWN and switched back over to my programming hard drive and my

xor eax,eax
mov edi, offset BUFFER
mov ecx, 1
rep stosb

Evidently did not work. All of the text was there but the first byte (sa it should be).

Trust me... I tested it 20 times or more before i post. It was so strange i had to.

Either i got a fauty hard drive which is true anyway...

(Segates I will NEVER BUY another one again ANYWAY)

OR stosb really do STORE those bytes elsewhere. They did pop up in the message box when they did not for the pass hour or two.

If so I will really be piss off at Intel or myself for not knowing what the proccesser really do with my data.

If this is true how do you REALLY clear a buffer. Not with MS API i am sure it is worse if all of this is true.


Only after shutdown it ALL came BACK.
Posted on 2003-07-07 03:15:03 by cmax
stosb =

mov ,al
inc edi

rep stosb =

@@:
mov ,al
inc edi
dec ecx
jnz @B
Posted on 2003-07-07 03:17:27 by roticv
So this mean i got fauty hardware . ..

Thanks

Segates hard drive (bad software drive it seems) have been giving me a lot of problems for nearly a year now. This false report here really took the cake...


"I Hate Segates"
Posted on 2003-07-07 03:28:54 by cmax
Nope....

xor eax,eax

mov edi, offset BUFFER
mov ecx, 1
rep stosb

Clears only 1 byte...

For a generic it should be


xor eax,eax
mov edi, offset buffer
mov ecx, SIZEOF buffer
shr ecx, 2
rep stosd

Just make sure that SIZEOF buffer is aligned to 4. If not remove the shift and replace the stosd with stosb
Posted on 2003-07-07 03:32:15 by roticv
Thanks again roticv,

I tried

@@:
mov ,al
inc edi
dec ecx
jnz @B

The message box said it was empty than down the line
i added other text to that buffer and the old test and the new text showed in the 2nd messagebox.


xor eax,eax
mov edi, offset BUFFER
mov ecx, 1
rep stosb

But this is again working perfectly as it use to. At lease i am getting closer to what make it tick. The other thing must have been a problem from elsewhere that make this code act like your example for the very first time.

It is more fun to learn what the code really do. And this is a trip... Why Why Why bitRAKE code works and your breakown of it all is missing something special but i can't see what it is...

Anyway the 2nd text to buffer and messagebox test show true results
Posted on 2003-07-07 04:19:46 by cmax
Let me explani stosb if you don't mind.

Stosx is the a string opcode (store string and the x being b/w/d depending on whether you want the processor to use byte or word or dword). stosb is thus store string byte. Firstly, edi is called the destination instruction so usually it is for the destination string. What stosb does is move (store) the value in accumulator to edi (Like my explanation just now). The partner opcode that is usually used with stosx would be lodsx or rather load string x.

rep is a prefix for repeat. For example for the following code:


@@:
stosb
dec ecx
jnz @B ;4 bytes

could be expressed with
rep stosb ; 2bytes


What I have just done just now is to attempt to you what stosb and rep stosb does.

For your code
xor eax,eax

mov edi, offset BUFFER
mov ecx, 1
rep stosb

What it does is to copy to the first byte/character 0 (Null). Thus the string could be considered null terminated, but the data in it is not cleared except for the first byte/character

PS: What is bitrake's code? :)
Posted on 2003-07-07 06:53:05 by roticv
There are two primary strategies for making text strings.

The first strategy, used by C (and the Windows API), is to use an end of string marker. This is the byte with a value of zero. DOS (and CP/M) had one system call that used '$' as an end of string marker. Another similar strategy, when using only a 7-bit ASCII character set, was to set bit 7 to 1 on the last character.

The second strategy, used by VB (and COM), is to have length data attached to the string. A string of type BSTR has the length prepended to the string data. You can also use a structure containing a length and a data pointer.

Another thing to remember is that there is no such thing as "erased" memory. Each memory location always has a value. With that in mind, if you think that "erase" means set all bits to 0, I have news for you -- an "erased" (E)EPROM may actually be set to all 1's.
Posted on 2003-07-07 16:59:02 by tenkey