From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13921 invoked from network); 6 Jun 2020 21:55:45 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2020 21:55:45 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 7C4769CA42; Sun, 7 Jun 2020 07:55:44 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 25D3D9C774; Sun, 7 Jun 2020 07:55:22 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="Sk96NIrR"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id AB75B9C606; Sun, 7 Jun 2020 07:55:20 +1000 (AEST) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by minnie.tuhs.org (Postfix) with ESMTPS id 07D5593D52 for ; Sun, 7 Jun 2020 07:55:20 +1000 (AEST) Received: by mail-qk1-f170.google.com with SMTP id n11so13600402qkn.8 for ; Sat, 06 Jun 2020 14:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UzNocWNALrceHKrS0udtJ2xR45PDUovIUdKgSiPoyZ4=; b=Sk96NIrRoxcnrJVNMgCneX6xnOeS0wJtDIPBkiKd2LwvZ+l9zl1SMpEJA5AXJAQzAQ PcIUijVgASHTUHL8ngdykfXfq9QOrkmelU0BR/vLsB4vzoOna2giNICZdOWGf5X7rMAm QVyqjyGUSTPNSS3WTQS0/9mOuyK3eoImiKkNvcwAWvdamomVx2Q/EiYnfBY8IGZ1hm4j tN/CChqF/AN4w1zP3U3JWhIDojtXJHCEQdiOFabDtzV5ErgZbPkwiQnA1ZvXdf1h7tlb QvrlEPMAwrok9JyTdUTj9n8zRqW6MkXLxpztyVWIZi4Co8pkIV746KWRt3HiDmhVAo3h pS9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UzNocWNALrceHKrS0udtJ2xR45PDUovIUdKgSiPoyZ4=; b=KXX/tKeofxhGadGGXmTlYkw5Cgn/JrHRphLRbLEcJRwRnysF9g0NZmZhECGmxAt5D0 VySvcI78x4sfue2cWY+mgXcChxalr/SKhxDLo33ufvXwz37RAynKrJPqPgb5psLIakIF B6j7xnu5ewskkXlwaXrUoCRUlME6AdSHaG5/hJuKzu+Ev7SaUFcLYSY5QhQ7l7m5TqRz mciHCnWIW1NTHnJT9FjD9NKHTCW12eXVm01AEaJtEv9YwSiy3kJLy17YUGB+klICuHVf pkVXW5xOcET13ZSG7HIlZOTNBHgTpePVO/CXUZt/sVW5boYOg5sxHpeM4Ju6L3f2W7tg /ubA== X-Gm-Message-State: AOAM533Jtv00yclzHqo9sNpcf/nLE9N0DgTaImopiM3EJR+OOgtOQLVS kI3hySPPxBq8y+utJSEjjkuN8SB0e94pCha68nkNpQ== X-Google-Smtp-Source: ABdhPJzIH2xhQh2OSvpAuJAeGNjQMFcN58yHbHRhoUGBOcSes/53n9YxksVjdMZMcC0Lnk+xzpFLbu/5qYnzSgn4W+Y= X-Received: by 2002:a37:9f09:: with SMTP id i9mr16288703qke.60.1591480518996; Sat, 06 Jun 2020 14:55:18 -0700 (PDT) MIME-Version: 1.0 References: <202006062149.056LnNsb074899@tahoe.cs.Dartmouth.EDU> In-Reply-To: <202006062149.056LnNsb074899@tahoe.cs.Dartmouth.EDU> From: Warner Losh Date: Sat, 6 Jun 2020 15:55:07 -0600 Message-ID: To: Doug McIlroy Content-Type: multipart/alternative; boundary="00000000000000885e05a7716f8c" Subject: Re: [TUHS] History of popularity of C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000000885e05a7716f8c Content-Type: text/plain; charset="UTF-8" On Sat, Jun 6, 2020 at 3:50 PM Doug McIlroy wrote: > > Steve Johnson's position paper on optimising compilers may amuse you: > > https://dl.acm.org/doi/abs/10.1145/567532.567542 > > Indeed. This passage struck a particular chord: > > "I contend that the class of applications that depend on, for example, loop > optimization and dead code elimination for their efficient solution is of > modest size, growing smaller, and often very susceptible to expression in > applicative languages where the optimization is built into the individual > applicative operators." > > I don't know whether I saw that note at the time, but since then I've > come to believe, particularly in regard to C, that one case of dead-code > elmination should be guaranteed. That case is if(0), where 0 is the > value of a constant expression. > > This guarantee would take the place of many--possibly even > most--ifdefs. Every ifdef is an ugly intrusion and a pain to read. > Syntactically it occurs at top level completely out of sync with the > indentation and flow of text. Conversion to if would be a big win. > I'd love something like this to work, but the semantic interpretation would need to also somehow be omitted, otherwise how do you replace #ifdef AIX ioct(fd, AIX_SPECIFIC_IOCTL, ...) #endif on a HUPX system that doesn't define AIX_SPECIFIC_IOCTL... I remember hearing that BLISS could cope because it deferred the semantic interpretation of the identifiers until after a round of dead code elimination so it didn't need a pre-processor... Warner --00000000000000885e05a7716f8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jun 6, 2020 at 3:50 PM Doug M= cIlroy <doug@cs.dartmouth.edu> wrote:
&g= t; Steve Johnson's position paper on optimising compilers may amuse you= :
> https://dl.acm.org/doi/abs/10.1145/567532.56754= 2

Indeed. This passage struck a particular chord:

"I contend that the class of applications that depend on, for example,= loop
optimization and dead code elimination for their efficient solution is of modest size, growing smaller, and often very susceptible to expression in applicative languages where the optimization is built into the individual applicative operators."

I don't know whether I saw that note at the time, but since then I'= ve
come to believe, particularly in regard to C, that one case of dead-code elmination should be guaranteed. That case is if(0), where 0 is the
value of a constant expression.

This guarantee would take the place of many--possibly even
most--ifdefs. Every ifdef is an ugly intrusion and a pain to read.
Syntactically it occurs at top level completely out of sync with the
indentation and flow of text. Conversion to if would be a big win.

I'd love something like this to work, but t= he semantic interpretation would need to also somehow be omitted, otherwise= how do you replace

#ifdef AIX
ioct(fd, = AIX_SPECIFIC_IOCTL, ...)
#endif

on a HUP= X system that doesn't define AIX_SPECIFIC_IOCTL...

=
I remember hearing that BLISS could cope because it deferred the seman= tic interpretation of the identifiers until after a round of dead code elim= ination so it didn't need a pre-processor...

W= arner
--00000000000000885e05a7716f8c--