The SPARC port required just a few trivial clean up commits and one straightforward change to support NetBSD ucontext_t (different names) to get built on NetBSD/sparc. Haven't tried GUI yet, but the basic world seems to build.
https://github.com/nbuwe/self/commits/feature/netbsd-sparc
There is just one serious issue - in the intervening years the SPARC ABI reserved %g7 for system use and it's currently used for thread-local storage block pointer. The default malloc implementation on NetBSD always uses TLS, so it relies on that %g7 not being clobbered. The self compiler uses %g7 for the stack limit (SPLimitReg). I'm currently cheating by using a libc with a different, more simple malloc implementation that doesn't use TLS. The compiler needs to be modified to move SPLimitReg to a different register at the cost of losing one temp, I guess.
-uwe
I'll pull in what you've done. What are you running this on? You seem to have a proper collection - I'm jealous Russell
On Tue, 4 Apr 2023, at 9:07 PM, Valery Ushakov wrote:
The SPARC port required just a few trivial clean up commits and one straightforward change to support NetBSD ucontext_t (different names) to get built on NetBSD/sparc. Haven't tried GUI yet, but the basic world seems to build.
https://github.com/nbuwe/self/commits/feature/netbsd-sparc
There is just one serious issue - in the intervening years the SPARC ABI reserved %g7 for system use and it's currently used for thread-local storage block pointer. The default malloc implementation on NetBSD always uses TLS, so it relies on that %g7 not being clobbered. The self compiler uses %g7 for the stack limit (SPLimitReg). I'm currently cheating by using a libc with a different, more simple malloc implementation that doesn't use TLS. The compiler needs to be modified to move SPLimitReg to a different register at the cost of losing one temp, I guess.
-uwe _______________________________________________ Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
On Thu, Apr 06, 2023 at 11:19:27 +1000, Russell Allen wrote:
I'll pull in what you've done.
Should I create a PR on github?
What are you running this on? You seem to have a proper collection
- I'm jealous
This one is under qemu primarily. qemu has its issues, but it's mostly ok.
I do have real sparc gear, but it's diskless JavaStations, so building anything with modern c++ (*cough* hogs *cough*) compilers in 64MB memory and (slow) NFS root/swap is ... slow.
On Krups (100Mhz) with slow nfs, -g build, ~nothing is inlined
echo _Quit | Self
takes about 4.5s
echo _Quit | Self -s Snapshot
takes about 80s, though it spends some of that time complaining about missing x11Globals (-o none snapshot).
On Tue, 4 Apr 2023, at 9:07 PM, Valery Ushakov wrote:
The SPARC port required just a few trivial clean up commits and one straightforward change to support NetBSD ucontext_t (different names) to get built on NetBSD/sparc. Haven't tried GUI yet, but the basic world seems to build.
https://github.com/nbuwe/self/commits/feature/netbsd-sparc
There is just one serious issue - in the intervening years the SPARC ABI reserved %g7 for system use and it's currently used for thread-local storage block pointer. The default malloc implementation on NetBSD always uses TLS, so it relies on that %g7 not being clobbered. The self compiler uses %g7 for the stack limit (SPLimitReg). I'm currently cheating by using a libc with a different, more simple malloc implementation that doesn't use TLS. The compiler needs to be modified to move SPLimitReg to a different register at the cost of losing one temp, I guess.
-uwe
-uwe
On Thu, 6 Apr 2023, at 12:55 PM, Valery Ushakov wrote:
On Thu, Apr 06, 2023 at 11:19:27 +1000, Russell Allen wrote:
I'll pull in what you've done.
Should I create a PR on github?
Yes please
What are you running this on? You seem to have a proper collection
- I'm jealous
This one is under qemu primarily. qemu has its issues, but it's mostly ok.
I'll try to add Sparc to my build script
I do have real sparc gear, but it's diskless JavaStations, so building anything with modern c++ (*cough* hogs *cough*) compilers in 64MB memory and (slow) NFS root/swap is ... slow.
On Krups (100Mhz) with slow nfs, -g build, ~nothing is inlined
echo _Quit | Self
takes about 4.5s
echo _Quit | Self -s Snapshot
takes about 80s, though it spends some of that time complaining about missing x11Globals (-o none snapshot).
It shouldn't be complaining, but admittedly I haven't properly worked on the non-X11 snapshot for ages. I should revisit it.
- Russell
On Tue, 4 Apr 2023, at 9:07 PM, Valery Ushakov wrote:
The SPARC port required just a few trivial clean up commits and one straightforward change to support NetBSD ucontext_t (different names) to get built on NetBSD/sparc. Haven't tried GUI yet, but the basic world seems to build.
https://github.com/nbuwe/self/commits/feature/netbsd-sparc
There is just one serious issue - in the intervening years the SPARC ABI reserved %g7 for system use and it's currently used for thread-local storage block pointer. The default malloc implementation on NetBSD always uses TLS, so it relies on that %g7 not being clobbered. The self compiler uses %g7 for the stack limit (SPLimitReg). I'm currently cheating by using a libc with a different, more simple malloc implementation that doesn't use TLS. The compiler needs to be modified to move SPLimitReg to a different register at the cost of losing one temp, I guess.
-uwe
-uwe _______________________________________________ Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
self-interest@lists.selflanguage.org
-
Russell Allen -
Valery Ushakov