Int64 and QWord not ordinal types?

[DavidL]

I'm sure this has been covered before (likely ad nauseam) but forum searches turned up nothing helpful.  Why, in 2026, are Int64 and QWord not ordinal types?  What with all the "convenience clutter" that's been jammed into FPC over the years wouldn't this have to be considered a truly fundamental oversight?

[cdbc]

Hi
That depends on your machine's bitness -- 32bit: ordinals are up to LongWord, 64bit: ordinals are up to QWord.
PtrInt & PtrUInt are aliases for the platforms /pointersized/ integers, i.e. they are 4 bytes on 32bit & 8 bytes on 64bit
Regards Benny

[Thaddy]

It is just like using compiling for 32 bit on a 64 bit platform is a very sane thing, if one would rephrase your 2026 remark...
Because you only run into that if you compile for 32 bit on a 64 bit platform.

[DavidL]

It is just like using compiling for 32 bit on a 64 bit platform is a very sane thing, if one would rephrase your 2026 remark...
Because you only run into that if you compile for 32 bit on a 64 bit platform.

Sorry but none of that makes any sense and doesn't address the actual question of "why?".  Everything that can be done with a 16-bit ordinal can be done with a 32-bit ordinal irrespective of the compilation target's bit width, right?  It follows that everything that can be done with a 32-bit ordinal should be doable with a 64-bit ordinal, again irrespective of the compilation target's bit width.  The documentation's unhelpful "some Pascal constructs will not work with these two integer types." doesn't bother to list the faulty constructs, so one is just left to wander in the wilderness.

[440bx]

Aside from all the mathematical properties an ordinal type must comply with, in programming, there is a usually unspoken/unstated rule that an ordinal type must fit entirely in a CPU register.

Because of this, in 64 bit programming, an int64 or a qword is considered an ordinal type whereas neither of those two types are considered ordinals in 32 bit programming. 

For instance, in FPC, a "for" loop can use an int64 or qword as a loop index in 64 bit but cannot in 32 bit.  The reason ?... simply register size, neither one of them fits in 32 bits which is the register width of a 32 bit architecture.

[Thaddy]

It is also consistent over all supported cross-compilers:
from 8bit registers upto 64 bit register size, the maximum size of an ordinal equals the register size. As with most real compilers, btw.

[DavidL]

Aside from all the mathematical properties an ordinal type must comply with, in programming, there is a usually unspoken/unstated rule that an ordinal type must fit entirely in a CPU register.

Because of this, in 64 bit programming, an int64 or a qword is considered an ordinal type whereas neither of those two types are considered ordinals in 32 bit programming. 

For instance, in FPC, a "for" loop can use an int64 or qword as a loop index in 64 bit but cannot in 32 bit.  The reason ?... simply register size, neither one of them fits in 32 bits which is the register width of a 32 bit architecture.

This explains it completely, thanks - an "unspoken/unstated rule" established by an arbitrary, lazy implementation decision and calcified by never being corrected, got it.   

[Thausand]

This explains it completely, thanks - an "unspoken/unstated rule" established by an arbitrary, lazy implementation decision and calcified by never being corrected, got it.   

... and all other programing language. It not fpc/pascal specific.

[440bx]

... and all other programing language. It not fpc/pascal specific.

Correct and, it is very important to point this out because a 1024 bit integer type is still, mathematically speaking, an ordinal but, using that as a loop counter in a 64 bit architecture would be a performance disaster (not to mention an 8 bit one.)

The performance alone is enough to justify limiting ordinals to what fits in a register and that's not the only reason.

[Remy Lebeau]

... and all other programing language. It not fpc/pascal specific.

Not ALL programming languages. Many languages handle 64bit ordinals in 32bit environments just fine. What a LANGUAGE can handle and what a CPU can handle are two separate things. 64bit ordinal operations can be implemented using 32bit commands if needed. Not being able to handle a 64bit ordinal in a for loop is a limitation of a compiler implementation, not a CPU.

[440bx]

Not ALL programming languages. Many languages handle 64bit ordinals in 32bit environments just fine. What a LANGUAGE can handle and what a CPU can handle are two separate things. 64bit ordinal operations can be implemented using 32bit commands if needed. Not being able to handle a 64bit ordinal in a for loop is a limitation of a compiler implementation, not a CPU.

True, the choice is a compiler implementation limitation.  Do you have an example of a 32 bit compiler that considers 64 bit integers to be ordinals, by that I mean, does not impose some limitations on the usage of the 64 bit ordinal that aren't also imposed on the 32 bit version ?  I ask because, of the top of my head, I cannot think of one.

[creaothceann]

an arbitrary, lazy implementation decision

32-bit code can emulate 64-bit registers (e.g. via ADC on x86), but for each one you still need another register to store the upper half. You'll quickly have to spill variables to the stack.

This is a complete non-issue on 64-bit CPUs. So the question is, why haven't you adjusted the project settings to use a 64-bit CPU target? 64-bit CPUs have been available for mainstream computers since 2003 (x86-64) and 2011 (AArch64). Perhaps this should be the default for 64-bit Lazarus projects, and 32-bit builds shouldn't even be offered.

[Khrys]

Do you have an example of a 32 bit compiler that considers 64 bit integers to be ordinals, by that I mean, does not impose some limitations on the usage of the 64 bit ordinal that aren't also imposed on the 32 bit version ?

AVR-GCC handles 64-bit integers just fine, and Rust's built-in 128 bit integer types are perfectly usable for e.g. loop indices.

So the question is, why haven't you adjusted the project settings to use a 64-bit CPU target? 64-bit CPUs have been available for mainstream computers since 2003 (x86-64) and 2011 (AArch64).

Legacy dependencies perhaps?

[nanobit]

Legacy dependencies perhaps?

True, unported source code, libraries, "extended" floating point.
Not every app needs the 64 bit address space, and 32-bit apps always have been able to use all virtual memory outside of the 32-bit space, by createFileMapping( -1, ...), which is useful for keeping large data (eg. bitmaps) in RAM.

[creaothceann]

Not every app needs the 64 bit address space, and 32-bit apps always have been able to use all virtual memory [...]

Even so, 64-bit code has access to many more registers. That alone is a huge speed-up.

If there's perhaps one thing missing that 64-bit Free Pascal could implement, it's a mode in which "pointer" is 32 bits in size.