[QUOTE=Batalov;425409]How about this (in get_fft_radices.c, lines 1443-1446):
[CODE] case 7 :
numrad = 6; rvec[0] = 16; rvec[1] = 8; rvec[2] = 8; rvec[3] = 8; rvec[4] = 8; rvec[5] = 16; break;
#ifndef USE_ONLY_LARGE_LEAD_RADICES
case 7 :
numrad = 5; rvec[0] = 8; rvec[1] = 16; rvec[2] = 16; rvec[3] = 32; rvec[4] = 16; break;

[linux1@rhel7-3 build]$ gcc -Os ../src/get_fft_radices.c
../src/get_fft_radices.c: In function ‘get_fft_radices’:
../src/get_fft_radices.c:1446:3: error: duplicate case value
case 7 :
^
../src/get_fft_radices.c:1443:3: error: previously used here
case 7 :
^
[/CODE]Their gcc compiler is a bit stricter than on x86_64 (I've built it before -- no problems were reported, only warnings).[/QUOTE]
Yes, that bug in the unthreaded scalar-C builds has been fixed in my dev-branch code, users who run into it should just 'do the needful' in their local copy of the file.

[QUOTE]A bit later (in TRICKY section)
[CODE]../src/util.c: In function ‘print_host_info’:
../src/util.c:1071:106: error: ‘OS_BITS’ undeclared (first use in this function)[/CODE]so add -DOS_BITS=64 to the compiler line.

After polishing these two little blemishes, runs like a clock.[/QUOTE]
As long as it's a 64-bit OS - that would be 'yes' - your hack is fine. Note OS_BITS is set (or better, attempted-to-set) in platform.h - you can turn on a bunch of diagnostics for that file by adding -DPLATFORM_DEBUG to your compile command, say for just a single tiny source file like br.c.

I managed to set up a s390x chroot! So I don't need to rely on QEMU image anymore (They are pretty hard to find and make). I can now build a "fresh" debian rootfs from scratch.

For curious people, this is how it is done (the following commands need root privilege):[CODE]# apt-get install binfmt-support qemu qemu-user-static[/CODE]Then, manually download [URL="https://packages.debian.org/jessie-backports/all/debootstrap/download"]debootstrap[/URL] and install it by [CODE]# dpkg -i debootstrap_1.0.73~bpo8+1_all.deb[/CODE]Note we cannot install the latest version because it has a [URL="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813232"]bug[/URL] which prevents the two-stage bootstrap from working. (It takes me a looong time to figure this out, the error message isn't so obvious.) [CODE]qemu-debootstrap --arch=s390x --include=emacs-nox,less,build-essential,autogen --variant=buildd sid debian-s390x[/CODE] and we are done! :smile: You can now chroot into the chroot. This should works for any architecture that is supported by QEMU user mode emulation. In particular, armel (used by your phone) is supported.

I dropped my compilation yesterday, but today I tried some more...

#define COMPILER_TYPE_GCC 1

in ../src/platform.h

And Bob's your mother's closest living relative or something like that...

OK, I got both un-and-multithreaded builds (all manual compile and link) to work, via the following hacks to platform.h:

o Got rid of these undefs at top - these (duh!) make it impossible for use of PLATFORM_DEBUG as intended, no clue WTF I was thinking with these undefs:

#undef PLATFORM_DEBUG
#undef OS_DEBUG
#undef OS_BITS_DEBUG
#undef CPU_DEBUG
#undef CMPLR_DEBUG

o Instead of initially undefing the following 3 things I now init them to 'unknown' (the not-defined CPU_NAME was hosing the util.c compile):

#define CPU_TYPE "Unknown CPU type"
#define CPU_NAME "Unknown CPU name"
#define CPU_SUBTYPE_NAME "Unknown CPU subtype"

o Changed

#ifndef CPU_TYPE
#error platform.h : CPU_TYPE not defined!
#endif

to a #warning. (OS_TYPE and COMPILER_TYPE are still required to be defined during preprocessing of the platform.h file, though.)

o Added a #elif for the case of Unknown hardware platform, but under Linux/GCC.

Fiddled version of the header attached. I only did a pair of quick spot-checks of the 2 binaries @FFT length 128K via './Mlucas -fftlen 128 -iters 100' in each of my 2 build dirs (one for unthreaded, one with pthreading). All the normal Linux thread-affinity stuff seems to be working, though no clue how much || scaling one can expect in these puny guest-accounts. (My virtual setup shows just 2 cores.)

Hi Ernst,

I have added 2 new CPU_TYPE CPU_IS_S390 and CPU_IS_S390X to platform.h, does it passes the spot-check and self-test on your VM? The platform.h I use is the old one on my repo, not the one you have just posted . I will rebase my change on the latest platform.h if it works.

By the way, could you post the latest version of get_fft_radices.c on your dev branch? I think I run into the duplicate case problem reported by Batalov when building with singlethread.

Thanks people!

Hi, Alex - I will diff your platform.h and try it on the Cloud when I'm home later today and have a secure connection.

Being paranoid I manage my dev-branch code privately, so here is the current version of the file you asked for - should be a drop-in replacement (md5 of the *gz = db5d2504d58897229d0366f4749b4131):

Also, do we have any easy way of determining what underlying compute hardware is being used, or is the whole point of the 'generic' cloud setup to obfuscate that?

My gcc predefines-dump shows no obvious clues to the CPU type.

[QUOTE=alexvong1995;425532]Hi Ernst,

I have added 2 new CPU_TYPE CPU_IS_S390 and CPU_IS_S390X to platform.h, does it passes the spot-check and self-test on your VM? The platform.h I use is the old one on my repo, not the one you have just posted . I will rebase my change on the latest platform.h if it works.

By the way, could you post the latest version of get_fft_radices.c on your dev branch? I think I run into the duplicate case problem reported by Batalov when building with singlethread.

Thanks people![/QUOTE]

Alex, I integrated your additions into my latest, and also made a few tweaks to my yesterday work - the 3 predefines to "Unknown" (in place of the previous #undef) I used lead to preprocessor warnings on platforms where the variables do end being set to a specific platform-associated value:
[code]
../platform.h:1222:10: warning: 'CPU_NAME' macro redefined
#define CPU_NAME "x86_64"
^
../platform.h:130:9: note: previous definition is here
#define CPU_NAME "Unknown CPU name"
[/code]
so I fiddled those to set to the "unknown" values only if they are still undef'd by the time we reach the end of the platform.h file.

But note I fubared my key-creation on the cloud, so to save time was using Serge's already-setup image with his unzip of the 14.1 packaged code. He has since blown his stuff away. If your instance is still up, could you try auto-build with the merged platform.h file attached below?

Thanks, and happy lunar new year! I guess the celebrations have already started in Asia. (Or will within the next few hours.)

After i replaced platform.h:

[CODE][linux1@lorenzoibm mlucas-14.1]$ ./mlucas

Mlucas 14.1

http://hogranch.com/mayer/README.html

INFO: testing qfloat routines...
CPU Family = S390x, OS = Linux, 64-bit Version, compiled with Gnu C [or other compatible], Version 4.8.5 20150623 (Red Hat 4.8.5-4).
INFO: Using inline-macro form of MUL_LOHI64.
INFO: MLUCAS_PATH is set to ""
INFO: using 53-bit-significand form of floating-double rounding constant for scalar-mode DNINT emulation.
INFO: testing IMUL routines...
INFO: System has 2 available processor cores.
INFO: testing FFT radix tables...
looking for number of threads to use in nthreads.ini file...
Using NTHREADS = #CPUs = 2.
looking for worktodo.ini file...
worktodo.ini file found...checking next exponent in range...
ERROR: at line 245 of file ./src/get_preferred_fft_radix.c
Assertion failed: CONFIGFILE = mlucas.cfg: open failed![/CODE]

Ohhh.Sorry. It's working!!! Amazing!!!
P.S. Forgot about perfomance tunes (mlucas -s m).

[QUOTE=Lorenzo;425605]Ohhh.Sorry. It's working!!! Amazing!!!
P.S. Forgot about perfomance tunes (mlucas -s m).[/QUOTE]

Can you tell us anything about its performances? I guess it's running with 2 threads...

Luigi