Hi experts ?

I suppose that FPC can create 64 bit (IA-32/64) code. Is that correct ? Linux and/or Windows ?

Can this be done by "cross"-compiling on a 32 Bit PC ? Linux and/or Windows ?

Does a 64 Bit FPC generated program need to run on a 64 Bit OS ? (Linux and/or Windows ?) or can it just use 64 Bit instructions internally ?

Does / can a 64 Bit FPC generated program include 32 Bit code as well so that it can run on a 32 Bit CPU ?

If any "No" would that be desirable ?

-Michael

Op Tue, 2 Oct 2007, schreef Michael Schnell:

Hi experts ? I suppose that FPC can create 64 bit (IA-32/64) code. Is that correct ? Linux and/or Windows ?

FPC can create IA32 and AMD64 code, not IA64 node.

Can this be done by "cross"-compiling on a 32 Bit PC ? Linux and/or Windows ?

Yes.

Does a 64 Bit FPC generated program need to run on a 64 Bit OS ? (Linux and/or Windows ?) or can it just use 64 Bit instructions internally ?

A 64-bit OS is necessary.

Does / can a 64 Bit FPC generated program include 32 Bit code as well so that it can run on a 32 Bit CPU ?

No.

If any "No" would that be desirable ?

No, because if the program can run on 32-bit, the only adavtage to go for 64-bit is speed. But, FPC generates currently slower 64-bit executables than 32-bit executables.

Therefore, if your program can run in 2 or 4GB, it makes more sense to use a 32-bit version on a 64-bit machine.

Daniël

Hi experts ? I suppose that FPC can create 64 bit (IA-32/64) code.

IA-32: yes, it's plain i386+ code
IA-64: no, IA-64 is the architecture used by the Itanium Or do you mean x86-64/AMD64/EMT64?

Is that correct ?

FPC can create IA32 and AMD64 code, not IA64 code.

That is what I meant by IA 32/64. I did not suppose it can create Inatium code :-) .

A 64-bit OS is necessary.

I suppose this is because the API calls generated are 64 bit. Correct ?

So you would need to compile/deploy both versions if you want the customer to optionally take advantage of 64 bit. No problem IMHO.

I suppose the 64 Bit OS takes care that any 32 bit program can run, anyway. Correct ?

No, because if the program can run on 32-bit, the only adavtage to go for 64-bit is speed. But, FPC generates currently slower 64-bit executables than 32-bit executables.

Oops ?!?! I supposed that using the much greater count of registers in 64 bit mode could speed up any kind of software. I suppose that the experts _are _working on that, though.

Thanks for your answers !

-Michael

Florian Klaempfl wrote

IA-64: no, IA-64 is the architecture used by the Itanium Or do you mean x86-64/AMD64/EMT64?

Sorry if this sounds stupid, but I've never dabbed into the 64bit world. What are all those XXX64 platforms / architectures? Architectures from different chip makers?

From the list I would guess: Intel, AMD and then ???

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

x86-64/AMD64/EMT64?

Right ! Sorry for the silly notation.

-Michael

Oops ?!?! I supposed that using the much greater count of registers in 64 bit mode could speed up any kind of software.

No. 64 Bit causes also more memory traffic because everything being an address has the double size. So it depends on the application if 64 bit is faster or not. And since the 64 bit port of fpc isn't that good yet as 32 bit one, the advantage of the higher amount of registers is lost even more easily.

[ Charset ISO-8859-1 unsupported, converting... ]

AMD64 : original (AMD)name of x86_64
EMT64 : Intel name of x86_64
x86_64: neutral (and GNU) name of x86_64.

IA-64 is of course Itanium and a really different architecture.

Ah, thanks Marco!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oops ?!?! I supposed that using the much greater count of registers in 64 bit mode could speed up any kind of software. I suppose that the experts _are _working on that, though.

Registers are only so useful. I have a very nice example program which is roughly 2x slower on 64bit version (on same machine) than 32bit version. It was a school project which did some tree search/generation (AI stuff) and had to use quite a lot of memory. The explanation of this slowdown given to me was simple.

In 64bits, the cache is same as in 32bits (same machine remember?), but the amount of memory not (pointers, alignment I guess? etc.)

I don't know the internals to know which things cause bigger cache hugging on 64bits, I'd guess at least pointers do, but perhaps everything is "native padded" for speed?

Thanks for your answers ! -Michael

Ales
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAgP6FoLZReEjiMgRAk3WAJwKa/nXvkxMfAxwf9Ujxs9hOaDQ0ACfT/H+ 91QIdh4G5AM0e1HylKU9/cc=
=JZtp
-----END PGP SIGNATURE-----

Hi,

in the 32 bits systems, the 'double' type is 64 bits long and the 'extended' type is 80 bits long. Are the 64 bits systems better than that ?

Thank you

Alain

Op Tue, 2 Oct 2007, schreef Alain Michaud:

Of course not, because the sizes of the floating point types is defined by the IEEE 754 standard. On x86_64, you will have exactly the same types as on i386: single (32-bit), double (64-bit) and extended (80-bit).

Daniël

Daniël Mantione wrote

Of course not, because the sizes of the floating point types is defined by the IEEE 754 standard. On x86_64, you will have exactly the same types as on i386: single (32-bit), double (64-bit) and extended (80-bit).

Except for Win64, where we only support single and double (because while the x87 is still supported there, it's deprecated).

Jonas

Ooops ?!?!?! No 80 Bit "extended" even though this is the native Floating point format of the CPU ?

-Michael

In some Win64 beta MS disabled even the use of the FPU. Because this went too far, MS marked the use of the FPU as deprecated.

It is supported but deprecated because x87 fpu simply gives compilers a headache.

In some Win64 beta MS disabled even the use of the FPU. Because this went too far, MS marked the use of the FPU as deprecated.

OK, for a Beta this might be OK (and done supposedly due to the OS failing to manage the FPU registers correctly), but the final product needs to support all the CPU offers.

-Michael

It is supported but deprecated because x87 fpu simply gives compilers a headache.

Are there new floating point instruction in the 64 bit instruction set and the old instructions are still there but not necessary to access the floating point hardware ?

If so, why would any 64 bit compiler use the old instructions at all ?

Do you suggest that the 80 bit IEEE floating point type is not supported by the 64 bit instruction set (so that the old instructions are necessary to handle this data type) ? Why would the CPU designers omit this type ?

-Michael

Op Thu, 4 Oct 2007, schreef Michael Schnell:

The x86 has nowadays 2 fpu's: the x87 and SSE. SSE does single and (if SSE2 present) double precision, the x87 single double and extended. On x86_64 the calling conventions have been designed to use the SSE registers.

This is also the difference between Windows and Linux: Under Linux, the extended precision is still defined in the calling convention, under Win64 it is not. It can still be used, but you need your own propietary calling convention.

Still, we're planning to support the extended on all platforms by means of softfloat. It could perhaps be a bit strange to do softfloat on Win64 if it can be done in hardware. But that is a future discussion.

Daniël

Daniël Mantione wrote

Still, we're planning to support the extended on all platforms by means of softfloat.

I don't think it would be a good idea to map the extended type to 80 bit soft float on platforms that don't support 80 bit fpu calculations in hardware. Many programs use "extended" by default without actually requiring 80 bit precision, and mapping those all to soft float would needlessly slow down such programs.

I think a separate type would be more appropriate.

Jonas

Op Thu, 4 Oct 2007, schreef Jonas Maebe:

Hmmm... I prefer to keep correct code that writes say, an extended type to a file working, over keeping code that falsely uses extended precision fast, especially as I expect people to correct such code anyway to take advantage of SSE performance.

In such case "extended" would also be a misleading name, since it would get "long double" semantics. Even worse, it would be a TP compatible extended on i386 and some x86_64 platforms and long double on other platforms.

Daniël

This might make sens if you want to use both FPUs at the same time. but preventing the use of one by the calling convention seems quite silly. AFAIK, in 32 Bit mode, SSE and FPU use the same registers to allow a pre-SSE OS to do the saving/restoring with switching tasks. I suppose with the 64 bit instruction set the registers are separate ???

OK. In Linux the problem seems not to exist ?

Still, we're planning to support the extended on all platforms by means of softfloat. It could perhaps be a bit strange to do softfloat on Win64 if it can be done in hardware. But that is a future discussion.

Sounds really silly, but of course I don't understand the details. In fact WIN 64 seems to be crippled here.

-Michael

It won't keep it working but rather break it, since currently writing an extended to file on virtually all platforms writes a double to the file.

over keeping code that falsely uses extended precision fast, especially as I expect people to correct such code anyway to take advantage of SSE performance.

I don't expect that to happen in most situations.

It's probably better to directly introduce a longdouble type with longdouble (128 bit) semantics on all platforms. I don't think that emulating the almost nowhere supported 80 bit type does much good.

Jonas

There is no use to do so because they share the execution units for floating point operations.

but preventing the use of one by the calling convention seems quite silly. AFAIK, in 32 Bit mode, SSE and FPU use the same registers to allow a

No. This was MMX. SSE is always separate.

No, it's cutting of old hindering stuff.

Op Thu, 4 Oct 2007, schreef Jonas Maebe:

It won't keep it working but rather break it, since currently writing an extended to file on virtually all platforms writes a double to the file.

The majority of code has not been ported to non-x86. To obtain a healthy base of compilable code, non-x86 platforms should be compatible with x86 as much as possible, not the other way around.

Daniël

It should be compatible where reasonable, but it doesn't make sense to emulate all x86 peculiarities on non-x86. Otherwise e.g. "longint shl 32" also has to be emulated as "shl 0" on ppc (rather than setting the result to 0), all intermediate floating point calculations have to be performed using soft float 80 bit math and only the end result rounded back to 64/32 bit, etc.

I disagree that having "extended" bit compatible with the i386 is required to be able to port most code. Extended, like comp, is an x86- specific type and you only get approximate behaviour when using it on other architectures (in case of comp the difference is at compile time, due to comp being an integer rather than a floating point type on non-i386).

Jonas

It's probably better to directly introduce a longdouble type with longdouble (128 bit) semantics on all platforms. I don't think that emulating the almost nowhere supported 80 bit type does much good.

Is 128 bit supported by any hardware ? 80 bit is and it's an IEEE standard format. So I can't imagine why it is "nowhere supported"

-Michael

Most hardware only directly supports up to 64 bit precision.

80 bit is and it's an IEEE standard format.

It's a fuzzy standard. The IEEE "double-extended precision" is only defined as ">= 79 bit", similarly to how "single-extended precision" is defined as ">= 43 bit".

So I can't imagine why it is "nowhere supported"

Because the x86 is pretty much the only one to support it in hardware. Similarly, the m68k supported a 96 bit double-extended type which is supported (almost?) nowhere else, and it's just as IEEE standard as the x86's 80 bit floating point format. It just doesn't make sense to emulate such cpu-specific types on other platforms.

Jonas

> No. This was MMX. SSE is always separate. > How does an old OS that does not know about SSE do the task switch ?

It doesn't. You can't use SSE on e.g. unpatched Win95 or WinNT.

Always storing the FPU simply increases task switch time. Further, SSE is simply faster with 64 bit because of the easier to use register file and because more registers are available on 64 Bit CPUs.

No. This was MMX. SSE is always separate.

How does an old OS that does not know about SSE do the task switch ?

No, it's cutting of old hindering stuff.

If doing Mathematical calculations it of course is best to use the format that offers the best accuracy when it's not slower. AFAIK the FPU is not slower when doing 80 bit than when doing 64 bit (of course loading/storing the values might take some additional cycles). So using 80 seems like a very sensible option with the given X86 hardware (all versions do support 80 bits).

-Michael

For the record: at least Sparc supports 128 Bit.

Always storing the FPU simply increases task switch time. Further, SSE is simply faster with 64 bit because of the easier to use register file and because more registers are available on 64 Bit CPUs.

That does make sense !

Does the FPU share these 64 bit registers with the 64 bit integer unit ?

-Michael

Op Thu, 4 Oct 2007, schreef Florian Klaempfl:

Actually this is the whole core of the matter: Microsoft's developers though they could save the task switch time by not storing the fpu.

However, later they discovered it was a huge security leak, and added the fpu store code.

Daniël

> So I can't imagine why it is "nowhere supported" Because the x86 is pretty much the only one to support it in hardware.

Supposedly this counts for 90% of the FPUs produced in 2007...

OK. things do change.

-Michael

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For what it's worth, it's not just Microsoft who says x87 is deprecated under 64bit:

http://developer.amd.com/articles.jsp?id=9&num=4

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFHBO0XtgfmGfGfuPARAsfIAJwNdcoopi0UqTzdHxF8G4TvcHyabwCfaLV8 6gTaxhhH5tw3gjhHqPAZTMs=
=P8vn
-----END PGP SIGNATURE-----