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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24909 invoked from network); 12 Mar 2023 11:40:36 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 12 Mar 2023 11:40:36 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id ABF52413DE; Sun, 12 Mar 2023 21:40:30 +1000 (AEST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by minnie.tuhs.org (Postfix) with ESMTPS id 96F39413BD for ; Sun, 12 Mar 2023 21:40:23 +1000 (AEST) Received: by mail-lf1-x12e.google.com with SMTP id bi9so12291781lfb.2 for ; Sun, 12 Mar 2023 04:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678621221; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Eb300KQ4ofS6qejQsjcqNzZnxmp49DF7XbxLEwcOBxE=; b=Qo+tWsfb4jJb3WJIK9gecSeWCfQ5hgRDxdtTg3+BdjCU7zSc3soACtEu5w0/dfiE6A sElhtvTqgojUvzIO0Wr9yc0+2n3VFFQMmvNsj+k8GZLU8UoSFkz1O7YYhvkpShMEmhXx zwlf7ntOV4o595gxaKbkCfsQkANIPUApsd/OvaHW7FPfecUuZv4EizuyOQ+iUfkm+MqB k7NaTMhgfY/d79IgLrQxr2xQx0A153i5ZqT6RWReyUEpWKlGoSCzp/ZzD9HwaIAnZi+2 Koyd2KoT0FkPUrOKAayLJ8E2b7k+oNYpGc3OT10OJQJXC2KKjP1zHQZkpXAEl9lj6BIT YkLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678621221; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Eb300KQ4ofS6qejQsjcqNzZnxmp49DF7XbxLEwcOBxE=; b=AcT5zm2uMhev32sSPFB5ptiFVEpY406bgHJUJZP7Sl5xt1dICQmWo4GxxgAIdtWwK9 RpN+xTuUq7+4AtzH5rJE8FZM7a8abr4w672hcjBL7yyaF9OWfK3czEPAuU9bdWVOy8cU aSgn6FBLzRT2wgzIv9O4/PArPHvFSGVgpjEHYh2meyUKHgx3D3cHsiN58ls40jwmaPbN fhg7IDsigzav7cd9weyGJO+a3t+VHoDx38GyOPEaDXCya3C8P1sek1xeCv3w/hYPQ7YS iGkrKhEYdeEQzDfPfE+HL9q3aiTdkzH59QulO3jc+vQpdovLKnDjWwCbr6qPO7GY7N4u mwOg== X-Gm-Message-State: AO0yUKVoNLrN9a45n8WPUAmnGJub2GgoUbqP6AVwBoidP56T3Nkwmr/X lmWFQ1ysE/MVruhoGc9+AAJJzTaU/b5e9nWxL11UQiXl X-Google-Smtp-Source: AK7set9iierte9rcAquzj0R6Bjc+RIIx90y8R/8e0sbnt45dFhv45H8tA3kkf2fwWwfPne/HMSfK2P0DolwV8NnwbEw= X-Received: by 2002:ac2:518b:0:b0:4d5:ca32:6aea with SMTP id u11-20020ac2518b000000b004d5ca326aeamr9371337lfi.10.1678621221097; Sun, 12 Mar 2023 04:40:21 -0700 (PDT) MIME-Version: 1.0 References: <20230310113708.AD55518C080@mercury.lcs.mit.edu> In-Reply-To: From: Dan Cross Date: Sun, 12 Mar 2023 07:40:11 -0400 Message-ID: To: Anthony Martin Content-Type: multipart/alternative; boundary="0000000000009893f505f6b2752e" Message-ID-Hash: M3YQHVTOJJZTQQYHAGEG4JTQU2Q35PPM X-Message-ID-Hash: M3YQHVTOJJZTQQYHAGEG4JTQU2Q35PPM X-MailFrom: crossd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: TUHS X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009893f505f6b2752e Content-Type: text/plain; charset="UTF-8" On Sun, Mar 12, 2023, 3:39 AM Anthony Martin wrote: > Dan Cross once said: > > I'm told that the plan9 C compilers were callee-save in part to keep > > these state labels svelte. > > The Plan 9 compilers are caller-save. That means the labels only have > to contain pc and sp. Indeed. I typo-ed but meant caller-save; it wouldn't be very svelte if it were the other way around. ;-) Waserror works well except for one small issue > involving whether or not the compiler decides to store a value to a > non-volatile, non-pointer variable when the value would not be used > after a function call. As in: > > int a; > a = 1; > if(waserror()){ /* ... */ } > a = 2; > a = foo(a); > > The waserror branch may see a == 1 if foo errors. > > Ken's compilers are great, though. They don't engage in antisocial > optimizations based on dubious notions of undefined behavior. I'd > prefer my compiler to not elide explicit null checks or loads and > stores from a pointer. It is certainly a shame that modern compiler writers have become essentially hostile to programmers in their pursuit of ever more aggressive optimizations based on rigid readings of the standard, common sense be damned. As for the plan9 C _language_, in the late 80s, it was arguably an improvement over what ANSI put out. Nowadays, however, I think the inverse is true. *Shrug* - Dan C. --0000000000009893f505f6b2752e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 12, 2023, 3:39 AM Anthony Martin <ality@pbrane.org> wrote:
Dan Cross <crossd@gmail.com> once said:
> I'm told that the plan9 C compilers were callee-save in part to ke= ep
> these state labels svelte.

The Plan 9 compilers are caller-save. That means the labels only have
to contain pc and sp.

<= div dir=3D"auto">Indeed. I typo-ed but meant caller-save; it wouldn't b= e very svelte if it were the other way around. ;-)
<= br>

Waserror works well except for one s= mall issue
involving whether or not the compiler decides to store a value to a
non-volatile, non-pointer variable when the value would not be used
after a function call. As in:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 int a;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if(waserror()){ /* ... */ }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D 2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D foo(a);

The waserror branch may see a =3D=3D 1 if foo errors.

Ken's compilers are great, though. They don't engage in antisocial<= br> optimizations based on dubious notions of undefined behavior. I'd
prefer my compiler to not elide explicit null checks or loads and
stores from a pointer.

=
It is certainly a shame that modern compiler writers have= become essentially hostile to programmers in their pursuit of ever more ag= gressive optimizations based on rigid readings of the standard, common sens= e be damned.

As for the = plan9 C _language_, in the late 80s, it was arguably an improvement over wh= at ANSI put out. Nowadays, however, I think the inverse is true. *Shrug*

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 - Dan C.

--0000000000009893f505f6b2752e--