flat assembler
Message board for the users of flat assembler.

Index > Windows > JCAlg1 x64 portation

Author
Thread Post new topic Reply to topic
marroh



Joined: 02 Apr 2013
Posts: 4
marroh
Hello to all,

I wonder why the JCAlg1 compression algorithm has no x64 version. Now I ask myself how hard it would be to port this source. What your assembler experts think?

A) Easy possible, just work time.
B) Not so easy to do, needs lots of skils.
C) Not possible, source work only on x86 cpu/can't be port to x64.

'm looking forward to your thoughts!

_________________
Greetings from Switzerland
Martin
Post 02 Apr 2013, 19:26
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:07; edited 1 time in total
Post 02 Apr 2013, 20:03
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3035
Location: vpcmipstrm
bitRAKE
Jeremy Collake has been coding in x86 for a long time, so would assume he just didn't work with amd64 at the time (1999). And/Or the goals of these algorithms didn't include amd64 support. He does sell amd64 software.

Of course, the more skill one has in data compression, and amd64 - the faster the conversion will be. The author has eased this somewhat by using a flexible coding sytle.

An easy start would be to convert the decompressors, test on some large data sets to verify conversion and inspire further goals. Most lines are in jcalg1_c.asm - looks like maybe 15% comments, 1500 lines. Many routines don't need any change. Wink Look for pointer/address usage. Might need to re-engineer some data structures.

(A) to (B), work backward from the small functions and verify with existing code base.

_________________
¯\(°_o)/¯ unlicense.org
Post 02 Apr 2013, 22:07
View user's profile Send private message Visit poster's website Reply with quote
marroh



Joined: 02 Apr 2013
Posts: 4
marroh
Thanks for your assessment. Is there by chance a list in which the CPU commands differences listed?
My assembler skills are unfortunately from Motorola 68000 time. Pointer / memory / structure handling I know still good. Use PureBasic which uses the Flat Assembler compiler, supports pointer, inline assembler...

Can I work with search and replace? Are x86 single instructions ported to x64 instructions sometimes multiple commands? A list of commands that I need to replace would be awesome of course.

And I agree, first handle the decompression... smaler code. Smile
Post 03 Apr 2013, 15:35
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3035
Location: vpcmipstrm
bitRAKE
Simple search and replace is not going to work. Some higher-level concepts need to be understood. First, there are differences in calling conventions used - assuming you are trying to produce a DLL for windows, or integrate into a Windows program.

There are nuances with the assemblers themselves which might also hinder successful translation. As an example:
Code:
cmp (_JCALG1_HEADER ptr [esi]).wSig,'CJ'    
MASM/TASM use the data in a string quite literally - ASCII code for 'C' * 256 + ASCII code for 'J'. FASM assumes the programmer is looking at/for a string and reverses the order - more visually appealing, imho.

Not to mention all the syntactical glue on the register. Jeremy's code is not consistent in his use here - having mystery numbers, extended dot notation, to the most complex used above - they are all the same:

[esi+0]
[esi]._JCALG1_HEADER.wSig
(_JCALG1_HEADER ptr [esi]).wSig

Compare with jcalg1_gusocb.asm:
Code:
JCALG1_GetUncompressedSizeOfCompressedBlock:
    xor eax,eax 
    jrcxz .BadPtr
    cmp word [rcx],'JC'
    jnz .BadPtr
    mov eax,[rcx+2]
.BadPtr:
    retn    
Above we have the first (and only) parameter in the RCX register instead of on the stack - no need to load value. Check for zero is a single instruction, and a test for compression signature. Notice how the registers within brackets have been promoted to the R* equivalents.
Post 05 Apr 2013, 17:51
View user's profile Send private message Visit poster's website Reply with quote
marroh



Joined: 02 Apr 2013
Posts: 4
marroh
Again thx for this information,

I see that the project is too difficult for me or requires too much training time.
Then I'll better use a different compression algorithm where a x64 version already exists.

Thanks again for the answers!
Post 05 Apr 2013, 20:21
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:06; edited 1 time in total
Post 06 Apr 2013, 16:33
View user's profile Send private message Reply with quote
marroh



Joined: 02 Apr 2013
Posts: 4
marroh
@HaHaAnonymous

If I were able to write me own algorithm in ASM I would have no problems in portation. Somehow logical - not!? Anyway, I have already found one.
Post 07 Apr 2013, 07:13
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.