It would be great if there is also ppc64le/power platform supported. — |
> On 2020-04-28, at 6:51 AM, kgardas <[hidden email]> wrote: > > > It would be great if there is also ppc64le/power platform supported. https://tenor.com/view/onemilliondollars-gif-4123675 tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim There can never be a computer language in which you cannot write a bad program. |
In reply to this post by David T Lewis
And which operating system? — |
In reply to this post by David T Lewis
This is per se a good idea. — |
In reply to this post by David T Lewis
However, maybe we could salvage some parts from Self? — |
In reply to this post by David T Lewis
If we ever manage to move the target-agnostic JIT over to OSTVM, that would give us PPC for free. As to the stack interpreter, it should work as is. I haven't tried with PPC (hmmm... would be a good idea) but last November at Smalltalks I tried on RISC-V 64-bit and it works fine (I demoed it on an Unleashed board) — |
In reply to this post by David T Lewis
Well, I'm on linux ppc64le here. When I tried to
it fails with:
Also it looks like build downloads some libraries (binaries) and they are AMD64 version instead of PPC64le:
So there is something to do on PPC64le support. For folks interested in POWER architecture development/porting, the most easy way to get access to actual hardware is GCC compile farm: https://cfarm.tetaneutral.net/ -- where people working on open-source/free-software may request account and access machines from the list. POWER is presented with both big and little endian and with power7, power8 and power9 CPUs hosts and with Linux and AIX. So the coverage is quite good... — |
In reply to this post by David T Lewis
I've also tested
but this still shows the problem above. — |
In reply to this post by David T Lewis
Sorry, this is not the build process used in this repo. I cannot really help with the problems you are presenting :/ — |
In reply to this post by David T Lewis
Tobias, indeed, I've completely messed up with this. Anyway, bear with me, testing this repo source code now. — |
In reply to this post by David T Lewis
Reading README reveals that there is obviously not build.linux64ppc64le directory with the required infrastructure. But most close is probably build.linux64x64 so I give a try to it to find out how far I can get. The first issue is that the project config.guess file is out-dated. Note, I'm using squeak.stack.spur as I've thought this is stack based VM without any JIT. Anyway, the output is here:
when I updated this file to recognize my platform, I've got this:
which looks like is caused by missing clang on my box, I've installed Ubuntu 18.04 LTS clang (6.0 version) and run again. Configure part complains with one error:
and compilation part fails with a lot of errors about VM_LABEL missing:
Anyway, I hope I've followed the right project and the right README here just to point few issues you probably already know about w.r.t. PPC64le platform support. Thanks! — |
In reply to this post by David T Lewis
Thanks, this puts things into perstpective. That config.guess is outdated might be the case, I have no Idea how that is cenerated. For the
as is done later in the file? — |
In reply to this post by David T Lewis
[see 5f07501 ] — |
In reply to this post by David T Lewis
On 29/04/20 2:14 am, kgardas wrote: > hich looks like is caused by missing clang on my box, I've installed > Ubuntu 18.04 LTS clang (6.0 version) and run again. Configure part > complains with one error: Perhaps you could try with gcc to check if it is the compiler choice that is triggering errors. See below > and compilation part fails with a lot of errors about VM_LABEL missing: > > |/home/karel/vcs/OpenSmalltalk/opensmalltalk-vm/spurstack64src/vm/gcc3x-interp.c:3054:5: > error: invalid symbol redefinition VM_LABEL(pushLiteralConstantBytecode2);| VM_LABEL macro definition in picked up from the file: ----- platforms/unix/vm/sqPlatformSpecific.h 108 #if defined(__GNUC__) 109 # if !defined(VM_LABEL) 110 # define VM_LABEL(foo) asm("\n.globl L" #foo "\nL" #foo ":") 111 # endif ----- How did the __GNUC__ get defined in your compilation? You could try passing -D'VM_LABEL(foo)=0' while compiling to work around this problem temporarily. Regards .. Subbu |
In reply to this post by David T Lewis
Thanks for the patch and for the hint. I used that and after some more or less horrible hacks I've got to compiling platform specific IA32abi plugin which is a mark that time for ppc64le specific build infrastructure is here. :-) My hacks so far including your advice is:
and the compile failure is:
— |
In reply to this post by David T Lewis
Yes. this is because of a plugin that is x86-specific Note that — |
In reply to this post by David T Lewis
Thanks, both of those removals were needed. Now I do have compiled VM in the tree. I've downloaded squeak image (5.3 latest), unzipped it, set SQUEAK_IMAGE to point to file and was able to start squeak. The UI complains about missing source file, but otherwise run -- as far as me as ST newbie can see... Thanks! — |
In reply to this post by David T Lewis
I've attempted to also start pharo8.0 image, but this complains (although run) with "Callout mechanism not available". It's probably a result of "GetPwdViaFFI" call as far as I can see and if this is FFI, then indeed, it may complain... — |
In reply to this post by David T Lewis
The sources file is here: http://files.squeak.org/sources_files/ (that is: http://files.squeak.org/sources_files/SqueakV50.sources.gz ) — |
In reply to this post by David T Lewis
That said, This is really cool! Can you post a screenshot of the about-squeak dialog on squeak-dev or vm-dev? — |
Free forum by Nabble | Edit this page |