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!

[ Post removed by author. ]

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. 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.

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.

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: 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: 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.

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 removed by author. ]

@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.