Re: Portable Software (was: fledgling assembler programmer)

Hans-Peter Diettrich <DrDiettrich1@netscape.net> writes:
>My impression was that the FSF favors C and ./configure for "portable"
>code. That's why I understand that any other way is easier for the
>implementation of really portable software, that deserves no extra
>tweaks for each supported target platform, for every single program.


I have not noticed that the FSF has any preference for C, apart from C
being the lingua franca in the late 1980s and the 1990s, and arguably
for certain requirements it still is.


Now C on Unix has to fight with certain portability issues. In early
times C programs contained a config.h that the sysadmin installing a
program had to edit by hand before running make. Then came autoconf,
which generates configure files that run certain checks on the system
and fill in config.h for you; and of course, once the mechanism is
there, stuff in other files is filled in with configure, too.


It's unclear to me what you mean with "any other way is easier". The
way of manually editing config.h certainly was not easier for the
sysadmins. Not sure if it was easier for the maintainer of the
programs.


>Can somebody shed some light on the current practice of writing portable
>C/C++ software, or any other compiled language, that (hopefully) does
>not require additional human work before or after compilation for a
>specific target platform?


There are other tools like Cmake that claim to make autoconf
unnecessary, but when I looked at it, I did not find it useful for my
needs (but I forgot why).


So I'll tell you here some of what autoconf does for Gforth: Gforth is
a Forth system mostly written in Forth, but using a C substrate. Many
system differences are dealt with in the C substrate, often with the
help of autoconf. The configure.ac file describes what autoconf
should do for Gforth; it has grown to 1886 lines.


* It determines the CPU architecture and OS where the configure script
    is running at, and uses that to configure some architecture-specific
    stuff for Gforth, in particular how to synchronize the data and
    instruction caches; later gcc acquired __builtin___clear_cache() to
    do that, but at least on some platforms that builtin is broken
    <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93811>.


* It checks the sizes of the C integer types in order to determine the
    C type for Forth's cell and double-cell types.


* It uses the OS information to configure things like the newline
    sequence, the directory and path separators.


* It deals with differences between OSs, such as large (>4GB) file
    support, an issue relevant in the 1990s.


* It checks for the chcon program, and, if present, uses it to "work
    around SELinux brain damage"; if not present, the brain is probably
    undamaged.


* It tests which of several ways is accepted by the assembler to skip
    code space (needed for implementing Gforth's dynamic
    superinstructions).


* It checks for the presence of various programs and library functions
    needed for building Gforth, e.g. mmap() (yes, there used to be
    systems that do not have mmap()). In some cases it works around the
    absence, sometimes with degraded functionality; in other cases it
    just reports the absence, so the sysadmin knows what to install.


That's just some of the things I see in configure.ac; there are many
bits and pieces that are too involved and/or too minor to report here.


Our portability stuff does not catch everything. E.g., MacOS on Apple
Silicon has a broken mmap() (broken as far as Gforth is concerned;
looking at POSIX, it's compliant with that, but that does not justify
this breakage; MacOS on Intel works fine, as does Linux on Apple
Silicon), an issue that's new to us; I have not yet devised a
workaround for that, but when I do, a part of the solution may use
autoconf.


Now when you write Forth code in Gforth, it tends to be quite portable
across platforms (despite Forth being a low-level language where, if
you want to see them, it's easy to see differences between 32-bit and
64-bit systems, and between different byte orders). One reason for
that is that Gforth papers over system differences (with the help of
autoconf among other things); another reason is that Gforth does not
expose many of the things where the systems are different, at least
not at the Forth level. You can use the C interface and then access
all the things that C gives access to, many of which are
system-specific, and for which tools like autoconf exist.


The story is probably similar for other languages.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

Return to the comp.compilers page.
Search the comp.compilers archives again.