When -i returns lines with spaces, e.g.

Supported CPU instruction sets:
SPARC V7
SPARC V8
SPARC V9

what is the correct form to use for the -Cp option? For the toplevel makefile I've already got make GDB_V607=1 OPT='-O- -gl -vt' all and I presume that what I need is something like

make GDB_V607=1 OPT='-O- -gl -vt "-CpSPARC V7"' all

but I'd appreciate confirmation: I'm just about to run a slow compilation to see whether FPC will work on a very small Solaris 7 (SunOS 5.7) system and I'd rather not have to wait a day to discover I've got an option wrong. Just pushing the limit out of curiosity...

You are right:
ppcsparc hello
ppcsparc hello -CpXX
Error: Illegal parameter: -CpXX
ppcsparc hello -Cp"sparc v7"
ppcsparc hello -Cp"sparc v8"
ppcsparc hello -Cp"sparc v9"
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...

Pierre

PS: Trunk for sparc is currently broken (I added some checks related to nostackframe modifier, ad
some CPU do not conform to the idea that
the stacksize should be zero in that case...)

colleagues]

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

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...

Tomas

(Subject to Tomas's comment) both -Cp'SPARC v9' and '-CpSPARC v9' appear to be accepted by the compiler. I suspect that the latter might be better practice from the POV of the shell.

PS: Trunk for sparc is currently broken (I added some checks related to nostackframe modifier, ad some CPU do not conform to the idea that the stacksize should be zero in that case...)

Thanks, noted. Yell when you want me to test something.

Or at least accepting just v8/v9 where there is no ambiguity. I note that some FPU designations already have underscores.

I'll take a look. However I stress that I've got absolutely nothing invested in SPARC v7 (AKA sun4c) and only marginal interest in Solaris 7, so allowing that even the LEON processor supports v8 (as do sun4m and sun4d) I think v7 could be quietly dropped.

Using this test input:

program test789;
const	a= 3;
var	b, c: integer;
begin
   b := 5;
   c := b * a
end.

Output (test789.s) files are identical containing

# [9] c := b * a
sethi %hi(U_P$TEST7_B),%o0
ldsh [%lo(U_P$TEST7_B)+%o0],%o0
smul %o0,3,%o0

I agree that smul is new to v8, but I don't know to what extent OSes on older chips would emulate it (the v8 manual suggests this as a possibility).

In any event, the -Cp parameter doesn't appear to be being carried through to the ELF info generated by ld, in all cases it reports

ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), statically linked, stripped

which is probably inappropriate in the case of v7. Hmm. On a Solaris 8 system I notice

/usr/local/bin/gld: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped

while FPC compiled on the same machine is described as

/usr/local/bin/fpc: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped

This should now be fixed...
If you have time to test it, it would be great.

Pierre

colleagues]

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

It's able to build and install itself, I note that the build was slightly faster than 2.6.1. I'll run the test suite and compare against 2.6 but for various reasons I don't want to do that on my main system. Anything specific you want me to look at?

If anybody's interested I've got test results for 2.7.1 and 2.6.0, but I'm having difficulty comparing them i.e. looking for things broken in one but not the other. If somebody wants them either by mail or dumped into e.g. pastebin please say.

In our previous episode, Mark Morgan Lloyd said:

There are also a bunch of not merged (to proto 2.6.2) RTL fixes atm:

http://www.stack.nl/~marcov/mergelogs26/sparc.txt

You could try to compare the "faillist" file of each version though 2.7.1 could potentially contain failures for tests that didn't exist in 2.6.0 (e.g. most of the tests/test/tgeneric*.pp tests).

Regards,
Sven

Ah- I was trying to filter the log and getting into trouble due to timestamps. However I'm seeing both reports of failures in 2.6.0 that aren't in 2.7.1 and vice versa:

$ wc -l fail*
55 faillist-2.6.0
44 faillist-2.7.1

$ diff -y faillist-2.6.0 faillist-2.7.1 |head
test/cg/taddbool | test/cg/tcalcst6 test/cg/tcalext5 test/cg/tcalext5 test/cg/tcalext6 | test/cg/tcalvar6 test/cg/tcppcl1 | test/packages/bzip2/tbzip2streamtest test/cg/tcppcl2 <
test/packages/webtbs/tw10045 <
test/packages/webtbs/tw14265 test/packages/webtbs/tw14265

test/tcpstr2a

test/tdel1 test/tdel1 test/tdel2 test/tdel2 ..

and so on.

I'll have another session over the weekend with a fresh 2.6.1 against trunk, but when I was running the tests today they did some odd things to my desktop system (e.g. changing the TZ offset abruptly which might have messed up their own makefiles) that makes me happier running on something else- and the "something else" in this case is about to be rebuilt because of other issues.

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.

In our previous episode, Mark Morgan Lloyd said:

On Linux afaik that points to a wrong dynamic loader, on *BSD to a missing ELF ident section (since that is how most BSDs link binary to dynamic linker)

Using elfdump -n might reveal which programs have an elf ident section.

(and objdump has some options to view elf headers, and objdump -D can be used to find the section's content)

I'll see if I can dig a copy of elfdump out later, but I seriously feel that v7 (both SPARC and Solaris) is too old to take any trouble over. On the other hand, v8 probably is worth trying to keep alive since it includes big machines like the Xerox/Cray servers (FPC tells gas to assume v9, but I'm not sure it really means it).

I've raised the original -i etc. issue as
http://mantis.freepascal.org/view.php?id=23250