Hello together!

A little entry about some details of Delphi x64 I stumbled on today:

http://wiert.wordpress.com/2010/11/01/more-delphi-x64-bits-allen-bauer-kylix_rd-on-twitter/

Most notable:

As speculated, the Tag property will become a NativeInt.

// didn't we have a discussion about this a few days ago?

So, Extended = Double.

// how is this in FPC? Extended is just not available on x86_64, or?
(well... I don't use Extended anyway ^^)

Type sizes for 64: SizeOf(Integer)=4,

SizeOf(NativeInt)=SizeOf(Pointer)=8,

// they needed to call it NativeInt, didn't they? They couldn't have
gone with PtrInt -.-

Regards,
Sven

PS: I've not posted this to lazarus-other, cause I'm not subscribed there.

Op 2010-11-01 11:26, Sven Barth het geskryf:

A little entry about some details of Delphi x64 I stumbled on today:

And let me guess, they took no cues from FPC, and had to make sure there is as much "incompatibility" as humanly possible! This is why I say, FPC should cut any ties with Delphi and simply innovate on it's own.

> So, Extended = Double. // how is this in FPC? Extended is just not available on x86_64, or? (well... I don't use Extended anyway ^^)

FPC has Extended and it's rang is 19-20 significant digits with range: 1.9E-4932 – 1.1E4932
It's size is 10 bytes.

> Type sizes for 64: SizeOf(Integer)=4, SizeOf(NativeInt)=SizeOf(Pointer)=8,

Oh f**k, please don't tell me FPC is now going to downgrade Integer to a 32-bit type. This will break such a LOT of programs!!

// they needed to call it NativeInt, didn't they? They couldn't have gone with PtrInt -.-

Definitely not, because that would be FPC compatible.

Regards,
- Graeme -

There are times where I think the same...

I'm aware that FPC has Extended. But the point is that it's not supported on all platforms, cause not every platform can handle 80bit floating points.
My question was more: Is Extended usable/enabled on Win64 or is it Extended=Double as well?

Ehhhh... In modes "objfpc" and "delphi" SizeOf(Integer) = 4 is already the case no matter what bitness your system has. For that purpose "PtrInt" (and "PtrUInt") were added. Only in modes "fpc" and "tp" SizeOf(Integer) = 2 is true (one can argue whether that was a good decision but that's the way it is...)

Yes... although I found a statement some time ago when they introduced "exit with argument". In a comment to that a Delphi developer said "We never broke compatibility with FPC on purpose". It's a pity that I'm not able to find that statement again :(

Regards,
Sven

Op 2010-11-01 12:21, Sven Barth het geskryf:

Ehhhh... In modes "objfpc" and "delphi" SizeOf(Integer) = 4 is already the case no matter what bitness your system has. For that purpose

Oh, when did that change? I looked up the information in FPC's Language Reference docs "Predefined integer types" table. My copy had Integer as 2,4 or 8 bytes. I just downloaded a new copy of FPC 2.4 Language Ref, and indeed that table has been update to show 2 or 4 bytes as the Integer size.

Ummm... interesting.

"exit with argument". In a comment to that a Delphi developer said "We never broke compatibility with FPC on purpose". It's a pity that I'm not able to find that statement again :(

I'm sure Embarcadero deleted it off the internet. ;-)

Regards,
- Graeme -

It was always the case in the implementation (as far as I'm aware of), but it might be that the documentation didn't reflect that ^^

Regards,
Sven

Op 2010-11-01 13:02, Sven Barth het geskryf:

It was always the case in the implementation (as far as I'm aware of), but it might be that the documentation didn't reflect that ^^

Yes, Michael just confirm that. The docs were wrong.

Regards,
- Graeme -

Sven Barth wrote

I'm aware that FPC has Extended. But the point is that it's not supported on all platforms, cause not every platform can handle 80bit floating points. My question was more: Is Extended usable/enabled on Win64 or is it Extended=Double as well?

Extended = double on Win64 in FPC as well.

Jonas

AFAIK this type is not available on x64 architecture, and the use of the FPU is discouraged as well - has somebody a reference to this strange change? Are 128 bit reals available now, as a replacement?

That's why a x64 system even cannot cross-compile for i386 (and other) targets, without using an FPU emulator.

That's how most programming languages behave, not only FPC and Delphi.

IMO subranges should be used, for values with an guaranteed bit/byte count. In those good ole days[tm] Fortran and Cobol allowed to specify the byte count or number of digits for every single integral, real and string variable. And that even before bytes and chars had settled down to 8 bits. Wirth only added a finer granularity, with the introduction of subrange types.

> // they needed to call it NativeInt, didn't they? They couldn't have > gone with PtrInt -.- Definitely not, because that would be FPC compatible.

It's wise to have different names for different origins. This allows to define the imported types (from other languages/compilers) as appropriate, in either environment.

DoDi

Ok, thanks for the clarification. :)

Regards,
Sven

This type is basically available on x64 (because every x86_64 can also run i386 code which might require the Extended type), but Microsoft (!) discourages the use of the FPU on Win64. Also Extended isn't necessarily available on other platforms as well (e.g. ARM). So Extended might not be even really needed cause Double is already enough for most important stuff.

That might be the case, but in the good old times of Turbo Pascal / early Delphi the Integer was thought of as the "signed register width type". You can still see this if you switch between modes fpc/tp and objfpc/delphi:
- fpc/tp: SizeOf(Integer) = 2
- objfpc/delphi: SizeOf(Integer) = 4

So it might have been more logically to stay with "SizeOf(Integer) = SizeOf(Pointer)". I can only guess why the decision by the FPC team was to let Integer stay a 32bit type on 64bit systems: it might be to ease the porting of Delphi code (which was 32bit only after all).

Once a 64 bit Delphi is out I can already imagine that one of the first bug reports in Mantis will be: "NativeInt not found" or "Add type NativeInt". So your point about having different names for different origins won't hold long...

Regards,
Sven

Actually, that's what also basically the pascal standard says, but ...

You can still see this if you switch between modes fpc/tp and objfpc/delphi: - fpc/tp: SizeOf(Integer) = 2

... but tp: sizeof(pointer)=4

- objfpc/delphi: SizeOf(Integer) = 4 So it might have been more logically to stay with "SizeOf(Integer) = SizeOf(Pointer)".

Actually sizeof(integer)=sizeof("alu register")

There where multiple reasons why we left sizeof(integer)=4 on 64 bit architectures:
- changing the size of data types always breaks a lot of existing code
- sizeof(int) on Windows 64 bit is 4 as well
- using 16 bit ints on i386 had a performance penalty while using 32 bit ints on x86-64 has none
- there are probably a few applications which benefit from sizeof(integer)=8 instead of 4
- code depending on sizeof(pointer)=sizeof(integer) might be broken anyways and it doesn't apply to 8 bit systems either (e.g. avr) or even TP, see above

Sigh...

Ok... I wasn't aware of this. When I programmed in TP I hadn't understood the concept of pointers yet :P

You're right of course... it's alu register not pointer...

Thank you for this list of reasons.
But at least when interfacing with Windows one could have replaced all Integer with LongInt to stay compatible... (in theory at least ^^ )

Regards,
Sven

Sven Barth wrote

But at least when interfacing with Windows one could have replaced all Integer with LongInt to stay compatible... (in theory at least ^^ )

The TP to Delphi change was one of the reasons I always use longint in Delphi now, and never, ever use integer. In C, I have an include to make everything read like u8, s16, u32 etc, and never use internal type names at all except occasionally for simple loop counters where the count is low. Should I need to do any 64 bit FPC, I'll probably do something similar for all my sources, and curse every time I use someone else's that breaks.

Jeff.

So Extended might not be even really needed cause Double is already enough for most important stuff.

Definitely not! I once wrote a numeric simulator which did not converge with single type. Only extended lead to the correct results. The number of significant bits is quite important, because the convergence criterion has to be lower than the available significant bits and double only has about 16 while extended has 19-20.

The TP to Delphi change was one of the reasons I always use longint in Delphi now, and never, ever use integer.

Yes, I also never use any generic types (like string or integer). It begs for trouble once you migrate such code to another platform. I always program with the limits of datatypes in mind (I think it's necessary to do so). If such limits change, my whole program may have a problem. So I never want data types changed in the background without me knowing.

In our previous episode, Florian Klaempfl said:

See also http://www.stack.nl/~marcov/buildfaq/#toc-Section-5.1

Number crunching can be "outsourced" into a dedicated library, together with an emulator for all targets without native reals of the required types.

The compiler is affected only in the evaluation of untyped FP literals and constant expressions, which could be defined to be of type Double only.

DoDi