Compile anywhere ?

[dbannon]

So, Lazarus and FPC, compile anywhere ?

The Debian people contacted me to tell be that my app, tomboy-ng, was not compiling on PowerPC64el (they mean ~le).  No, said I, PowerPC64 is a server chip, you find it in serious IBM (and others) hardware that is not made for Desktop use.

"But we like to try ..." - so, I tried, it took serious time to install a PSeries machine as a QEMU client and its sure not fast but one edit to my build scripts and my app runs on ppc64el. I thought it worth a post on a forum that is usually dominated with "not working" content !

The one edit ?  Power does not seem to like the Intel Hardening switches to FPC...

Thanks folks, you sure are doing a great job !

Davo

 

[PascalDragon]

The Debian people contacted me to tell be that my app, tomboy-ng, was not compiling on PowerPC64el (they mean ~le).  No, said I, PowerPC64 is a server chip, you find it in serious IBM (and others) hardware that is not made for Desktop use.

So you don't know about the Raptor TALOS for example? (yes, it's a much higher prize tier than an x86, but nevertheless it's intended for a workstation)

And if I hadn't slept a few years ago I could have bought myself a refurbished 80 core Power8 server for ~200 €

[dbannon]

..... you find it in serious IBM (and others) hardware that is not made for Desktop use.

So you don't know about the Raptor TALOS for example? (yes, it's a much higher prize tier than an x86, but nevertheless it's intended for a workstation)

OK, well, Raptor uses can now run a FPC/Lazarus app, a bit of free software will help given their price point !

And if I hadn't slept a few years ago I could have bought myself a refurbished 80 core Power8 server for ~200 €

And a excellent room heater it would make too.

I had, at one stage, both a Bluegen/L and  BlueGen/P https://en.wikipedia.org/wiki/IBM_Blue_Gene under my care, there are quite a few Power chips in those babies I can assure you.  And a couple of other clusters of more conventional POWER chips too. My experience is there is nothing quite so valueless as a second hand supercomputer !

David

[MarkMLl]

The Debian people contacted me to tell be that my app, tomboy-ng, was not compiling on PowerPC64el (they mean ~le).  No, said I, PowerPC64 is a server chip, you find it in serious IBM (and others) hardware that is not made for Desktop use.

I certainly had FPC (and I think Lazarus) working on a PPC based Mac without significant problems until comparatively recently... there might have been a problem with one of the smart linking options.

SPARC similarly ran fine, subject to an alignment bug invoking lhelp... there's a patch for that on Mantis.

Now obviously the 64-bit variants are a different matter, but as long as the enthusiasm and investment are there from the OS people (which bodes ill for SPARC, Hurd and so on) worth trying.

MarkMLl

[dbannon]

SPARC similarly ran fine, subject to an alignment bug invoking lhelp... there's a patch for that on Mantis.

I wonder if you have that patch bookmarked Mark, there is still a problem building lhelp on ppc64el too, might be the same thing ?

..... (which bodes ill for SPARC, Hurd and so on) worth trying.

Indeed, even Debian now have SPARC as only "a port".  Was once such a big player .....

Davo

[MarkMLl]

SPARC similarly ran fine, subject to an alignment bug invoking lhelp... there's a patch for that on Mantis.

I wonder if you have that patch bookmarked Mark, there is still a problem building lhelp on ppc64el too, might be the same thing ?

Sorry, Mantis has gone and I've neither the time nor the inclination to mess around with Git. However this was specifically a problem invoking lhelp on SPARC and possibly ARM (at the time), which I was only able to work around by moving (a pointer?) rather than assigning it, and TPTB decided it was too hackish and they'd prefer it to crash.

..... (which bodes ill for SPARC, Hurd and so on) worth trying.

Indeed, even Debian now have SPARC as only "a port".  Was once such a big player .....

The way I look at it, there's two fundamental architectures: the orthogonal register file model that came in with the IBM360 and the non-orthogonal one that preceded it. SPARC was firmly in the second camp, as was Itanium and the ESP32 chip. 32-bit x86 was moderately in the second camp, but the 64-bit modifications moved it towards the orthogonal approach.

So the porters tried valiantly with SPARC, but ultimately they were stymied far more by lack of interest on the part of the hardware vendors than by technical problems (even allowing for some of the quirks of the Forth-based boot ROMs). However things like https://hackaday.com/2009/10/23/sparkfun-gets-a-cease-and-desist/ can't have helped.

I've had Solaris/SunOS 10(?) running on a SPARC workstation, but it self-destructed after suspiciously-close to a year's intermittent operation. I've also had a port of the "open" Solaris release running (OpenSXCE?) but the developer was a Russian in Eastern Ukraine and the project and online discussion... degenerated.

The bottom line however is that from the user's and OS-installer's POV there was very little difference between x86 and SPARC/PPC/ARM etc. This gives me some hope for e.g. RISC-V in the future, provided that it holds its critical mass together.

MarkMLl

[PascalDragon]

SPARC similarly ran fine, subject to an alignment bug invoking lhelp... there's a patch for that on Mantis.

I wonder if you have that patch bookmarked Mark, there is still a problem building lhelp on ppc64el too, might be the same thing ?

Sorry, Mantis has gone and I've neither the time nor the inclination to mess around with Git. However this was specifically a problem invoking lhelp on SPARC and possibly ARM (at the time), which I was only able to work around by moving (a pointer?) rather than assigning it, and TPTB decided it was too hackish and they'd prefer it to crash.

Redirects from the old URLs to GitLab are in place, so if you know the bug ID you could provide dbannon with a link so that they can take a look at it.

[MarkMLl]

Redirects from the old URLs to GitLab are in place, so if you know the bug ID you could provide dbannon with a link so that they can take a look at it.

Thanks for that, and I assure you that I appreciate the work somebody's put in getting that going.

Via Google I get to https://lists.lazarus-ide.org/pipermail/lazarus/2012-August/205816.html i.e. issues 22696 and 22697.

I'm sure that anybody with an interest knows this, but I'll repeat it just in case. Leaving aside for the moment that some implementations of any given architecture are tolerant of misalignment and some are not, my experience at the time was that it also depended on the OS. As a specific example, Linux SPARC would raise an application-level exception if there was a misalignment but Solaris/SunOS SPARC wouldn't, however the internal exception handler which sorted out the problem was notoriously slow so couldn't really be considered a viable solution.

Apart from that, at the time I think the Lazarus IDE ran well on Linux SPARC, PPC and ARM (this predated the RPI's ARMhf though). I can't remember where anybody got to with MIPS... FPC certainly ran on Linux MIPS but most of the discussion IIRC focussed on things like OpenWRT library issues. I think I had the IDE running on at least one Solaris SPARC version, but can't remember which... probably OpenSXCE which I think still used gtk v1.

MarkMLl

[dbannon]

Thanks Mark, no, does not look like the same issue, on ppc64el, it shows up at compile time. 

I will chase it up at some stage but have had to put a freeze on VMs until I install a new hard disk.

Davo

[PascalDragon]

I'm sure that anybody with an interest knows this, but I'll repeat it just in case. Leaving aside for the moment that some implementations of any given architecture are tolerant of misalignment and some are not, my experience at the time was that it also depended on the OS. As a specific example, Linux SPARC would raise an application-level exception if there was a misalignment but Solaris/SunOS SPARC wouldn't, however the internal exception handler which sorted out the problem was notoriously slow so couldn't really be considered a viable solution.

Fun fact: on Aarch64 it's up to the OS whether misalignment exceptions are enabled or not: whether the CPU triggers an exception upon a misaligned data access (that isn't part of an exclusive store/release) is controlled by a flag in the MMU registers (e.g. SCTLR_EL1).

[MarkMLl]

Fun fact: on Aarch64 it's up to the OS whether misalignment exceptions are enabled or not: whether the CPU triggers an exception upon a misaligned data access (that isn't part of an exclusive store/release) is controlled by a flag in the MMU registers (e.g. SCTLR_EL1).

TFT, makes sense in view of the presumably small amount of hardware it would take.

Is that per-process or global?

MarkMLl

[PascalDragon]

Is that per-process or global?

Global. More precisely: per execution level (aka the privilege). A hypervisor could have a different setting from an OS running in that hypervisor..

[MarkMLl]

Is that per-process or global?

Global. More precisely: per execution level (aka the privilege). A hypervisor could have a different setting from an OS running in that hypervisor..

Roger, TFT.

MarkMLl

[dbannon]

Getting back to the powerpc64 issue, it happens while compiling lhelp and seems to be an assembler issue.

FPC creates a file, lib/powerpc64-linux/basecontentprovider.s, presumbly while compiling basecontentprovider.pas and then points the assembler at it. The assembler says -

Code: [Select]

lib/powerpc64-linux/basecontentprovider.s: Assembler messages:
lib/powerpc64-linux/basecontentprovider.s:1112: Error: can't resolve `.text.n_basecontentprovider_$$_geturiprefix$ansistring$$ansistring' {.text.n_basecontentprovider_$$_geturiprefix$ansistring$$ansistring section} - `.BASECONTENTPROVIDER_$$_GETURIPREFIX$ANSISTRING$$ANSISTRING' {*UND* section}
And repeats that for a lot of lines in basecontentprovider.s.  Now, that is something that normally all "just happens" out of my sight so, anyone with inside knowledge of assembly code (on a powerpc64 but sounds like a pretty generic issue) ?

While linux on powerPC is not officially a Lazarus supported platform, this seems the only reason why its not. I have tested compile of my app (20K lines) and run the GUI all good as long as you don't try to compile lhelp.  So, be cool to get it going ....

Davo