Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2015-01

Binary code generated for Integer and PtrInt

6 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Juha Manninen

Does it make sense to use PtrInt instead of Integer for optimization or code size reasons?
In other words, does the compiler generate faster or smaller code in 64-bit CPUs for the native integer size?
Does it depend on architecture?

Regards,
Juha

Reply by email

Florian Klämpfl
to Juha Manninen
Juha Manninen wrote
Does it make sense to use PtrInt instead of Integer for optimization or code size reasons?

Hard to say, but I wouldn't expect a benefit because bigger data types means also more cache pollution.

In other words, does the compiler generate faster or smaller code in 64-bit CPUs for the native integer size?

Normally the code is a little bit smaller (less sign extensions), but the data footprint is bigger.

Does it depend on architecture?

The comments above are probably valid for all 64 bit CPUs except alpha which is not supported by fpc.

Reply by email

Jonas Maebe
to Florian Klämpfl
Florian Klämpfl wrote 13 lines
Am 02.01.2015 um 19:31 schrieb Juha Manninen: > Does it make sense to use PtrInt instead of Integer for optimization or code size reasons? Hard to say, but I wouldn't expect a benefit because bigger data types means also more cache pollution. > In other words, does the compiler generate faster or smaller code in 64-bit CPUs for the native > integer size? Normally the code is a little bit smaller (less sign extensions), but the data footprint is bigger. > Does it depend on architecture? The comments above are probably valid for all 64 bit CPUs except alpha which is not supported by fpc.

And except for AArch64, where 32 bit will, in principle, also be more efficient than 64 bit in all cases. It can even use the lower 8/16/32 bit of a register as index in a memory references and sign/zero-extend + optionally multiply it with the access size.

Jonas

Reply by email

Florian Klämpfl
to Jonas Maebe
Jonas Maebe wrote 19 lines
On 02/01/15 21:16, Florian Klämpfl wrote: > Am 02.01.2015 um 19:31 schrieb Juha Manninen: >> Does it make sense to use PtrInt instead of Integer for optimization or code size reasons? > > Hard to say, but I wouldn't expect a benefit because bigger data types means also more cache pollution. > >> In other words, does the compiler generate faster or smaller code in 64-bit CPUs for the native >> integer size? > > Normally the code is a little bit smaller (less sign extensions), but the data footprint is bigger. > >> Does it depend on architecture? > > The comments above are probably valid for all 64 bit CPUs except alpha which is not supported by fpc. And except for AArch64, where 32 bit will, in principle, also be more efficient than 64 bit in all cases. It can even use the lower 8/16/32 bit of a register as index in a memory references and sign/zero-extend + optionally multiply it with the access size.

But integer operations are done always on 64 bit in FPC?

Reply by email

Jonas Maebe
to Florian Klämpfl
Florian Klämpfl wrote 6 lines
Am 02.01.2015 um 21:34 schrieb Jonas Maebe: > > And except for AArch64, where 32 bit will, in principle, also be more > > efficient than 64 bit in all cases. It can even use the lower 8/16/32 > > bit of a register as index in a memory references and sign/zero-extend + > > optionally multiply it with the access size. But integer operations are done always on 64 bit in FPC?

If you have

var
  l: longint;
  a: array of word;
begin
  a[l]:= ...
end

then the index will still be a longint.

Jonas

Reply by email

Florian Klämpfl
to Jonas Maebe
Jonas Maebe wrote 19 lines
On 02/01/15 22:12, Florian Klämpfl wrote: > Am 02.01.2015 um 21:34 schrieb Jonas Maebe: >>> And except for AArch64, where 32 bit will, in principle, also be more >>> efficient than 64 bit in all cases. It can even use the lower 8/16/32 >>> bit of a register as index in a memory references and sign/zero-extend + >>> optionally multiply it with the access size. > But integer operations are done always on 64 bit in FPC? If you have var l: longint; a: array of word; begin a[l]:= ... end then the index will still be a longint.

True, so even less reasons to use PtrInt.

Reply by email