Int64 and QWord not ordinal types? lazarus / 64-FPC development ---------------------------------------------------------------------- DavidL · 2026-05-01 13:27 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 · 2026-05-01 13:35 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 · 2026-05-01 16:57 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 · 2026-05-01 23:55 Quote from: Thaddy on May 01, 2026, 06:57:52 pmIt 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 · 2026-05-02 00:13 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 · 2026-05-02 06:11 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 · 2026-05-02 12:46 Quote from: 440bx on May 02, 2026, 02:13:26 amAside 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 · 2026-05-02 12:53 Quote from: DavidL on May 02, 2026, 02:46:43 pmThis 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 · 2026-05-02 16:12 Quote from: Thausand on May 02, 2026, 02:53:34 pm... 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 · 2026-05-03 20:49 Quote from: Thausand on May 02, 2026, 02:53:34 pm... 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 · 2026-05-03 21:08 Quote from: Remy Lebeau on May 03, 2026, 10:49:42 pmNot 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 · 2026-05-03 21:57 Quote from: DavidL on May 02, 2026, 02:46:43 pman 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. ---------------------------------------------------------------------- H₂SO₄ · 2026-05-04 05:57 Quote from: 440bx on May 03, 2026, 11:08:07 pmDo 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. Quote from: creaothceann on May 03, 2026, 11:57:03 pmSo 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 · 2026-05-04 07:32 Quote from: Khrys on May 04, 2026, 07:57:52 amLegacy 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 · 2026-05-04 10:24 Quote from: nanobit on May 04, 2026, 09:32:51 amNot 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. ---------------------------------------------------------------------- marcov · 2026-05-04 11:37 Note that afaik is a limitation stemming from the Borland Pascal FOR loop.  Classic Pascal did afaik allow regvars larger than register size. I guess it simply makes optimizing FOR harder (more cases) for little added benefit. ---------------------------------------------------------------------- Thaddy · 2026-05-05 14:24 Nope. And Yes. The P-compilers (some of them) allowed that, but they are just that: P-compilers, geared towards everything being better in the past. Try running P5... ---------------------------------------------------------------------- marcov · 2026-05-05 16:04 Quote from: Thaddy on May 05, 2026, 04:24:53 pmNope. And Yes. The P-compilers (some of them) allowed that, but they are just that: P-compilers, geared towards everything being better in the past. Try running P5... P compilers are not the only non Borland derived compilers. I'm talking about eighties mainframe and minicomputer pascal compilers. ---------------------------------------------------------------------- Thaddy · 2026-05-05 17:57 So basically when I was teaching Pascal at university? UCSD?  Come on Marco, you know where I am coming from. You were 10 or eleven. And I just left the - obligatory- army service. My world with Pascal started with UCSD on Apple, hence the reference to P... Of course you are right about some real compilers at the time, I never saw them. And WFW and the likes are luxury versions of the dos extenders... ---------------------------------------------------------------------- marcov · 2026-05-05 19:12 Quote from: Thaddy on May 05, 2026, 07:57:58 pmSo basically when I was teaching Pascal at university? UCSD?  Come on Marco, you know where I am coming from. You were 10 or eleven. And I just left the - obligatory- army service. Dodged that, but I did went through the check-up. QuoteMy world with Pascal started with UCSD on Apple, hence the reference to P... That it is all that you know as non-borland Psacal,  doesn't excuse you dismissing the rest.