Re^4: Accessing Memory-mapped I/O

Replies are listed 'Best First'.
Re^5: Accessing Memory-mapped I/O by stevieb (Canon) on Oct 31, 2019 at 20:11 UTC
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.	[reply] [d/l] [select]
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.	[reply]
Re^7: Accessing Memory-mapped I/O by jcb (Parson) on Nov 01, 2019 at 22:42 UTC
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?	[reply]
Re^8: Accessing Memory-mapped I/O by jdmonk (Initiate) on Nov 04, 2019 at 19:25 UTC
Re^7: Accessing Memory-mapped I/O by Anonymous Monk on Nov 01, 2019 at 12:18 UTC
My last sentence should be: "Other processes can access addresses outside the system ram without an issue."	[reply]
Re^8: Accessing Memory-mapped I/O by Corion (Patriarch) on Nov 01, 2019 at 15:07 UTC