in reply to Re^4: Accessing Memory-mapped I/O
in thread Accessing Memory-mapped I/O

What system is this (OS, 32 or 64 bit etc), and what version of perl? I can't reproduce the Perl issue you describe on Linux Mint 18.3 64-bit, nor Raspbian (armv7l) 32-bit. Both return without any warning or error (even after adding strict and warnings).

On the 64-bit platform I've got Perl 5.26.1, and on the 32-bit one, I've got Perl 5.30.0.

Update: I agree with Corion, the Perl code doesn't reflect at all what the C code is doing.

Replies are listed 'Best First'.
Re^6: Accessing Memory-mapped I/O
by Anonymous Monk on Nov 01, 2019 at 12:16 UTC

    Stievieb- thank you for trying the code on your systems.

    I am using altera-ltsi 4.1.33 on an armv7l (32-bit) and perl 5.2.22.

    I understand that the Perl code isn't doing the same thing as the C-code. My question really is whether there is something with my Perl build (or code) that would prevent me from accessing memory outside the system ram. Other processes can access that ram without an issue.

      I am using altera-ltsi 4.1.33 on an armv7l (32-bit) and perl 5.2.22.

      Is that an error or is your perl even more ancient than the venerable (and now very obsolete) 5.005?

        Good catch. That should be 5.22.2.

      My last sentence should be: "Other processes can access addresses outside the system ram without an issue."

        You will have to find out whether /dev/mem supports what you want, and whether the seek call accepts offsets larger than 2GB on your system.

        If either of these fails, you will have to find a different approach than reading from /dev/mem, like using one of the mmap calls.

        If the seek function takes and understands a 64bit value, you will have to look at the output of perl -V to find out why it is not using this version of the seek call. For example if -Duselargefiles is missing in the output, that is a sure sign that your Perl was not build properly for your system.