[SOLVED] 64-bit FPC generate 386 code (LZMA decoder error)

[tk]

Hi,
having strange problem with the pascal LZMA port, http://www.birtles.org.uk/programming/.
The decoder works only when compiled with 32 bit compiler.
Not when compiled with 64bit compiler.
The encoder works with both compilers ok and produces the same packed files.

Is there any option to say the compiler to generate 386 code for some units?
SOmething like the $G option in TP?
The decoder is full of shl, shr and or operations because it plays with stream bits.
I think somewhere there is the problem.
Already tried to replace all Integers with Longints but didn't help.

Thanks tk

[marcov]

It's probably either a bug or a mode problem. Do you compile with -Sd or {$mode delphi}?

Lots of old Delphi code is full of bugs that potentially that hamper 64-bit usage.

The only solution is to stay on 32-bit or fix the bug.   Typical issues are 32-bit assembler (sometimes accepted in 64-bit), integer to pointer conversions

[tk]

Yes this must be a bug in 64bit FPC, added a bug report
http://bugs.freepascal.org/view.php?id=26471

[Laksen]

Longint arithmetic is expanded to the native integer type, or in some cases 64-bit.

So the correct way to do it in your case would be like this:
t := ((Code - Range) shr 31) and 1;

[marcov]

Yes this must be a bug in 64bit FPC, added a bug report
http://bugs.freepascal.org/view.php?id=26471

I meant a bug in the LZMA code, unless it works with 64-bit Delphi.

[tk]

Longint arithmetic is expanded to the native integer type, or in some cases 64-bit.

Unless you retype it to the same type you are working with (here LongInt)...

32 bit Delphi behaves the same as 32 bit FPC, tried for ShortInt, SmallInt now.
In 32 bit Delphi SHR produces negative value from negative value for ShortInt, SmallInt but positive value for Longint.
So generally it is not FPC bug.

Don't have the 64bit Delphi compiler now and won't reopen the issue although I am not very satisfied with this way of compilation.
When working with some bit width I would expect all the operations would take place in that bit width (from my point of view, of course compiler can internally use the most effective way).
SHR is declared as bitwise operator so I would always expect for a negative number to get positive number when SHRed.
As is the case when you SHR this in 32 bit width with 32 bit compiler.
And as is the case when you retype the result as described in my second comment to the bug report.
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/expressions_xml.html

But why to explicitly retype when the operation result should be already of that type?
I don't know.

Either way, the LZMA decoder works for me now on 64bit compiler, the retyping solved this (your solution would probably either, didn't try).
Hope this thread will help to somebody else trying to use it.