Discussion:
[fpc-pascal] selecting target processor
Marc Santhoff
2005-06-19 18:48:52 UTC
Permalink
Hi,

how can I tell fpc to use only instructions supported on a specific
processor?

I'm compiling on an athlon for running on a geode (restriction has to
define instruction set from x686 to x586, I think).

Sometimes my program crashes on the target machine with signal 4
(illegal instruction).

TIA,
Marc
Jonas Maebe
2005-06-19 20:26:48 UTC
Permalink
Post by Marc Santhoff
how can I tell fpc to use only instructions supported on a specific
processor?
I'm compiling on an athlon for running on a geode (restriction has to
define instruction set from x686 to x586, I think).
In theory, the code generated by FPC should always run on an i386
(even if you use e.g. -Op3), unless you use some special command line
switches I cannot find in the help. Other behaviour indicates a bug.
Can you figure out which instruction it is that causes this?


Jonas
Florian Klaempfl
2005-06-19 20:49:44 UTC
Permalink
Post by Marc Santhoff
how can I tell fpc to use only instructions supported on a specific
processor?
I'm compiling on an athlon for running on a geode (restriction has to
define instruction set from x686 to x586, I think).
In theory, the code generated by FPC should always run on an i386 (even
if you use e.g. -Op3), unless you use some special command line
switches I cannot find in the help.
-C<x> code generation options:
-Cc<x> set default calling convention to <x>
-CD create also dynamic library (not supported)
-Ce Compilation with emulated floating point opcodes
-Cf<x> Select fpu instruction set to use, see fpc -i for
possible values
-Cg Generate PIC code
-Ch<n> <n> bytes heap (between 1023 and 67107840)
-Ci IO-checking
-Cn omit linking stage
-Co check overflow of integer operations
-Cp<x> select instruction set, see fpc -i for possible values

That is it :)
Other behaviour indicates a bug.
Can you figure out which instruction it is that causes this?
Jonas
_______________________________________________
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Tomas Hajny
2005-06-19 21:10:45 UTC
Permalink
Date sent: Sun, 19 Jun 2005 22:49:44 +0200
From: Florian Klaempfl <***@freepascal.org>
To: FPC-Pascal users discussions <fpc-***@lists.freepascal.org>
Subject: Re: [fpc-pascal] selecting target processor
Post by Florian Klaempfl
Post by Jonas Maebe
Post by Marc Santhoff
how can I tell fpc to use only instructions supported on a specific
processor?
I'm compiling on an athlon for running on a geode (restriction has
to define instruction set from x686 to x586, I think).
In theory, the code generated by FPC should always run on an i386
(even if you use e.g. -Op3), unless you use some special command
line switches I cannot find in the help.
-Cc<x> set default calling convention to <x>
-CD create also dynamic library (not supported)
-Ce Compilation with emulated floating point opcodes
-Cf<x> Select fpu instruction set to use, see fpc -i for
possible values
-Cg Generate PIC code
-Ch<n> <n> bytes heap (between 1023 and 67107840)
-Ci IO-checking
-Cn omit linking stage
-Co check overflow of integer operations
-Cp<x> select instruction set, see fpc -i for possible
values
That is it :)
Nice can of worms I haven't been aware of... ;-) So what is the best -
Cp option for my Athlon then? ;-))) And what would be correct for AMD
K6 and all other non-Intel CPUs > 386? Looks as a lot of work for
Michael...

Tomas
Florian Klaempfl
2005-06-19 21:19:43 UTC
Permalink
Post by Tomas Hajny
Date sent: Sun, 19 Jun 2005 22:49:44 +0200
Subject: Re: [fpc-pascal] selecting target processor
Post by Florian Klaempfl
Post by Jonas Maebe
Post by Marc Santhoff
how can I tell fpc to use only instructions supported on a specific
processor?
I'm compiling on an athlon for running on a geode (restriction has
to define instruction set from x686 to x586, I think).
In theory, the code generated by FPC should always run on an i386
(even if you use e.g. -Op3), unless you use some special command
line switches I cannot find in the help.
-Cc<x> set default calling convention to <x>
-CD create also dynamic library (not supported)
-Ce Compilation with emulated floating point opcodes
-Cf<x> Select fpu instruction set to use, see fpc -i for
possible values
-Cg Generate PIC code
-Ch<n> <n> bytes heap (between 1023 and 67107840)
-Ci IO-checking
-Cn omit linking stage
-Co check overflow of integer operations
-Cp<x> select instruction set, see fpc -i for possible
values
That is it :)
Nice can of worms I haven't been aware of... ;-) So what is the best -
Cp option for my Athlon then? ;-))) And what would be correct for AMD
K6 and all other non-Intel CPUs > 386? Looks as a lot of work for
Michael...
PENTIUM afaik nothing new
PENTIUM2 mainly cmov and fcmov, cmov creates nice code for
length(<ansistring>) or max if max is inlined:

# [14] i:=length(s);
movl U_P$PROGRAM_S,%eax
testl %eax,%eax
cmovnel -4(%eax),%eax
movl %eax,U_P$PROGRAM_I
# [15] j:=max(j,k);
movl U_P$PROGRAM_K,%ecx
movl U_P$PROGRAM_J,%edx
cmpl %ecx,%edx
cmovgl %edx,%eax
.L29:
cmovngl %ecx,%eax
movl %eax,U_P$PROGRAM_J


PENTIUM3 sse1 for usual code possible (e.g. prefetch)
PENTIUM4 sse2 for usual code possible

K6 -> Pentium
Athlon/Duron -> Pentium2
AthlonXP/Sempron -> Pentium3
Athlon64 -> Pentium4
Post by Tomas Hajny
Tomas
_______________________________________________
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Marc Santhoff
2005-06-20 07:59:56 UTC
Permalink
Post by Jonas Maebe
Post by Marc Santhoff
how can I tell fpc to use only instructions supported on a specific
processor?
I'm compiling on an athlon for running on a geode (restriction has to
define instruction set from x686 to x586, I think).
In theory, the code generated by FPC should always run on an i386
(even if you use e.g. -Op3), unless you use some special command line
switches I cannot find in the help. Other behaviour indicates a bug.
So it should work:

I'm using "-dRELEASE" for releasing and my fpg.cfg has standard "-OG2p3"
and "-Xs". Testing is done with "-XX -B".
Post by Jonas Maebe
Can you figure out which instruction it is that causes this?
How would I do that? Would a saved core dump do? It seems to occur on
when redirecting stdout to a file, but I'm not sure yet.

Thanks,
Marc
Jonas Maebe
2005-06-20 13:36:10 UTC
Permalink
Post by Marc Santhoff
I'm using "-dRELEASE" for releasing and my fpg.cfg has standard "-
OG2p3"
and "-Xs". Testing is done with "-XX -B".
Yes, it should.
Post by Marc Santhoff
Post by Jonas Maebe
Can you figure out which instruction it is that causes this?
How would I do that? Would a saved core dump do? It seems to occur on
when redirecting stdout to a file, but I'm not sure yet.
Normally, you'd do this by running the program under gdb and checking
what the faulting instruction is. A coredump should contain the
necessary information as well, yes.


Jonas
Eduardo
2005-06-20 15:19:51 UTC
Permalink
Post by Jonas Maebe
I'm using "-dRELEASE" for releasing and my fpg.cfg has standard "- OG2p3"
and "-Xs". Testing is done with "-XX -B".
Yes, it should.
Post by Jonas Maebe
Can you figure out which instruction it is that causes this?
How would I do that? Would a saved core dump do? It seems to occur on
when redirecting stdout to a file, but I'm not sure yet.
Normally, you'd do this by running the program under gdb and checking
what the faulting instruction is. A coredump should contain the
necessary information as well, yes.
Are you using any dll or lib.so :? Perhaps the external code is compiled
for a specific processor.


**************************************************************************************************************************************************
This document represent my ideas. They are original from me. It's forbidden
think the same than me, without previous payment.
If you agree me, PAY.
Marc Santhoff
2005-06-21 13:09:46 UTC
Permalink
Am Montag, den 20.06.2005, 17:19 +0200 schrieb Eduardo:
[...]
Post by Eduardo
Are you using any dll or lib.so :? Perhaps the external code is compiled
for a specific processor.
This in fact seems to be tha cause. The error happens inside the GTK
library which i'll try to recompile and check again.

Thanks to you all so far,
Marc

Loading...