Re: Portable Software (was: fledgling assembler programmer)

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups	comp.compilers
Subject	Re: Portable Software (was: fledgling assembler programmer)
Date	2023-03-31 16:34 +0000
Organization	Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID	<23-04-001@comp.compilers> (permalink)
References	(4 earlier) <23-03-008@comp.compilers> <23-03-012@comp.compilers> <23-03-017@comp.compilers> <23-03-022@comp.compilers> <23-03-029@comp.compilers>

Show all headers | View raw

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/

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

fledgling assembler programmer Alan.Beck@darkrealms.ca (Alan Beck) - 2023-03-21 17:40 -0400
  Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-21 17:23 -0700
    Re: fledgling assembler programmer Thomas Koenig <tkoenig@netcologne.de> - 2023-03-22 06:49 +0000
      Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-22 13:31 -0700
        Re: fledgling assembler programmer Thomas Koenig <tkoenig@netcologne.de> - 2023-03-23 11:26 +0000
          Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-24 14:17 -0700
            Re: ancient PL/I, was fledgling assembler programmer drb@ihatespam.msu.edu (Dennis Boone) - 2023-03-24 22:51 +0000
              Re: ancient PL/I, was fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-24 22:44 -0700
                Re: ancient PL/I, was fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-25 01:27 -0700
            Re: fledgling assembler programmer Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-25 13:07 +0100
              Re: fledgling assembler programmer George Neuner <gneuner2@comcast.net> - 2023-03-25 20:54 -0400
                Portable Software (was: fledgling assembler programmer) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-28 09:21 +0200
                Re: Portable Software (was: fledgling assembler programmer) arnold@freefriends.org (Aharon Robbins) - 2023-03-28 14:42 +0000
                Re: configuguration tools, Portable Software (was: fledgling assembler programmer) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-03-29 18:33 +0000
                Re: configuguration tools, Portable Software (was: fledgling assembler programmer) arnold@skeeve.com (Aharon Robbins) - 2023-03-31 07:10 +0000
                Re: configuguration tools, Portable Software (was: fledgling assembler programmer) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-02 08:56 +0000
                Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-31 07:49 +0200
                Re: Portable Software anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-02 10:04 +0000
                Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-04-05 11:23 +0200
                Re: Portable Software anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-05 16:30 +0000
                Re: Portable Software Kaz Kylheku <864-117-4973@kylheku.com> - 2023-04-06 08:35 +0000
                Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-04-07 15:35 +0200
                Re: Portable Software Thomas Koenig <tkoenig@netcologne.de> - 2023-04-08 18:25 +0000
                Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-28 14:21 -0700
                Re: Portable Software (was: fledgling assembler programmer) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-03-29 18:34 +0000
                Re: Portable Software (was: fledgling assembler programmer) George Neuner <gneuner2@comcast.net> - 2023-03-28 17:26 -0400
                Re: Portable python Software (was: fledgling assembler programmer) George Neuner <gneuner2@comcast.net> - 2023-03-29 13:50 -0400
                Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-29 11:27 -0700
                Re: Portable Software (was: fledgling assembler programmer) Thomas Koenig <tkoenig@netcologne.de> - 2023-03-31 05:19 +0000
                Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-31 12:41 -0700
                Re: Portable Software (was: fledgling assembler programmer) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-03-31 16:34 +0000
      Re: fledgling assembler programmer arnold@skeeve.com (Aharon Robbins) - 2023-03-23 13:56 +0000
    Re: fledgling assembler programmer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-03-22 10:02 +0000
  Re: fledgling assembler programmer David Brown <david.brown@hesbynett.no> - 2023-03-22 14:39 +0100
  Re: fledgling assembler programmer George Neuner <gneuner2@comcast.net> - 2023-03-22 14:54 -0400

csiph-web