From Newsgroup: comp.arch
Anton Ertl <
anton@mips.complang.tuwien.ac.at> schrieb:
After our discussion a few days ago about I32LP64 vs. ILP64 I searched
for "ILP64" to see if anybody had written more about it or even
implemented it. And what did I find:
https://www.intel.com/content/www/us/en/docs/onemkl/developer-guide-linux/2025-2/using-the-ilp64-interface-vs-lp64-interface.html
|The Intel oneAPI Math Kernel Library (oneMKL) ILP64 libraries use the >|64-bit integer type (necessary for indexing large arrays, with more
|than 2^31-1 elements), whereas the LP64 libraries index arrays with the >|32-bit integer type.
This looked strange to me, because C (which has the ints, longs, and
pointers that the ILP refers to, indexing is performed with size_t,
which tends to be 64 bit even on I32LP64 systems (as was pointed out
to me many years ago when I brought up array indexing as another
reason to prefer ILP64).
But it turns out that the whole section is actually about Fortran, the language that, according to Thomas Koenig, requires that INTEGERs have
the same size as REALs, and half the size of DOUBLEs,
Not according to me, according to the standards from FORTRAN
66 to Fortran 2023. If you want to check this, download
https://j3-fortran.org/doc/year/23/23-007r1.pdf and look
at clause 19.5.3 (Storage association).
But it is quite funny that you bring that up, I recently committed
a patch for invoking BLAS matmul with 64-bit INTEGER types for
indices, see
https://gcc.gnu.org/gcc-16/changes.html#fortran .
and where 64-bit
INTEGERs are therefore supposedly a no-no.
That is somewhere between a misunderstanding and a misrepresentation,
I'm not sure where it falls on that scale.
Apparently Intel thinks
differently.
No.
In any case, if Fortran INTEGER is the only way to index
an array, I am surprised that Fortran has not run into difficulties
with 32-bit INTEGERs a decade or three ago.
That was the case when the first 64-bit systems were developed,
and the I32LP64 architectures defined, and when those considerations
were meaningful.
As I wrote, during that time, FORTRAN 77 (with vendor extensions,
to be sure) was the name of the game, and Fortran 90 compilers had
not really appeared. One of the vendor extensions, widely used,
is INTEGER*8, which (usually) specifies a 64-bit integer. But
plain, unadorned INTEGER, still used in the vast majority of codes,
at the time, had to be the same size as a REAL, and this is the case
to this day.
People used this for a very good (or very bad) reason: There was
no dynamic storage management in FORTRAN. People used huge COMMON
blocks and parcelled them out. They could be used for DOUBLE PRECISION
and INTEGER (via EQUIVALENCE), and the program had to rely on the
fact that a DOUBLE PRECISION took two storage units, and INTEGER
took one. Anybody messing with that would have lost their FORTRAN
customers faster than they could have said "compiler".
And I'm told that large software packages still rely on this kind
of thing to this day, although the language has had dynamic
allocation (and even auto-allocation on exiting of a block,
very handy) for decades.
Fortran 90 introduced KIND numbers, so you can wirite since then
integer, parameter :: ik = selected_int_kind(18) ! Select an integer
! with at least decimal 18 digits, in practice this is usually 64 bits.
integer(kind=ik) :: i ! And declare a variable.
You can use i for indexing arrays just fine. If the system does
not support the number of digits, you get an error during compilation.
To sum this up: Since Fortran 90, you CAN have large integers,
and you could do so before, with vendor extensions. What you could
_not_ do was to make the plain, unadorned INTEGER a 64-bit quantity.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2