On 30 Jan 2008, at 08:35, Michael Schnell wrote:
Yes, that is understable, because for example pointers are twice as
big, which results in more memory accesses and less pointers in the
CPU caches and more cache misses.
Is this a software design decision (to allow for large projects
using
Hi Folks,
here goes the summary of the story:
The task: compiling the same source in 32 and 64 bit environment using
FPC ver. 2.2.0 and compare the results. In ideal case the results should
be the same. I hit the several bugs during this test.
1) - the available 32-bit and 64-bit RPM
Miklos Cserzo schreef:
Hi Folks,
5) - considering the two versions of a source that will not hit this bug
the generated 32-bit executable runs much faster than its 64-bit
equivalent. That indicates the general weakness of the 64-bit platform
support.
Yes, that is understable, because
On 29 Jan 2008, at 17:25, Vincent Snijders wrote:
Miklos Cserzo schreef:
Hi Folks,
5) - considering the two versions of a source that will not hit
this bug the generated 32-bit executable runs much faster than its
64-bit equivalent. That indicates the general weakness of the 64-
bit
2) - when the concurrent installation of the two versions of the
complier is solved users can control the type of the generated binaries
by the '-P' switch of the complier. This switch is not mentioned in the
documentation at all.
Not in the formal user docs, but in bootstrapping and
Yes, that is understable, because for example pointers are twice as
big, which results in more memory accesses and less pointers in the
CPU caches and more cache misses.
Is this a software design decision (to allow for large projects using
4Gig Memory) or does the architecture not provide an
On 28 Jan 2008, at 17:00, Miklos Cserzo wrote:
Jonas Maebe wrote:
Try compiling with -Aas, because the internal assembler is quite
broken for x86_64 in 2.2.0.
That gives equivalent result as replacing the compact nested
reference of the array element with the several simple references,
Jonas Maebe wrote:
Try compiling with -Aas, because the internal assembler is quite broken
for x86_64 in 2.2.0.
That gives equivalent result as replacing the compact nested reference
of the array element with the several simple references, i.e. 'score'
cumulates non-zero values but the
Hi Folks,
I have a 32 bit system running openSUSE 10.3 with FPC 2.2.0 installed on
it. On the other system the 64 bit variants installed of the OS and the
compiler. I have a code that compiles and runs fine in the 32 bit
environment. The same code compiles on 64-bit but it hits a division by
On 25 Jan 2008, at 16:30, Miklos Cserzo wrote:
I guess the real problem is well before the critical line but I have
no idea where could it be and how to find it. Now I wonder, if the
same code supposed to compile and run in the same manner on 32 and
64 bit architecture? Is this sort of
10 matches
Mail list logo
