does any one knows a way to generate a god checksum without a big code and that DWORD 256 dup (?) table?
here's one made by tE:
had comma's in uses ebx esi edi
;*-------------------------------------------*
; int CRC32(*buffer, sizeof(buffer));
; Calculates a 32 Bit Cyclic Redundancy Code
; over a buffer with length sizeof(buffer).
; Polynom: EDB88320h (Winzip)
; Doesn't need any table or precalculations.
; Speed: ~2.4 MB/s on a Intel PII 300
; (c) tE!
;*-------------------------------------------*
CRC32 proc uses ebx esi edi lpbuffer:DWORD, lsize:DWORD
mov esi, lpbuffer
mov ebx, lsize
xor ecx, ecx
lea eax, [ecx-1]
mov edi, 0EDB88320h
@@m1: xor edx, edx
mov dl, [esi]
xor dl, al
@@m2: shr edx, 1
jnc @@m3
xor edx, edi
@@m3: inc ecx
and cl, 7
jnz @@m2
shr eax, 8
xor eax, edx
inc esi
dec ebx
jg @@m1
not eax
RET
CRC32 endp
had comma's in uses ebx esi edi
Hmmm... Good savage. I think you have reapeared.
Keep on the good work!!
Keep on the good work!!
I have another similer alg, except it needs to precalculate CRC32 Table before use, but once this is done it will calculate a checksun at around two to three times as fast because of the reduced overhead.
I prefer the generate-table-once approach. 1kb of data isn't really
that much today, and since you can generate it runtime, it doesn't
add much to your executable size. Imho the table-less version is
only really useful if you work in very "extreme" conditions, like a
smartcard (I think those would be fun to mess with :D).
that much today, and since you can generate it runtime, it doesn't
add much to your executable size. Imho the table-less version is
only really useful if you work in very "extreme" conditions, like a
smartcard (I think those would be fun to mess with :D).
Sorry, the reason I didn't post the alg before was I couldn't find it, but another search has found it, so here it is:
;*-------------------------------------------*
; void InitCRC(void);
; Precomputes a 256*4 CRC array for use with
; Crc32()
;*-------------------------------------------*
InitCrc32Tbl PROC USES ESI EDI EBX
lea edi,crctab + (255*4)
xor edx,edx
dec dl
std
CalcTblValues:
mov eax,edx
mov ebx,0edb88320h ; winzip polynominal
push 8 ;mov ecx,8
pop ecx
ReflectBitsCompute_Loop:
shr eax,1
sbb esi,esi
and esi,ebx
xor eax,esi
dec ecx
jz ReflectBitsCompute_Loop
stosd
dec edx
jns CalcTblValues
cld
ret
InitCrc32Tbl ENDP
;*-------------------------------------------*
; int FastCRC(*buffer, sizeof(buffer);
; Calculates a 32 Bit Cyclic Redundancy Code
; over a buffer with length sizeof(buffer),
; using a precomputed CRC table. InitCRC()
; must be called *once* before.
; Speed: ~7 MB/s on a Intel PII 300
;*-------------------------------------------*
Crc32 PROC USES ESI EDI lpData:DWORD,bLen:DWORD
mov esi,lpData
lea edi,crctab
mov ecx,bLen
xor eax,eax
dec eax
@@:
xor edx,edx
mov dl,byte ptr [esi]
inc esi
xor dl,al
shr eax,8
xor eax,dword ptr [edi+(edx*4)]
dec ecx
jnz @B
not eax
ret
Crc32 ENDP
coder7345, I hope you don't mind me asking this stupit question on your post but what is a crc32 and what do it do for your app. I think i know that it check PE size for other apps, but the way it sound here it check your own PE inside your own app.
; input: EDX=data, ECX=size, EAX=crc
; output: EAX=crc, EDX+=ECX, ECX=BL=0
xcrc32: jecxz @@4
not eax
@@1: xor al,
inc edx
mov bl, 8
@@2: shr eax, 1
jnc @@3
xor eax, 0EDB88320h
@@3: dec bl
jnz @@2
loop @@1
not eax
@@4: ret
; output: EAX=crc, EDX+=ECX, ECX=BL=0
xcrc32: jecxz @@4
not eax
@@1: xor al,
inc edx
mov bl, 8
@@2: shr eax, 1
jnc @@3
xor eax, 0EDB88320h
@@3: dec bl
jnz @@2
loop @@1
not eax
@@4: ret
i tried the first and the last method and get different results ! :(
First Method
{
CRC_CALC proc uses ebx esi edi lpbuffer:DWORD, lsize:DWORD
mov esi,lpbuffer
mov ebx,lsize
xor ecx,ecx
lea eax,
mov edi,0EDB88320h
@@m1:
xor edx,edx
mov dl,
xor dl,al
@@m2:
shr edx,1
jnc @@m3
xor edx,edi
@@m3:
inc ecx
and cl,7
jnz @@m2
shr eax,8
xor eax,edx
inc esi
dec ebx
jg @@m1
not eax
ret
CRC_CALC endp
}
gives a CRC32 A9E9A64F for the string "!!!TEST!!!" (without quotes)
and the last method
{
CRC_CALC proc Text:DWORD, TextLen:DWORD
mov edx, Text
mov ecx, TextLen
xcrc32: jecxz @@4
not eax
@@1: xor al,
inc edx
mov bl,8
@@2: shr eax,1
jnc @@3
xor eax,0EDB88320h
@@3: dec bl
jnz @@2
loop @@1
not eax
@@4:ret
CRC_CALC endp
}
calculates BECB3686 for the same string !
which one is the right one ?
but anyway, good work guys ;)
First Method
{
CRC_CALC proc uses ebx esi edi lpbuffer:DWORD, lsize:DWORD
mov esi,lpbuffer
mov ebx,lsize
xor ecx,ecx
lea eax,
mov edi,0EDB88320h
@@m1:
xor edx,edx
mov dl,
xor dl,al
@@m2:
shr edx,1
jnc @@m3
xor edx,edi
@@m3:
inc ecx
and cl,7
jnz @@m2
shr eax,8
xor eax,edx
inc esi
dec ebx
jg @@m1
not eax
ret
CRC_CALC endp
}
gives a CRC32 A9E9A64F for the string "!!!TEST!!!" (without quotes)
and the last method
{
CRC_CALC proc Text:DWORD, TextLen:DWORD
mov edx, Text
mov ecx, TextLen
xcrc32: jecxz @@4
not eax
@@1: xor al,
inc edx
mov bl,8
@@2: shr eax,1
jnc @@3
xor eax,0EDB88320h
@@3: dec bl
jnz @@2
loop @@1
not eax
@@4:ret
CRC_CALC endp
}
calculates BECB3686 for the same string !
which one is the right one ?
but anyway, good work guys ;)
crc32(!!!TEST!!!) = A9E9A64F ;)
Hi All Coders,
This ZIP & ARJ 32-Bit CRC Calculation *.PAS source. Just new idea.
Have nice day, :)
This ZIP & ARJ 32-Bit CRC Calculation *.PAS source. Just new idea.
Have nice day, :)
This not in progress is mostly crc32 used in PNG's. What you're looking for will be found in Subs.asm. PNG.asm demostrated the usage.
, tola...
the entry ";input: EDX=data, ECX=size, EAX=crc" in the original routine dont match your procedure:
notice the EAX ;)
put after your "mov ecx, TextLen" a "SUB EAX,EAX", and the routine magically will start to work right ;)
ancev
the entry ";input: EDX=data, ECX=size, EAX=crc" in the original routine dont match your procedure:
CRC_CALC proc Text:DWORD, TextLen:DWORD
mov edx, Text
mov ecx, TextLen
notice the EAX ;)
put after your "mov ecx, TextLen" a "SUB EAX,EAX", and the routine magically will start to work right ;)
ancev
This post came at the right moment : I was thinking about working on an optimized crc-32 asm proc, many good ideas to start with here...
About the table, I agree with huh and f0dder...
1 kb is not much, especially if you allocate it with HeapAlloc and deallocate it once it is not used anymore...
About the table, I agree with huh and f0dder...
1 kb is not much, especially if you allocate it with HeapAlloc and deallocate it once it is not used anymore...
Ummmmm 1kb is nothing :)........... I hate to say it, maybe back in the day where 640k was all there was it might of been something to consider.
Also I dont think you will make much an improvment on the algorithm on my previous post.
Maybe using MMX your could make a CRC64 but the MD5 hashing routine is basicly a CRC128 already and seems to be almost the a new standed.
Also I dont think you will make much an improvment on the algorithm on my previous post.
Maybe using MMX your could make a CRC64 but the MD5 hashing routine is basicly a CRC128 already and seems to be almost the a new standed.
Also I dont think you will make much an improvment on the algorithm on my previous post.
Posted on 2002-02-14 10:33:20 by bitRAKE
I did say 'I didn't think much' :)
I didn't originally write that version but it seems to me of been taken apart enough for the writer to of not had the "xor edx,edx" outside the loop by design. I dont understand much about pentium optimization to say how moving the xor to outside the loop will affect the speed of the code either but its something to consider.
I didn't originally write that version but it seems to me of been taken apart enough for the writer to of not had the "xor edx,edx" outside the loop by design. I dont understand much about pentium optimization to say how moving the xor to outside the loop will affect the speed of the code either but its something to consider.
huh, that was just an obvious start. It is slow - I can see I'd have to do the work of optimizing it myself to show you what I mean. ;) The code doesn't look optimized at all!
May as well use that 1k to write more code that would beat the table based version. A version that processes a DWORD at a time would be nice.
May as well use that 1k to write more code that would beat the table based version. A version that processes a DWORD at a time would be nice.
Haha, this is turning into a big argument (one that I will probably lose :))
But.... there is no way to process a dword at a time except to read a dword from memory and unroll the loop, which may be a little faster if done properly.
Because of the nature of the Cyclic Redundancy Check, the next result is directly dependant on the previous result so it is impossible for the function to process more than a byte at a time without destroying the accuracy of the results.
-huh
But.... there is no way to process a dword at a time except to read a dword from memory and unroll the loop, which may be a little faster if done properly.
Because of the nature of the Cyclic Redundancy Check, the next result is directly dependant on the previous result so it is impossible for the function to process more than a byte at a time without destroying the accuracy of the results.
-huh
I've got my ass kicked before, but I still love a good fight. ;)