"The Evolution of Lua" -- born 1993, based on "ANSI C" -- and its relation to atomics -- 2011

[sur-behoffski <sur_behoffski@...>]

I've collected the PDF of a paper given at ACM HOPL III, 9-10 June 2007,
San Diego, CA, USA, entitled "The Evolution of Lua".  Snippets of this
paper are quoted in Lua's Wikipedia page.

URL: http://webserver2.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf



On PP 2-3, we have a list under the title "Other distinguishing features
of Lua come from its implementation:".  I'll just quote the first item --
together with its footnote -- as relevant here:

        Portability:  Lua is easy to build because it is implemented
        in strict ANSI C.[1]  It compiles out-of-the-box on most
        platforms (Linux, Unix, Windows, Mac OS X, etc.), and
        runs with at most a few small adjustments in virtually
        all platforms we know of, including mobile devices (e.g.,
        handheld computers and cell phones) and embedded mi-
        croprocessors (e.g., ARM and Rabbit).  To ensure porta-
        bility, we strive for warning-free compilations under as
        many compilers as possible.

        [1] Actually, Lua is implemented in “clean C”, that is, the
            intersection of C and C++.  Lua compiles unmodified as a
            C++ library.

Lua 1.0 came out in 1993, so "ANSI C" would obviously mean C89 (and
its ISO equivalent).

--

Further down the paper, from the "Retrospect" section, comes:

        Another thing that has worked well was our insistence on
        portability, which was initially motivated by the diverse plat-
        forms of Tecgraf’s clients. This allowed Lua to be compiled
        for platforms we had never dreamed of supporting. In par-
        ticular, Lua’s portability is one of the reasons that Lua has
        been widely adopted for developing games. Restricted en-
        vironments, such as game consoles, tend not to support the
        complete semantics of the full standard C library. By gradu-
        ally reducing the dependency of Lua’s core on the standard
        C library, we are moving towards a Lua core that requires
        only a free-standing ANSI C implementation. This move
        aims mainly at embedding flexibility, but it also increases
        portability. For instance, since Lua 3.1 it is easy to change
        a few macros in the code to make Lua use an application-
        specific memory allocator, instead of relying on malloc and
        friends. Starting with Lua 5.1, the memory allocator can be
        provided dynamically when creating a Lua state.

-----------------

Okay, enough on this topic.  I entered in response to this comment
that I found in Lua Digest Vol. 118, Issue 83:

        Subject: Re: More on thread memory contention [was: Re: Can't interrupt tight loops in Lua 5.4 anymore?]
        From:    Viacheslav Usov <via.usov@gmail.com>
        Date:    2020-05-20 19:51
        To:      Lua mailing list <lua-l@lists.lua.org>

        On Wed, May 20, 2020 at 3:43 AM sur-behoffski <sur_behoffski@grouse.com.au> wrote:

        > Title:   Who's afraid of a big bad optimizing compiler?

        This article, written almost a decade after atomics were standardized in C,
        failed to mention them except in passing, and failed to explain why they
        were deemed irrelevant.The article is seriously defective as such.

        Cheers,
        V.

and after I pointed to the "Who's Afraid of the Big Bad Optimizer"
article in LWN net, there was this post:

        Subject: Re: C atomics, lwn.net and major concurrency users...
        From:    Viacheslav Usov <via.usov@gmail.com>
        Date:    2020-05-21 17:56
        To:      Lua mailing list <lua-l@lists.lua.org>

        On Thu, May 21, 2020 at 2:17 AM sur-behoffski <sur_behoffski@grouse.com.au> wrote:

        > As such, I have not looked closely at atomics myself.  However,
        > lwn.net came to my rescue when I was searching for relevant
        > content:

        My point was that the article you mentioned originally was just about
        completely silent about some very important parts of the story. An
        uninitiated reader would be seriously mislead by relying on the article. A
        good article should have at least mentioned prior and related work.

        Cheers,
        V.
----

My reason for entering was that I believed that people were focussing
on simple-concurrency-model race conditions, whereas modern
multi-core architectures, with multiple level of caches, meant that
programmers needed to be more sophisticated in dealing with
concurrency issues in multi-threaded, shared-memory code... and that
is what the first LWN.net article I mentioned tackled.

The comments above about Lua's desire to be portable, rely on core ANSI C89,
and to strive to not rely heavily on support libraries, was something
I read so long ago, that I assumed readers of my first post would equally
understand this background.

Enough said.  While I wouldn't mind more discussions at other times, at
present I have so much else going on, that I have to withdraw from this
thread.

cheers,

sur-behoffski (Brenton Hoff)
programmer, Grouse Software