News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

about seperate reg/variable to track file length

Started by Rainstorm, May 03, 2007, 09:56:32 AM

Previous topic - Next topic

Rainstorm

hi.

while checking for an end of file since its better to use the file length rather than a 0 terminator, is there a way around the need to use an extra reg/variable.
this becomes neccessary in the code not just where the file length is compared but almost all over where the file pointer (esi in this case), is used;....in order to keep track of the filel length

using a simple example..
using file length..

mov esi, offset filebuffer
@@:
    add esi, 1                          ; move data pointer forward 
    add ebx, 1                        ; keep count of file length

..........other code here

    cmp ebx, filelength          ; check for zero terminator
    jne @B


using zero terminator..
Quote@@:
    add esi, 1

    .......other code here

    cmp byte ptr [esi], 0          ; check for zero terminator
    jne @B

any shorter code, suggestions or solutions to this ?
besides an extra instruction everywhere, an extra register gets used too.

thanks.

zooba

Add the start of the buffer to the length and store it in a variable. While ESI < variable, keep going.

I don't think there's any way to do it without storing the length somewhere (calling the API each time is obviously worse).

Cheers,

Zooba :U

Tedd

I have a habit of doing..

    mov esi, offset filebuffer
    xor ebx,ebx
  @@:

    ;access bytes at [esi+ebx]
    ;...etc...
   
    add ebx, 1
    cmp ebx, filelength    ;check for EOF
    jb @B



Or you can do: file-end = esi+filelength (as zooba said), if you don't want to use ebx at all.
No snowflake in an avalanche feels responsible.

Rainstorm

tedd & zooba, thanks for the feed back!

zooba's method has the advantage that one register is freed up & tedd's method would be faster I suppose ??? - since it uses just registers.

Also, any idea whether the buffer allotted by commands like 'read_disk_file', is the exact size of the file,.. or is it larger or something like that ?

-

zooba

I doubt there's any difference in speed, both methods have a register-memory compare. A (very minor) optimisation is to keep the file length in a register and decrement it as you go. The 'dec' or 'sub' instruction will set the zero flag when you reach zero and there's no need for the comparison at all.

I've been known to use all of these different forms. I don't know that any has an advantage over the rest in all cases. AFAIK the one I posted uses the least registers though it does have the downside of trashing the main file pointer. The one Tedd posted doesn't change the value of ESI at all, so you can continue to use it as the 'start' of the file.

The best one depends on your personal preference and the context it is being used in. It doesn't hurt to know the options, but in terms of optimisation the complexity goes up from here.

No idea on the library functions, sorry. I don't use them

Cheers,

Zooba :U

Tedd

Speedwise, I don't think there's really much (if any) difference; nor should it really be much concern given the minor part it plays in the program as a whole. I generally do it that way to preserve the value of esi as it makes 'seeking' simpler and the file is often read into a block of memory pointed to by esi (and therefore freed by the same pointer.)

read_fisk_file (from the masm library) allocates filesize+32 bytes (for some reason) and then reads the file into that - which will give you at least 32 bytes slack to play with (maybe a few more, depending on the memory allocation method and how it rounds-up the value; short answer: you get the amount you ask for, maybe a bit more if you're lucky.)
No snowflake in an avalanche feels responsible.

sinsi

If you are using ReadFile to read a byte at a time, you can keep checking lpNumberOfBytesRead until it is 0.
Or if you are reading from a buffer, you can use lpNumberOfBytesRead, since it is already allocated for ReadFile.

  sub lpNumberOfBytesRead,1
  jz eof
  ...
Light travels faster than sound, that's why some people seem bright until you hear them.