Activity for Pete
-
Pete modified a wiki page
Home
-
This was my bad. As I mentioned, I am unfamiliar with Debian, so took the latest install package available from privoxy downloads. When I use Software center, or even execute your dpkg command, Privoxy does not show anywhere. apt list does show it. Funny that since using *nix since 1992, this is my first foray into a more constricted "we will do everything for you" environment. Sorry for the braindead question! Much to learn...still! ;-)
-
Debian 12 installation of .DEB file fails.
-
Home
-
About
-
About
-
Home
-
I've been tracking the lzma SDK and with the release of 21.06 have integrated it into lrzip-next. lrzip-next is the next generation of Con Kolivas' lrzip application. It includes new and enhanced features including very large block sizes, reduced dictionary size set (akin to lzma2), redesigned encryption hashing, assembler integration, adds the BCJ and Delta filtering from the SDK, updated ZPAQ SDK and much more. See lrzip-next wiki and lrzip-next discussion for details. A new branch is available...
-
FWIW, I converted the code for LzFindOpt.asm to NASM format. I incorporate it into my lrzip-next lzma-21.03beta branch. Attaching the nasm-converted source in case anyone finds it useful. It's x64 bit only.
-
So, my bad. I ran tests and as you indicated, not a lot of time benefit. In debugger, I can see the function being called properly. Thanks for the excellent work and speedy reply. Starting lzma back end compression thread 0... [Switching to Thread 0x7ffff7051640 (LWP 13314)] Thread 3261 "lrzip-next" hit Breakpoint 5, _GetMatchesSpecN_2 () at /tmp/lrzip-next/src/lzma/ASM/x86/LzFindOpt.asm:123
-
ASM compiled fine, linked fine. Using LzmaLib and calling it with default parameters, the function never GetMatchesSpecN_2 gets called. Are the BTree hash routines not used by lzma?
-
I see in LzFindMt.c, this function is called in BtGetMatches and when MFMT_GM_INLINE is defined. What options are needed for LZMA to get here? I'd like to use the Assembler match finder if possible. And BtGetMatches() is called from BtFillBlock() static void BtGetMatches(CMatchFinderMt *p, UInt32 *d) { ... #ifndef MFMT_GM_INLINE while (curPos < limit && size-- != 0) { UInt32 *startDistances = d + curPos; UInt32 num = (UInt32)(GetMatchesSpec1(lenLimit, pos - p->hashBuf[p->hashBufPos++], pos, p->buffer,...
-
21.03beta: LzFindMt.c #define for assembler compilation
-
@ipavlov has released an Alpha version of LZMA SDK 21.02. The major feature is POSIX compatibility which makes the source easy to build on Linux and Mac systems. The x86 Assembler code is still MASM compatible, but the ARM code uses gcc buildable .S code. In my lrzip-next 21.02 branch, I have updated the ASM source for nasm compatibility, removed Windows code, and pretty-formatted everything for enhanced readability. (NB. lrzip-next is a detached fork of Con Kolivas' lrzip project with many improvements...
-
No Sam. The 19.00 SDK is not consistent with p7zip. You must use SDK 19.00 files. I was not able to upgrade p7zip. However, I limited myself to the C code and a small subset of LZMA files.
-
@tansy, the 19.00 SDK introduced some new features. Perhaps take a peek at my github for lrzip-next, goto src/lzma/ASM/x86. Here's the file in any event. HTH
-
Thank you @conor42, @ipavlov. There were two problems. 1. The COPY_VAR and RESTORE_VAR Macros assumed the source and destination member names were the same. I prefixed all local var equates with l_ so COPY_VAR would copy the variable to the wrong place. Of course, RESTORE_VAR would not work also. Ex. %macro COPY_VAR 2 ; macro name mov t0, GLOB_2(%1) ; name mov LOC_0(%2), t0 ; name, t0 In the ; ---------- LITERAL MATCHED ---------- LIT_PROBS LOC(l_lpMask) section, I did not use the LOC Macro and did...
-
@conor42 l_dicSpec and l_rep0 are corrupt. They seem to get assigned properly at the beginning. Since I did use some global substitutions in editing, maybe I confused LOC and LOC_0 somewhere along the way, or GLOB and GLOB_2. Thanks for the tip. Now I can work backwards. Probably something stupid! On a very small test file in copy_match, l_dic_Spec is totally corrupted. dicSize 33,554,432 l_limit 0 dicPos 0 cnt_R 313 sym_R 3 * l_dicSpec 0x697a726c2f746967 INVALID * l_rep0 -168965056 (4126002240)...
-
@tansy, actually I adopted this file for lrzip using lzma SDK 19.00. I was inspired by p7zip and only use the multi threading files Threads.c and Threads.h. I compiled it and created listing, disassembled, and ran through gdb. I'm not sure it's compatible with 16.02. You can compile with nasm -Dx64 -f elf64 -g -F dwarf -o LzmaDecOpt.o -l LzmaDecOpt.lst LzmaDecOpt.asm (all on one line, of course) Be aware I left out a comment mark on line 992 which must be corrected or a compile error will occur....
-
Thanks, @ipavlov, for the suggestions. I'll keep at it. I'm wondering if I'm popping the wrong registers on return.
-
Well one problem solved. The REG_PARAM_0-4 registers had to be changed for *nix in 7zAsm.asm. Thanks to Conor McCarthy. The attached file has a FIXME in it. Anyone with knowledge as to how to backtrace the error, your help is appreciated. The file is almost complete! # for WIN64-x64 ABI: .equ REG_PARAM_0, r1 .equ REG_PARAM_1, r2 .equ REG_PARAM_2, r8 .equ REG_PARAM_3, r9 # for System V AMD64 ABI: .equ REG_PARAM_0, r7 .equ REG_PARAM_1, r6 .equ REG_PARAM_2, r2 .equ REG_PARAM_3, r1 But after some iterations,...
-
I started with the Windows ASM file. The MASM directives don't convert 1:1. The disassembly listing helped somewhat. I found one source, fast_lzma2 which has a modified version of it in Intel format (which compiles nicely with gcc). But fast_lzma2 is not compatible with LZMA. But Conor's .S file helped a lot to set this up. Since I wrote this post I made a lot of headway, and LzmaDecOpt.asm compiles. It's just a matter of making sure I have the correct pointer sizes and that it in fact will work...
-
In LZMA SDK 19.00 an optimized decompress Asm module, LzmaDecOpt.asm is introduced. Has anyone succeeded in converting this from MASM to NASM syntax? It's a worthwhile project since it could significantly speed up decompression. While I've been able to convert macros, defines, includes, and function calls, I'm still not getting everything I need to get it to compile properly. Thank you for anyone withing to take a run at this!
-
I only work with a small subset of files in the /C directory, but I have been able to insert SDK 19 code into my projects with the following files modified. After copying files from /C in lzma SDK 19.00 Edit MtCoder.h and uncomment /* #define MTCODER__USE_WRITE_THREAD */ Copy over Threads.c and Threads.h from p7zip 16.02 Edit Threads.h and add this line around line 90 #define Semaphore_IsCreated(p) ((CSemaphore *) (p) != NULL) YMMV, but these small changes allowed me to use SDK 19 in my code. Hope...
1