Re: makemake.in configuration (os--hw) -- what default settings?

[Bruno H. <br...@cl...>]

Hi Jörg and all,

> I'm a bit puzzled by what still needs to be done about makemake.in.
> Despite the numerous recent patches and successful compilation attempts
> on lots of systems, that file still contains lots of empty/default
> sections, e.g.
> 
>       # Mac OS X/x86_64 with 32-bit ABI
>       darwin*--i386) # TODO

Glad that you ask. The approach to portability now has changed. Before,
we enabled all optimizations by default, and reacted when people reported
a crash. And we did nothing if we could not reproduce the problem.

Now, by default, all possible NO_* optimizations blockers are enabled, i.e.
the optimizations are disabled. And we turn them on when we have verified
they cause no harm. The result should be better in the sense: "Better a
clisp that works and is slow, than a clisp that is fully optimized and
crashes during the test suite or even during the build."

The stubs here are records of how far we have come, for each platform.

I am currently working on the Linux/*, GNU/kFreeBSD, and Hurd platforms,
therefore work on these would duplicate work of mine. (I am currently
hanging on issues with Linux/sparc64.) But for other operating systems,
you can determine the progress.

The overall process of a port to a new platform is described in
unix/PLATFORMS.

> For instance, I have an 11 year old MacBook Pro. It's i386, 32bit only,
> and limited by apple to Snow Leopard OSX 10.6.x. No x86_64, despite the
> above comment.

I see [1][2]. The first thing to check is whether the address range in
processes on your Mac is similar enough as the one on Mac OS X/x86_64 with
32-bit ABI, that I have access to. See the unix/PLATFORMS file, section
"Address space layout". If it's similar enough, adjust the section for
defined(UNIX_MACOSX) && defined(I80386) (around line 2400 of lispbibl.d),
otherwise create a new one.

Then find out which parameters you need in the environment variable
MULTIBUILD_32_OPTIONS so that
  $ make -k -f Makefile.devel build-porting32-gcc-portability
succeeds.

Then try
  $ make -k -f Makefile.devel multibuild-macosx-i386
and analyze the build failures, so see which are failures that are expected
and unavoidable vs. failures that you can fix (through code changes or
by reducing the gcc optimizations).

Once you have determined this set, remove most optimization blocker flags
in makemake.in and redo
  $ make -k -f Makefile.devel multibuild-macosx-i386
and verify that all builds that succeeded earlier still succeed.

> What should go into the above section?
> - The most performant settings that happen work on my machine, after running
>   make benchmark in each of the build-gcc-spvw* directories?

Ignore "make benchmark" for the moment. Assume that each optimization
actually improves speed.

> - The most conservative settings, because my machine is just one among many darwin*--i386?
>   For instance, it currently contains NO_ADDRESS_SPACE_ASSUMPTIONS

NO_ADDRESS_SPACE_ASSUMPTIONS is certainly an optimization blocker
that you can remove.

> Furthermore, despite dispatching upon the OS and architecture, this section
> typically contains compiler-specific settings, e.g. -DNO_ARI_ASM. Is that
> really the correct place to put these?

NO_ARI_ASM is not compiler-specific, but NO_ASM is. Whether it's the correct
place, can be debated. Patches will be considered.

> That machine reports:
> 
> $ gcc -v
> Using built-in specs.
> Target: i686-apple-darwin10
> Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/usr/include/c++/4.2.1 --host=i686-apple-darwin10 --target=i686-apple-darwin10
> Thread model: posix
> gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
> 
> $ clang -v
> Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)
> Target: i386-apple-darwin10
> Thread model: posix

I would ignore clang on this platform. Too old. The current version is 4.0 or so.

Bruno

[1] https://support.apple.com/en-us/HT201948
[2] https://apple.stackexchange.com/questions/12666/how-to-check-whether-my-intel-based-mac-is-32-bit-or-64-bit