Recent

Author Topic: Some fun with bitmanipulations  (Read 2033 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 9140
Re: Some fun with bitmanipulations
« Reply #15 on: October 10, 2019, 04:39:47 pm »
Bart, the issue seems related to other versions than trunk:
Compile this with the real patch! It passes all tests too..
{$mode delphi}{$H+}{$rangechecks on}
uses sysutils;
var a:shortint = 0;
begin
  a.setbit(7);
  writeln(a);
end.

As well as any other types....

I will update the factored out version, though.
also related to equus asinus.

garlar27

  • Hero Member
  • *****
  • Posts: 618
Re: Some fun with bitmanipulations
« Reply #16 on: October 10, 2019, 05:11:00 pm »
Thaddy, did you see BitHelpers by Avra?

He was working on something similar.

Thaddy

  • Hero Member
  • *****
  • Posts: 9140
Re: Some fun with bitmanipulations
« Reply #17 on: October 10, 2019, 05:47:36 pm »
Thaddy, did you see BitHelpers by Avra?

He was working on something similar.
Yes. I encouraged him even.

But this version can be integrated in the rtl.
also related to equus asinus.

Bart

  • Hero Member
  • *****
  • Posts: 3538
    • Bart en Mariska's Webstek
Re: Some fun with bitmanipulations
« Reply #18 on: October 10, 2019, 08:21:21 pm »
Hi Thaddy,

Attached a modified version of your original code (all bit manipulation is done with unsigned types).
Also an extensive test suite that tests all then methods you added for different bitness (even for 16-bit mode).
Its quite a bit more extensive than your test in the bugtracker.
It does all bit manipulation-methods (setbit, togglebit, clearbit, testbit) for all possible bits of a given type.

With my modifications the test program passes all tests.

When I have time, I will apply your last patch in the bugtracker to trunk and see if my tests pass.

Bart

Thaddy

  • Hero Member
  • *****
  • Posts: 9140
Re: Some fun with bitmanipulations
« Reply #19 on: October 10, 2019, 09:02:11 pm »
Thanks Bart,
This looks good, but I also want to check why the original stuff failed. That is still not clear to me (128).
If I can test everything OK, I will submit your suggestions in a final patch. Again, thanks for the support.
also related to equus asinus.

Bart

  • Hero Member
  • *****
  • Posts: 3538
    • Bart en Mariska's Webstek
Re: Some fun with bitmanipulations
« Reply #20 on: October 11, 2019, 12:16:48 am »
See my notes and updated test-program in the bugtracker.

Bart

valdir.marcos

  • Hero Member
  • *****
  • Posts: 830
Re: Some fun with bitmanipulations
« Reply #21 on: October 11, 2019, 02:59:04 am »
Just for reference:
0036146: PATCH extended ordinal helpers for bit patterns
https://bugs.freepascal.org/view.php?id=36146

PascalDragon

  • Hero Member
  • *****
  • Posts: 664
  • Compiler Developer
Re: Some fun with bitmanipulations
« Reply #22 on: October 11, 2019, 10:02:14 am »
On Linux it's rather easy to test other platforms using QEMU's user space emulation (at least as long as you don't require any C libraries). The following is an example for m68k (it assumes the binutils are available as m68k-elf-*, in the $fpcdir is a directory testoutput and the test program is at $fpcdir/fpctests/tmyprogram.pp):

Code: [Select]
cd $fpcdir
make clean all BINUTILSPREFIX=m68k-elf- CROSSOPT=-Cpcfv4e
./compiler/pprcoss68k -n -Furtl/units/m68k-elf -XPm68k-elf- -FEtestoutput ./fpctests/tmyprogram.pp
qemu-m68k -cpu cfv4e ./testoutput/tmyprogram
(Note: untested, as I'm not on my development machine)

Even running the testsuite is possible with this using a script that is passed to the EMULATOR option of the makefile ;)

MarkMLl

  • Full Member
  • ***
  • Posts: 209
Re: Some fun with bitmanipulations
« Reply #23 on: October 11, 2019, 03:48:57 pm »
On Linux it's rather easy to test other platforms using QEMU's user space emulation (at least as long as you don't require any C libraries).

"Up to a point, Lord Copper" :-)

There's enough peculiarities in SPARC etc. relating to alignment and the extent to (and speed with) which the kernel handles alignment exceptions that relying on the Qemu maintainers' understanding of how real hardware will behave is probably unwise: it's yet another unknown in what usually turns out to be a complex set of equations.

And if it's really that easy why is https://bugs.freepascal.org/view.php?id=22696 still unfixed? :-) :-) :-) :-) :-)
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

jamie

  • Hero Member
  • *****
  • Posts: 2068
Re: Some fun with bitmanipulations
« Reply #24 on: October 12, 2019, 01:33:54 am »
You know, I always thought most of the basic lib files were synced between the 32 and 64 bit versions of Lazarus and fpc.. I guess I was wrong, again! >:(

  I just discovered that the helpers for the QWord and Int64 report 32 bit values when using the 64 bit Lazarus release 2.0.4 with Fpc 3.0.4

  This maybe the cause of many headaches when working with Helpers .

EDIT:
 Apparently this has been fixed in fpc 3.3.x

 How many more decades do we need to wait for this in Lazarus?

 I don't like using tools that change every other day.
« Last Edit: October 12, 2019, 03:16:08 am by jamie »
Number 1 at blue screen app creations!

Thaddy

  • Hero Member
  • *****
  • Posts: 9140
Re: Some fun with bitmanipulations
« Reply #25 on: October 12, 2019, 01:07:00 pm »
Here's a new version based on - but not equal to - Bart's suggestions.

Note the bug regarding the size in 3.0.4 is a bug in Freepascal and this was fixed in 3.2.0 (32 vs 64 bit) and not part of the bugs in my code.
Note Bart's tests all pass. (Both with the patch and with the factored out helper as presented here)
« Last Edit: October 12, 2019, 03:15:53 pm by Thaddy »
also related to equus asinus.

MarkMLl

  • Full Member
  • ***
  • Posts: 209
Re: Some fun with bitmanipulations
« Reply #26 on: October 14, 2019, 09:46:17 am »
Should definitely be unsigned. You still need to be careful with 64-bit values if you go that high, since I believe they're stored internally as signed.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

PascalDragon

  • Hero Member
  • *****
  • Posts: 664
  • Compiler Developer
Re: Some fun with bitmanipulations
« Reply #27 on: October 14, 2019, 09:59:10 am »
On Linux it's rather easy to test other platforms using QEMU's user space emulation (at least as long as you don't require any C libraries).

"Up to a point, Lord Copper" :-)

There's enough peculiarities in SPARC etc. relating to alignment and the extent to (and speed with) which the kernel handles alignment exceptions that relying on the Qemu maintainers' understanding of how real hardware will behave is probably unwise: it's yet another unknown in what usually turns out to be a complex set of equations.
It does not account for everything, yes, but in this case regarding endianess it would be plain Pascal programming errors anyway.
And at least for ARM it definitely helped to fix the alignment mess in the RTTI.

And if it's really that easy why is https://bugs.freepascal.org/view.php?id=22696 still unfixed? :-) :-) :-) :-) :-)
You even quoted the reason for this:
Quote
(at least as long as you don't require any C libraries)
For UI programs like lhelp you need to have all the required libraries available for the target platform. Fixing problems that are caught by FPC's testsuite is much easier. Though in this specific case one might be able to try the chm utility provided with FPC...

Thaddy

  • Hero Member
  • *****
  • Posts: 9140
Re: Some fun with bitmanipulations
« Reply #28 on: October 14, 2019, 10:01:47 am »
I have submitted a new patch based on Michael's suggestions.
And indeed: all internal processing needs to be unsigned. (actually the signed/unsigned issue is only to represent the result)
The new patch passes all tests in all modes that support type helpers.
I will add a version for older than trunk later.
also related to equus asinus.

Bart

  • Hero Member
  • *****
  • Posts: 3538
    • Bart en Mariska's Webstek
Re: Some fun with bitmanipulations
« Reply #29 on: October 14, 2019, 01:57:20 pm »
I have submitted a new patch based on Michael's suggestions.
And indeed: all internal processing needs to be unsigned.

Wasn't that my suggestion?

Bart