FASM закрытие-открытие файла

Писал о том, что использование памяти (lFile) по отношению к регистру не даст заметного выиграша, т.к. при первом же обращении lFile попадает в кэш, далее - либо будет находиться там же, т.к. текущий процесс не вытеснит, а если уж и вытеснит, то не текущий процесс; есть вероятность, конечно, что ассоциативности не хватит и с 4-й (8-й?) попытки вместо lFile будет в кэше лежать что-то другое. Вместе с тем, видимо, zet, используя esi в качестве счетчика, пытался оптимизировать по скорости (?).

 

Разве без ebx нельзя было ?

Код (Text):

1. include '%fasm%\win32ax.inc'
2. section '.code' executable
3. start:
4.         invoke CreateFile,fi,GENERIC_READ,NULL,NULL,\
5.                OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL
6.                mov [hFile],eax
7.  
8.         invoke GetFileSize,[hFile],NULL
9.                mov esi,eax
10.  
11.         invoke CreateFile,fo,GENERIC_WRITE,NULL,NULL,\
12.                CREATE_NEW,FILE_ATTRIBUTE_NORMAL,NULL
13.                mov [hFout],eax
14.  
15.         invoke SetFileAttributes,fi,FILE_ATTRIBUTE_NORMAL
16.         invoke SetFileAttributes,fo,FILE_ATTRIBUTE_NORMAL
17. @@:
18.         invoke ReadFile,[hFile],lpBuffer,1,szReadByte,NULL
19.                inc [lpBuffer]
20.  
21.         invoke WriteFile,[hFout],lpBuffer,1,szFileWritten,NULL
22.                dec esi
23.                jnz @r
24.  
25.         invoke CloseHandle,[hFile]
26.         invoke CloseHandle,[hFout]
27.  
28. exit:
29.         invoke ExitProcess,NULL
30.  
31. .end start
32.  
33. section '.data' readable
34.  
35.         fi db 'z1.txt',NULL
36.         fo db 'z2.txt',NULL
37.  
38. section '.data' readable writable
39.  
40.         hFile dd NULL
41.         szFile dd NULL
42.         lpBuffer dd NULL
43.         hFout dd NULL
44.         szFileWritten dd NULL
45.         szReadByte dd NULL