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 >
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 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 platf
> 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 cr
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 for
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 distri
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 pro
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 ano
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
10 matches
Mail list logo
