FPC for SPARC v7

[praetor]

Howdy y'all!

So, as some of you know I'm working on and SGI IRIX port, but I figured I'd learn how to cross compile and tweak on a known platform where there are already all the bits, so I chose Solaris because I think it would be cool to have a pascal compiler on my little Sun IPX. But the problem is the IPX has a SPARCv7 CPU and FPC generates 8+ binaries. I'm kinda invested in this project and have learned SO MUCH, but how do I get the compiler to shoot out a v7 binary?

Thanks!

[MarkMLl]

Oh crap. Can you give us a quick reminder of what's what as far as architecture variants are concerned?

I had one of those and replaced its battery etc. circa (finger-in-wind guess) 2012, but I think I found that I couldn't get anything approaching a recent Linux on it let alone the system libraries etc. that would allow FPC to run... that would have been around FPC 2.7.1 which as verified by PascalDragon a few days ago should equate to 3.0.0.

I'm pretty sure I discussed this on the fpc-devel mailing list, and that Jonas highlighted a couple of opcodes that FPC really required and that the CPU in the IPX lacked.

I /think/ I had FPC running on e.g. SPARCstation 20 and SPARCserver 1000 both with some version of Linux... possibly only kernel 2.0 in the case of the SS1000 since the bus initialisation was fouled up: I got flamed by Dave Miller who didn't like my interim fix, and I never really got to grips with later versions.

I definitely had FPC circa 2.7.1 running on various later systems: those were the ones with a 64-bit Linux kernel but 32-bit userland. I can't remember where I got to with pukka SunOS/Solaris, at least one copy of that self-destructed on me which made me suspect that Oracle had intentionally put a timebomb in their "free" versions.

I also has it running on OpenSXCE which was pretty good, but that project imploded since the developer was in the Eastern Ukraine and the whole thing turned political after Russia's invasion and occupation of the Crimea.

I've got a small server here, but since Debian's support for both 32- and 64-bit SPARC ground to a halt I haven't a clue what OS I've got on it or what OS I could put on it: my recollection is that in the past I've concluded that Debian "Lenny" was rather a sweet spot in terms of robust support for "minority" architectures with reliability tailing off either side.

That's really the best I can do for the moment. I suggest looking through the fpc-devel and possibly Lazarus ML archives for relevant postings.

MarkMLl

[Handoko]

But the problem is the IPX has a SPARCv7 CPU and FPC generates 8+ binaries. I'm kinda invested in this project and have learned SO MUCH, but how do I get the compiler to shoot out a v7 binary?

Not sure but maybe this can help.

I didn't prepare the cross compiler for Solaris SPARC target. But on my Lazarus I can choose the compiler option for SPARC V7 and reveal the command line parameters:

-Tsolaris -Psparc -CpSPARC V7

[MarkMLl]

I didn't prepare the cross compiler for Solaris SPARC target. But on my Lazarus I can choose the compiler option for SPARC V7 and reveal the command line parameters:

-Tsolaris -Psparc -CpSPARC V7

Certainly worth trying, since that might be something that got into the compiler after I had that particular system.

MarkMLl

[marcov]

A commandline option with a space in it is doubtful. If you have a sparc crosscompiler, fpc -i should give you a list of available CPU options

[AlexTP]

Code: Pascal  [Select][+][-]

1.   { possible supported processors for this target }
2.   tcputype=(cpu_none,
3.     cpu_SPARC_V7,
4.     cpu_SPARC_V8,
5.     cpu_SPARC_V9
6.   );
7.  

[Handoko]

A commandline option with a space in it is doubtful.

I think so too. But that was what Lazarus showed me.

[JuhaManninen]

Target processors for SPARC CPU are now added in procedure GetTargetProcessors() in CodeTools like:

Code: Pascal  [Select][+][-]

1.   procedure Sparc;
2.   begin
3.     aList.Add('SPARC V7');
4.     aList.Add('SPARC V8');
5.     aList.Add('SPARC V9');
6.   end;

Should there be an underscore '_' instead of a space?

[MarkMLl]

https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg27286.html

appears relevant, circa 2012. Specifically:

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

What I had turns out to be an IPC not an IPX with SunOS running on it, and the ML consensus was that v8 support was worth having because that's what Qemu etc. provided, but not earlier. Not really sure where things went from there. Also

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

This was apparently in the 2.6.1 era.

MarkMLl

[ccrause]

Target processors for SPARC CPU are now added in procedure GetTargetProcessors() in CodeTools like:

Code: Pascal  [Select][+][-]

1.   procedure Sparc;
2.   begin
3.     aList.Add('SPARC V7');
4.     aList.Add('SPARC V8');
5.     aList.Add('SPARC V9');
6.   end;

Should there be an underscore '_' instead of a space?

The space was removed with this commit, about 9 years ago.  Since at least FPC 3.0.0 the name is written without a space on the compiler's side (from compiler/sparc/cpuinfo.pas):

Code: Pascal  [Select][+][-]

1.    cputypestr : array[tcputype] of string[10] = ('',
2.      'SPARCV7',
3.      'SPARCV8',
4.      'SPARCV9'
5.    );

[praetor]

Thank you gentlemen, ladies, them/theys! This is helpful as usual. I'll muck around with the Makefile (which I should probably learn to muck around with for my Irix port)

I think if I add a new target and give it the -Tsolaris -Psparc -CpSPARCV7 build options, we might just get there. Good opportunity to learn how to make new targets,

Thanks! 

[praetor]

I love having a beastly HP Zbook to do this on. My time to failure is less 

Doing this:
make all CPU_TARGET=sparc OS_TARGET=solaris CROSSBINUTILPREFIX="sparc-solaris" CROSSOPT="-CpSPARCV7"

Yields this:
/home/wfisher/Downloads/fpc-3.2.2/rtl/units/sparc-solaris/system.s:55918: Error: Architecture mismatch on "sdiv %o0,%o2,%o0".
/home/wfisher/Downloads/fpc-3.2.2/rtl/units/sparc-solaris/system.s:55918: (Requires v8|leon|sparclet|sparclite|v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is v7.)

Which is probably because the v7 lacks DIV and MUL instructions as a few of y'all have said. I'll have to do some more research, unless y'all have any ideas. Assembler is one of those languages I have ALWAYS struggled with. I'm fluent with Pascal and C, but Assembler escapes me.

[MarkMLl]

This is a long shot: does SunOS provide emulation traps for those opcodes, in the same way that it can trap and fix alignment errors (with dire performance penalty)?

If so, what needs to be done to the execution environment to enable it?

MarkMLl

[praetor]

The V7 has an operation for step multiplication. I would think it would be pretty trivial to add that into the sparc compiler. I don't know how to do that....yet....because like I said, assembler escapes me.

Assembler
Syntax: mulscc regrs1, reg_or_imm, regrd
Description: The multiply step instruction can be used to generate the 64-bit product of two signed or unsigned
words.

[JuhaManninen]

The space was removed with this commit, about 9 years ago.

I removed the spaces in ae6d20b6a4. Please test.