[fpc-devel] -i and -Cp

[Mark Morgan Lloyd]

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-3.2$ ./product_pas_8
bash: ./product_pas_8: cannot execute binary file

while if I use the default shell (Ksh?) I get

$ ./product_pas_8
./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]