[fpc-devel] -i and -Cp
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Tue Oct 30 19:35:16 CET 2012
Tomas Hajny wrote:
> On Wed, October 17, 2012 16:25, Pierre Free Pascal wrote:
>> You are right:
>> muller at deluxe:~/pas/test$ ppcsparc hello
>> muller at deluxe:~/pas/test$ ppcsparc hello -CpXX
>> Error: Illegal parameter: -CpXX
>> muller at deluxe:~/pas/test$ ppcsparc hello -Cp"sparc v7"
>> muller at deluxe:~/pas/test$ ppcsparc hello -Cp"sparc v8"
>> muller at deluxe:~/pas/test$ ppcsparc hello -Cp"sparc v9"
>> muller at deluxe:~/pas/test$ ppcsparc hello -Cp"sparc v19"
>> Error: Illegal parameter: -Cpsparc v19
>> But I didn't find any use of cputype current_settings field
>> in compiler/sparc directory sources,
>> so the generated result should not change...
> If the field/value isn't used yet, wouldn't it make sense to change the
> texts so that they use an underscore instead of space? I believe that it
> makes life easier for everyone and helps to avoid similar questions in the
> future. It seems that GCC uses just v7/v8/v9 (without "SPARC") so that the
> space doesn't seem to come from an attempt for alignment with GCC or
> something like that.
> Regarding Marks attempt - if I understand it correctly (based on
> information in Wikipedia ;-) ), Sparc v7 supports no HW multiplication /
> division. So a simple check may be to write a one liner containing
> multiplication, compiling it with any ppcsparc (or ppccrosssparc) while
> using the -s parameter and then checking the generated assembly for use of
> the mul/div asm instructions...
I've now got a SPARC V7 system running Solaris v7 for test purposes,
loaded with GCC, GNU binutils and so on. A C program compiled using gcc
with default options on either Solaris v7 or v8 is reported by file as
ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
A Pascal program including a multiplication compiled on a Solaris v8
system has a umul opcode. If I run the assembly/linkage on a v7 system,
irrespective of whether I've left the umul in place and of gas's -A
parameter, I get a .o described as
ELF 32-bit MSB relocatable SPARC Version 1
but after linkage the executable is
ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required,
dynamically linked, stripped
I presume that what's happening is that the version requirements from
system.o are propagating, otherwise I'd be interested in anybody's
comments. The result of this is that I don't think I can build a test
program that will run on a SPARC V7 without a whole lot of messing
around cross-building the RTL, and without doing that I can't find out
whether the OS is trapping and emulating the hardware multiply and
divide instructions. And I'm not sure it's worth the time and effort.
An interesting twist is that if I try to run an inappropriate program on
Solaris v7 using Bash I get
bash: ./product_pas_8: cannot execute binary file
while if I use the default shell (Ksh?) I get
./product_pas_8: syntax error at line 1: `(' unexpected
Somebody's recently reported seeing something similar on a MIPS-based
OpenWRT when he fed it a questionable binary.
My own feeling is that SPARC V7 should be dropped as a potential target.
There is probably a handful of surviving machines in operation, and even
the LEON design for implementation on an FPGA is V8.
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-devel