Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #400344 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2026-07-22 01:38 +0200 |
| Last post | 2026-07-23 11:18 +0200 |
| Articles | 20 on this page of 180 — 20 participants |
Back to article view | Back to comp.lang.c
Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 01:38 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 17:26 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 01:50 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 20:25 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 17:37 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-22 13:26 -0700
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 07:33 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-22 10:41 +0200
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-22 18:08 -0500
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-23 10:31 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:31 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:48 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 15:11 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 09:23 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 03:14 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-24 14:56 +0000
Re: Prioritize Performance over Correctness antispam@fricas.org (Waldek Hebisch) - 2026-07-25 16:30 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 09:33 -0400
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 00:22 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 12:58 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:37 -0500
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 17:13 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 15:17 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 01:18 +0000
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:40 +0800
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:18 +0000
Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 22:48 +0800
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 15:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 23:30 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 19:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:08 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:15 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:26 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 06:41 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:23 +0000
Picture of Organicks' book Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:01 +0800
Re: Picture of Organicks' book cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-29 13:46 +0000
Re: Picture of Organicks' book R Kym Horsell <kymhorsell@gmail.com> - 2026-07-29 16:54 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-29 23:22 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 15:55 -0700
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 18:58 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:10 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:20 +0000
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-29 14:44 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-30 02:08 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-16 07:59 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 17:59 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:42 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 03:22 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 19:21 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 13:02 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 20:18 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 14:17 +0100
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-28 16:02 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:45 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 12:03 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 19:32 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 13:42 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 20:49 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 16:01 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 12:53 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-31 14:21 -0400
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-31 20:07 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-31 13:00 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-01 02:34 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 16:08 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:28 +0000
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:22 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:51 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:32 -0400
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:20 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:54 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:00 +0800
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:25 -0400
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:55 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:31 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 21:26 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:57 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 15:33 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 16:22 -0700
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-07-30 07:40 +0100
Re: Prioritize Correctness over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 06:48 +0000
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:50 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:54 -0700
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 08:24 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:40 -0700
Re: Prioritize Correctness over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:39 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:44 -0400
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:00 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:38 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:53 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 15:10 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:40 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-31 02:43 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:44 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:58 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-01 01:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-02 23:14 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-02 14:37 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-02 22:51 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 16:43 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 12:03 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-03 23:49 +0000
Re: Prioritize Correctness Over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 19:35 -0700
MS-DOS memory models (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 08:08 +0800
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 10:16 +0200
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-03 10:41 +0100
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 12:28 +0200
Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 19:23 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 14:01 +0200
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 22:52 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 19:41 +0200
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:13 -0700
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:10 -0700
Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:10 +0200
But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:15 +0200
GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) Mild Shock <janburse@fastmail.fm> - 2026-08-07 14:37 +0200
What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) Mild Shock <janburse@fastmail.fm> - 2026-08-07 18:07 +0200
Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-09 21:22 +0200
Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:26 +0200
How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:50 +0200
The Mac Neo is a Budget Monster [GPU Channels] (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:27 +0200
The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:51 +0200
Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-03 19:51 +0100
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 00:22 +0800
Re: Malicious Computer Architecture Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-04 19:10 +0100
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:21 +0800
Re: Malicious Computer Architecture Kaz Kylheku <046-301-5902@kylheku.com> - 2026-08-06 21:55 +0000
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:31 +0800
Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-06 23:01 +0100
A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-04 14:58 +0200
The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus) Mild Shock <janburse@fastmail.fm> - 2026-08-04 15:10 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 05:34 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:04 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-04 00:52 +0000
Re: Prioritize Correctness Over Performance scott@slp53.sl.home (Scott Lurndal) - 2026-08-04 14:22 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 05:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 15:10 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:16 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-03 20:29 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 17:55 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-04 09:12 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 19:01 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-03 19:59 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:50 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 15:09 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 08:14 +0800
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:54 +0800
Re: Prioritize Performance over Correctness steveo@panix.com (Steven M. O'Neill) - 2026-07-31 20:34 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 19:40 -0400
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:36 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:56 +0800
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-24 14:47 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 16:27 +0200
Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 00:52 +0800
Re: Resources for Amateur Compiler Writers bart <bc@freeuk.com> - 2026-07-24 23:08 +0100
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-24 18:50 -0500
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 01:54 +0000
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:20 +0800
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 07:24 +0000
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:30 +0800
Re: Resources for Amateur Compiler Writers David Brown <david.brown@hesbynett.no> - 2026-07-25 10:37 +0200
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-27 00:35 +0800
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-26 12:39 -0500
Re: Resources for Amateur Compiler Writers bart <bc@freeuk.com> - 2026-07-26 22:27 +0100
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-26 18:02 -0500
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 22:32 +0000
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-25 15:58 -0700
Re: Resources for Amateur Compiler Writers David Brown <david.brown@hesbynett.no> - 2026-07-25 10:23 +0200
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 16:29 -0700
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:25 +0800
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-25 15:33 -0700
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-27 00:38 +0800
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-26 17:06 -0700
Re: Resources for Amateur Compiler Writers Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-26 17:03 +0000
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-24 16:50 -0500
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 16:13 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-26 15:26 -0500
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-23 11:18 +0200
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-28 18:58 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <114au4c$sto$1@reader1.panix.com> |
| In reply to | #400475 |
In article <tj3aS.40751$yWz9.13547@fx04.ams4>, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 28/07/2026 10:18 PM, Dan Cross wrote: >>> [snip] >>> I'd expect GE-645 to qualify too, but as far as I know, that >>> also didn't get a C compiler. Right now I'm not pulling >>> Organick off my shelf to see if I'm right, other people can >>> do that. >> >> I assume you mean the Multics system. It did not have a C >> compiler on the 645, no. The follow-on , H6180 and DPS/8m, yes. > >In way yes, in a way no. As far as I know, Multics was the only >operating system for the GE 645. First, this is not true. The GE 645 had a 635 compatibility mode that allowed it to boot the earlier GECOS operating system; for details, see the section, "Transition to the GE-645" at https://multicians.org/ge635.html. But that historical trivia aside, I don't see how it is relevant to your claim about nil pointers. >Yet, you can create a C compiler >for bare metal programmer. You probably don't have one, or you'd >know this was possible. What does that have to do with anything? You mentioned Organick, so it seems reasonable you were asking about either Multics or FORTRAN (Organick wrote a very well-regarded book about FORTRAN-77). Given that you mentioned the GE 645, Multics was most likely. If you only meant to talk about the 645, absent Multics, then one would be better off referring to GE documentation (which is available), not Organick. There is a C compiler for Multics; it predates the ANSI C standard, but post-dates typesetter C: it's close to what is described in K&R1, and I've heard it was a port of the compiler that shipped with SVR2. I don't know about the veracity of that claim, however. In any event, no C compiler ever ran on, or targeted, the 645 specifically. However, C compilers _did_ run on and target the GE 635 during the timeframe in which the 645 was a going concern, including an early compiler written by Dennis Ritchie. I have never bothered to investigate how NULL was represented on that machine, but it is likely that programs compiled for the 635 would run on the 645 in compatibility mode, if anyone ever tried. >My personal example is the mikroC Pro for PIC32. It creates MIPS >binaries, and is loaded directly on the microcontroller. There is >no operating system to speak of. ...so? >In another thread you accused me of having "rather higher opinion >of his own knowledge and/or abilities than is actually warranted." Yes. This post to which I am responding is rather QED on that point, I'm afraid. >Now I have the same opinion of you. You don't know what you're >talking about, all the time. It is true that I do not always know what I am talking about. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 04:10 +0800 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <h18aS.8606$jNNe.7242@fx15.ams4> |
| In reply to | #400478 |
On 29/07/2026 2:58 AM, Dan Cross wrote: > In article <tj3aS.40751$yWz9.13547@fx04.ams4>, > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >> On 28/07/2026 10:18 PM, Dan Cross wrote: >>>> [snip] >>>> I'd expect GE-645 to qualify too, but as far as I know, that >>>> also didn't get a C compiler. Right now I'm not pulling >>>> Organick off my shelf to see if I'm right, other people can >>>> do that. >>> >>> I assume you mean the Multics system. It did not have a C >>> compiler on the 645, no. The follow-on , H6180 and DPS/8m, yes. >> >> In way yes, in a way no. As far as I know, Multics was the only >> operating system for the GE 645. > > First, this is not true. The GE 645 had a 635 compatibility > mode that allowed it to boot the earlier GECOS operating system; > for details, see the section, "Transition to the GE-645" at > https://multicians.org/ge635.html. > > But that historical trivia aside, I don't see how it is relevant > to your claim about nil pointers. > >> Yet, you can create a C compiler >> for bare metal programmer. You probably don't have one, or you'd >> know this was possible. > > What does that have to do with anything? > > You mentioned Organick, so it seems reasonable you were asking > about either Multics or FORTRAN (Organick wrote a very > well-regarded book about FORTRAN-77). Given that you mentioned > the GE 645, Multics was most likely. If you only meant to talk > about the 645, absent Multics, then one would be better off > referring to GE documentation (which is available), not > Organick. > > There is a C compiler for Multics; it predates the ANSI C > standard, but post-dates typesetter C: it's close to what is > described in K&R1, and I've heard it was a port of the compiler > that shipped with SVR2. I don't know about the veracity of that > claim, however. > > In any event, no C compiler ever ran on, or targeted, the 645 > specifically. However, C compilers _did_ run on and target the > GE 635 during the timeframe in which the 645 was a going > concern, including an early compiler written by Dennis Ritchie. > I have never bothered to investigate how NULL was represented on > that machine, but it is likely that programs compiled for the > 635 would run on the 645 in compatibility mode, if anyone ever > tried. > >> My personal example is the mikroC Pro for PIC32. It creates MIPS >> binaries, and is loaded directly on the microcontroller. There is >> no operating system to speak of. > > ...so? > >> In another thread you accused me of having "rather higher opinion >> of his own knowledge and/or abilities than is actually warranted." > > Yes. This post to which I am responding is rather QED on that > point, I'm afraid. > >> Now I have the same opinion of you. You don't know what you're >> talking about, all the time. > > It is true that I do not always know what I am talking about. > > - Dan C. > Please direct yourself to the reading comprehension program, and learn what "as far as I know" means. You told me something I didn't know before, but you're being so much of an asshole I don't want to learn anything from you. So please go and subscribe to comp.lang.ml, and stay there! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-28 22:20 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <114ba0b$bkj$1@reader1.panix.com> |
| In reply to | #400481 |
In article <h18aS.8606$jNNe.7242@fx15.ams4>, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 29/07/2026 2:58 AM, Dan Cross wrote: >> In article <tj3aS.40751$yWz9.13547@fx04.ams4>, >> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>> On 28/07/2026 10:18 PM, Dan Cross wrote: >>>>> [snip] >>>>> I'd expect GE-645 to qualify too, but as far as I know, that >>>>> also didn't get a C compiler. Right now I'm not pulling >>>>> Organick off my shelf to see if I'm right, other people can >>>>> do that. >>>> >>>> I assume you mean the Multics system. It did not have a C >>>> compiler on the 645, no. The follow-on , H6180 and DPS/8m, yes. >>> >>> In way yes, in a way no. As far as I know, Multics was the only >>> operating system for the GE 645. >> >> First, this is not true. The GE 645 had a 635 compatibility >> mode that allowed it to boot the earlier GECOS operating system; >> for details, see the section, "Transition to the GE-645" at >> https://multicians.org/ge635.html. >> >> But that historical trivia aside, I don't see how it is relevant >> to your claim about nil pointers. >> >>> Yet, you can create a C compiler >>> for bare metal programmer. You probably don't have one, or you'd >>> know this was possible. >> >> What does that have to do with anything? >> >> You mentioned Organick, so it seems reasonable you were asking >> about either Multics or FORTRAN (Organick wrote a very >> well-regarded book about FORTRAN-77). Given that you mentioned >> the GE 645, Multics was most likely. If you only meant to talk >> about the 645, absent Multics, then one would be better off >> referring to GE documentation (which is available), not >> Organick. >> >> There is a C compiler for Multics; it predates the ANSI C >> standard, but post-dates typesetter C: it's close to what is >> described in K&R1, and I've heard it was a port of the compiler >> that shipped with SVR2. I don't know about the veracity of that >> claim, however. >> >> In any event, no C compiler ever ran on, or targeted, the 645 >> specifically. However, C compilers _did_ run on and target the >> GE 635 during the timeframe in which the 645 was a going >> concern, including an early compiler written by Dennis Ritchie. >> I have never bothered to investigate how NULL was represented on >> that machine, but it is likely that programs compiled for the >> 635 would run on the 645 in compatibility mode, if anyone ever >> tried. >> >>> My personal example is the mikroC Pro for PIC32. It creates MIPS >>> binaries, and is loaded directly on the microcontroller. There is >>> no operating system to speak of. >> >> ...so? >> >>> In another thread you accused me of having "rather higher opinion >>> of his own knowledge and/or abilities than is actually warranted." >> >> Yes. This post to which I am responding is rather QED on that >> point, I'm afraid. >> >>> Now I have the same opinion of you. You don't know what you're >>> talking about, all the time. >> >> It is true that I do not always know what I am talking about. > >Please direct yourself to the reading comprehension program, >and learn what "as far as I know" means. You told me something >I didn't know before, but you're being so much of an asshole >I don't want to learn anything from you. > >So please go and subscribe to comp.lang.ml, and stay there! You keep telling other people what to do, and yet you yourself do not seem to know what you are talking about. My guess at this point is that your posts are actually actually the slop output of some bad LLM. Anyway, I'm sure everyone here is waiting with baited breath for your vibe-coded compiler. ;-} - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-07-29 14:44 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <sloaS.10773$Nxe6.5977@fx43.iad> |
| In reply to | #400489 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <h18aS.8606$jNNe.7242@fx15.ams4>, >>So please go and subscribe to comp.lang.ml, and stay there! > >You keep telling other people what to do, and yet you yourself >do not seem to know what you are talking about. My guess at >this point is that your posts are actually actually the slop >output of some bad LLM. Anyway, I'm sure everyone here is >waiting with baited breath for your vibe-coded compiler. ;-} Personally, I'd rather wait with bated[*] breath, as it smells much better than baited breath.[**] [*] derived from abate [**] I have no interest whatsoever in the newbie's vibe-coded C compiler.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-30 02:08 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <114ebnh$7t$1@reader1.panix.com> |
| In reply to | #400531 |
In article <sloaS.10773$Nxe6.5977@fx43.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <h18aS.8606$jNNe.7242@fx15.ams4>, > >>>So please go and subscribe to comp.lang.ml, and stay there! >> >>You keep telling other people what to do, and yet you yourself >>do not seem to know what you are talking about. My guess at >>this point is that your posts are actually actually the slop >>output of some bad LLM. Anyway, I'm sure everyone here is >>waiting with baited breath for your vibe-coded compiler. ;-} > >Personally, I'd rather wait with bated[*] breath, as it smells >much better than baited breath.[**] I said what I said. :-) - Dan C. >[*] derived from abate > >[**] I have no interest whatsoever in the newbie's vibe-coded C compiler.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-16 07:59 -0700 |
| Message-ID | <86tsou2js0.fsf@linuxsc.com> |
| In reply to | #400454 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Note that the requirement for all-bits-zero to be a valid
> representation for zero in all integer types was added, without
> much fanfare, in a technical corrigendum to C99, [...]
That's true but it wasn't at all a big leap. First it was
already guaranteed to be true for integer types without padding
bits. Second the only additional constraint imposed is that a
value of 0 could have all padding bits be zeros (which likely was
already satisfied by all existing implementations). The C89/C90
standard doesn't use the term padding bits but they may be
inferred from the description of binary representation for
integer values ("pure binary numeration system").
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-27 17:59 -0700 |
| Message-ID | <1148usp$3lk77$1@kst.eternal-september.org> |
| In reply to | #400449 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
> On 28/07/2026 3:58 AM, Keith Thompson wrote:
>> You'd have to create a compiler, or modify an existing one, to use a
>> non-zero representation for null pointers. That's hardly "trivial".
>> (For example, default initialization for static objects could no
>> longer just zero the target object.)
>
[SNIP]
Your ASCII art has nothing to do with the current discussion (and
didn't even display correctly due to line wrapping). I've dropped
the cross-post to alt.ascii-art. Can you please try to focus?
>> I don't think there are any modern C compilers that don't use
>> all-bits-zero for null pointers. Other representations are of
>> course valid, but tend not to be worth the trouble.
>> I wouldn't be terribly surprised if a future standard mandated
>> all-bits-zero for null pointers -- or if it didn't.
>
> I think more of it like an arm-chair thought exercise. The issue
> isn't the bit pattern at all, but how you're going to treat conversion
> to integers. Especially in this context,
>
> if ( p ) { ... }
>
> a 64bit p with the pattern 0x..00000000 isn't supposed to be false,
> when truncated to an integer. If I remember the standard(s)
> correctly, p here is supposed to "devolve" into either 1 or 0 in a
> boolean context. I'd believe comparing to zero, and use the Z flag is
> normal in x64, and in MIPS64, direct comparison to $zero is probably
> the most normal way to go about it.
> I forgot the actual instructions in both cases. They're easy to
> look up anyway.
I don't know what you mean by "truncated to an integer". There is no
implicit pointer-to-integer conversion in "if (p)". Rather, if p is a
pointer, the implicit 0 is converted to pointer type before the
comparison, and the comparison yields 0 or 1 of type int.
Pointer values can be converted to integer types, but the result is
implementation-defined and not necessarily meaningful. There isn't
even a guarantee that converting a null pointer to an integer type
yields 0.
Here's what the standard says:
In both forms, the first substatement is executed if the
expression compares unequal to 0. In the else form, the second
substatement is executed if the expression compares equal to
0. If the first substatement is reached via a label, the second
substatement is not executed.
You can think of it as "devolving" to 1 or 0 if you like, but that's
not how the C standard describes it.
If p is of pointer type, "if (p)" treats the condition as true if
p is non-null, false if it's null. That's it. The semantics are
not defined in terms of pointer representation or CPU instructions.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-28 15:42 +0800 |
| Message-ID | <54Z9S.2213$jNNe.860@fx15.ams4> |
| In reply to | #400461 |
On 28/07/2026 8:59 AM, Keith Thompson wrote: > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >> On 28/07/2026 3:58 AM, Keith Thompson wrote: >>> You'd have to create a compiler, or modify an existing one, to use a >>> non-zero representation for null pointers. That's hardly "trivial". >>> (For example, default initialization for static objects could no >>> longer just zero the target object.) >> > [SNIP] > > Your ASCII art has nothing to do with the current discussion (and > didn't even display correctly due to line wrapping). I've dropped > the cross-post to alt.ascii-art. Can you please try to focus? > Nope. You've absolutely demonstrated that you have no idea what is involved in the internals of a C compiler. What you're trying to describe is just hogwash and balderdash when it comes to the real world nitty gritty of implementing a compiler. Now stay out of my compiler discussion, you're not wanted here! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-28 03:22 -0700 |
| Message-ID | <1149vtl$3v7uk$1@kst.eternal-september.org> |
| In reply to | #400464 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
> On 28/07/2026 8:59 AM, Keith Thompson wrote:
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>> On 28/07/2026 3:58 AM, Keith Thompson wrote:
>>>> You'd have to create a compiler, or modify an existing one, to use a
>>>> non-zero representation for null pointers. That's hardly "trivial".
>>>> (For example, default initialization for static objects could no
>>>> longer just zero the target object.)
>>>
>> [SNIP]
>> Your ASCII art has nothing to do with the current discussion (and
>> didn't even display correctly due to line wrapping). I've dropped
>> the cross-post to alt.ascii-art. Can you please try to focus?
>
> Nope. You've absolutely demonstrated that you have no idea what
> is involved in the internals of a C compiler. What you're trying
> to describe is just hogwash and balderdash when it comes to the
> real world nitty gritty of implementing a compiler.
>
> Now stay out of my compiler discussion, you're not wanted here!
Perhaps the rest of the group would be interested in knowing just
what I got so badly wrong.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-28 19:21 +0800 |
| Message-ID | <4h0aS.10292$1xtd.1622@fx01.ams4> |
| In reply to | #400466 |
On 28/07/2026 6:22 PM, Keith Thompson wrote: > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >> On 28/07/2026 8:59 AM, Keith Thompson wrote: >>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >>>> On 28/07/2026 3:58 AM, Keith Thompson wrote: >>>>> You'd have to create a compiler, or modify an existing one, to use a >>>>> non-zero representation for null pointers. That's hardly "trivial". >>>>> (For example, default initialization for static objects could no >>>>> longer just zero the target object.) >>>> >>> [SNIP] >>> Your ASCII art has nothing to do with the current discussion (and >>> didn't even display correctly due to line wrapping). I've dropped >>> the cross-post to alt.ascii-art. Can you please try to focus? >> >> Nope. You've absolutely demonstrated that you have no idea what >> is involved in the internals of a C compiler. What you're trying >> to describe is just hogwash and balderdash when it comes to the >> real world nitty gritty of implementing a compiler. >> >> Now stay out of my compiler discussion, you're not wanted here! > > Perhaps the rest of the group would be interested in knowing just > what I got so badly wrong. > I'll summarize it as: You think I care what the C standard documents say. I don't. I care how it's implemented. You don't. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-28 13:02 +0100 |
| Message-ID | <114a5nq$ohm$1@dont-email.me> |
| In reply to | #400468 |
On 28/07/2026 12:21, Johann 'Myrkraverk' Oskarsson wrote:
> On 28/07/2026 6:22 PM, Keith Thompson wrote:
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>> On 28/07/2026 8:59 AM, Keith Thompson wrote:
>>>> Your ASCII art has nothing to do with the current discussion (and
>>>> didn't even display correctly due to line wrapping). I've dropped
>>>> the cross-post to alt.ascii-art. Can you please try to focus?
>>>
>>> Nope. You've absolutely demonstrated that you have no idea what
>>> is involved in the internals of a C compiler.
You don't seem to have much idea either.
> What you're trying
>>> to describe is just hogwash and balderdash when it comes to the
>>> real world nitty gritty of implementing a compiler.
>>>
>>> Now stay out of my compiler discussion, you're not wanted here!
>>
>> Perhaps the rest of the group would be interested in knowing just
>> what I got so badly wrong.
>>
>
> I'll summarize it as: You think I care what the C standard documents
> say. I don't.
>
> I care how it's implemented. You don't.
This is what you wrote:
"I think more of it like an arm-chair thought exercise. The issue
isn't the bit pattern at all, but how you're going to treat conversion
to integers. Especially in this context,
if ( p ) { ... }
a 64bit p with the pattern 0x..00000000 isn't supposed to be false,
when truncated to an integer...."
You don't say what type 'p' is, but I assume it is a pointer.
How a compiler implements this depends partly on what the language says,
for example:
Scalar type Value True when
integer i i != 0
float x x != 0.0 (-0.0 may need considering)
pointer p p != NULL
Whether NULL is all-bits-zero depends on the implementation, but I think
it it more platform-dependent rather than left to individual compilers.
Since in that case code from different compilers would be incompatible,
and calling into external libraries would be problematical.
In any case, there is no conversion to int involved; it is just has to
implement that comparison by whatever means works.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-28 20:18 +0800 |
| Message-ID | <x61aS.10293$1xtd.9670@fx01.ams4> |
| In reply to | #400469 |
On 28/07/2026 8:02 PM, bart wrote:
> On 28/07/2026 12:21, Johann 'Myrkraverk' Oskarsson wrote:
>> On 28/07/2026 6:22 PM, Keith Thompson wrote:
>>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>>> On 28/07/2026 8:59 AM, Keith Thompson wrote:
>
>>>>> Your ASCII art has nothing to do with the current discussion (and
>>>>> didn't even display correctly due to line wrapping). I've dropped
>>>>> the cross-post to alt.ascii-art. Can you please try to focus?
>>>>
>>>> Nope. You've absolutely demonstrated that you have no idea what
>>>> is involved in the internals of a C compiler.
>
> You don't seem to have much idea either.
>
>
>> What you're trying
>>>> to describe is just hogwash and balderdash when it comes to the
>>>> real world nitty gritty of implementing a compiler.
>>>>
>>>> Now stay out of my compiler discussion, you're not wanted here!
>>>
>>> Perhaps the rest of the group would be interested in knowing just
>>> what I got so badly wrong.
>>>
>>
>> I'll summarize it as: You think I care what the C standard documents
>> say. I don't.
>>
>> I care how it's implemented. You don't.
>
> This is what you wrote:
>
> "I think more of it like an arm-chair thought exercise. The issue
> isn't the bit pattern at all, but how you're going to treat conversion
> to integers. Especially in this context,
>
> if ( p ) { ... }
>
> a 64bit p with the pattern 0x..00000000 isn't supposed to be false,
> when truncated to an integer...."
>
> You don't say what type 'p' is, but I assume it is a pointer.
>
> How a compiler implements this depends partly on what the language says,
> for example:
>
> Scalar type Value True when
>
> integer i i != 0
> float x x != 0.0 (-0.0 may need considering)
> pointer p p != NULL
>
> Whether NULL is all-bits-zero depends on the implementation, but I think
> it it more platform-dependent rather than left to individual compilers.
>
> Since in that case code from different compilers would be incompatible,
> and calling into external libraries would be problematical.
>
> In any case, there is no conversion to int involved; it is just has to
> implement that comparison by whatever means works.
>
Indeed, and if you read the snippet you so thoughtfully cut off, you'd
have realized that's exactly how I think about it, in terms of compiler
internals. Now, of course, you being an expert in twisting other
people's expertise, you must be a journalist? Do you perhaps write for
VICE? I got my name into a VICE article once, for not being involved
at all. That was comforting. Now I feel like I'm just as important
as UBS.
On the other hand, to the programmer, especially those not who have not
and never will read the C language standard, it does look like the p
pointer is "truncated" to an integer valued 0 or 1, in boolean context.
And as I told Keith, I don't care how the language standard words
things. I care how the compiler is implemented.
.________________________.
,-'""`-. ( )
; : o 0 ( I also added some more old )
: : ( ASCII art, and re-added )
: (_) (_) ; ( alt.ascii-art for cross )
` '` ' ^^( posting purposes! )^^
:`++++'; ^(._______________.)
``..'' /mv/
Happy writing articles for VICE!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-28 14:17 +0100 |
| Message-ID | <114aa4b$2hor$1@dont-email.me> |
| In reply to | #400470 |
On 28/07/2026 13:18, Johann 'Myrkraverk' Oskarsson wrote: > On 28/07/2026 8:02 PM, bart wrote: >> >> In any case, there is no conversion to int involved; it is just has to >> implement that comparison by whatever means works. >> > On the other hand, to the programmer, especially those not who have not > and never will read the C language standard, it does look like the p > pointer is "truncated" to an integer valued 0 or 1, in boolean context. It doesn't look like that all. This is just testing for 'truthiness', which in many languages can be applied to data types such as strings or lists. 'Truncation' doesn't work either: you can have all-bits-zero NULL, and a value for 'p' of 0x123456 - truncating to one bit would give you zero, which is false. There is also rarely any result - no value needs to be yielded when the result just affects control-flow.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-07-28 16:02 -0500 |
| Message-ID | <114b5jd$cdh4$1@dont-email.me> |
| In reply to | #400471 |
On 7/28/2026 8:17 AM, bart wrote: > On 28/07/2026 13:18, Johann 'Myrkraverk' Oskarsson wrote: >> On 28/07/2026 8:02 PM, bart wrote: > >>> >>> In any case, there is no conversion to int involved; it is just has >>> to implement that comparison by whatever means works. >>> > >> On the other hand, to the programmer, especially those not who have not >> and never will read the C language standard, it does look like the p >> pointer is "truncated" to an integer valued 0 or 1, in boolean context. > > It doesn't look like that all. This is just testing for 'truthiness', > which in many languages can be applied to data types such as strings or > lists. > > 'Truncation' doesn't work either: you can have all-bits-zero NULL, and a > value for 'p' of 0x123456 - truncating to one bit would give you zero, > which is false. > > There is also rarely any result - no value needs to be yielded when the > result just affects control-flow. > In practice, it is mostly come sort of "compare with 0", of some sort. In my case, typically a 64-bit compare with 0 is used, as while tagged NULLs could exist in theory, by default they don't, and it is not worth the added cost of dealing with them (either in software or hardware). I once did experiment with supporting a few 48-bit ALU ops specifically for pointers, but these worked out as "deceptively expensive" for the CPU core. So, this idea was soon dropped (well, along with 48-bit Load/Store with a 16-bit index scale; was overly niche and too expensive to justify that niche). Eventually noted, the main winning strategy is mostly to just use native 64-bit compare ops for everything. Earlier forms of the ISA had 32-bit compare ops that ignored the high 32 bits, but these are effectively gone in the newer variant. Even if it does mean that in cases where one wants to ignore the high 16 bits, it is necessary to sign or zero extend from 48 bits. In the default mode, my compiler does not do so, so using tagging bits may interfere with pointer comparison. Most cases where tagging are used though are not places where the pointers are likely to be compared though. Except well, in the experimental bounds-checked mode, which had more expensive multi-op zero-extending pointer compares (as otherwise the bounds-check tagging would unleash chaos). Did create another mess: Pointer subtract also needs to sign-extend; Casting pointers to long needing to truncate the high bits; ... This created a hassle for code that needed to twiddle the tag bits though, so, say: x=(long)((__m64)(ptr)); With casting via __m64 as a "just give me the raw bits" thing, where __m64 and __m128 were understood as opaque "bag of bits" types, which lack any operations of their own, but can be used to do raw bit-casts in other cases where the cast would have modified the type. In this compiler: memcpy(&x, &y, sizeof(T)); //not ideal, various drawbacks x=*(T*)(&y); //less bad, still not ideal x=(T)((__mXX)y); //usually the fastest, bare register MOV. Contrast with MSVC which treated __m64/__m128 as "some sort of unholy hackery masquerading as a struct", personally I think "type whose sole purpose is to be N bits" is a more sensible interpretation. Then added __m32 and __m16 for other cases where I felt a need for raw-bit casting. No "__m8" though mostly for lack of relevant types to cast between (no useful distinction from "unsigned char" or similar). They also still have tie-ins with SIMD, though had mostly ended up taking a different approach (from either MSVC or GCC), and instead effectively bolting GLSL style vectors onto C. Where, the GLSL approach seemed closest to my typical use-cases. Or, say, vector types: __vec2f, __vec3f, __vec4f //2/3/4 element, float __vec2d, __vec3d, __vec4d //2/3/4 element, double __vec2h. __vec3h, __vec4h //2/3/4 element, half / "short float" __vec2sf. __vec3sf, __vec4sf //2/3/4 element, half, same as above __quatf, __quatd //quaternion Where, types: float : 32-bit, S.E8.M23 double : 64-bit, S.E11.M52 short float : 16-bit, S.E5.M10 long double : 128-bit, S.E15.M112 Where, vectors have elements: x/y/z/w. Multiple or repeated elements gives a new vector or shuffle. '_' is a filler spot containing 0. "_Complex float" and "_Complex double" also exists as sub-types of vectors (or quaternions), where complex has i/r members (equiv x/y), and quaternions have i/j/k/r (equiv x/y/z/w). Convention would tend to put 'r' as the first component, but putting 'r' at the end works better for reusing existing SIMD handling. At present, these lack native "short float" or "long double" variants. Typical SIMD operators being, mostly: +, -: Pairwise add/sub *: Pairwise mul (vec), complex/quaternion product /: Pairwise div (vec), complex/quaternion division ^: Dot Product (scalar result) %: Cross Product (scalar for vec2, vector otherwise) Also sorta supports GCC style "__attribute__((vector_size(N)))" style SIMD as well. Well, I will probably stop here... ...
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 16:45 +0800 |
| Message-ID | <G4jaS.719$UXf1.389@fx03.ams4> |
| In reply to | #400471 |
On 28/07/2026 9:17 PM, bart wrote:
> On 28/07/2026 13:18, Johann 'Myrkraverk' Oskarsson wrote:
>> On 28/07/2026 8:02 PM, bart wrote:
>
>>>
>>> In any case, there is no conversion to int involved; it is just has
>>> to implement that comparison by whatever means works.
>>>
>
>> On the other hand, to the programmer, especially those not who have not
>> and never will read the C language standard, it does look like the p
>> pointer is "truncated" to an integer valued 0 or 1, in boolean context.
>
> It doesn't look like that all. This is just testing for 'truthiness',
> which in many languages can be applied to data types such as strings or
> lists.
Let's test something for /truthiness/,
#include <stdio.h>
int main( int argc, char *argv[] ) {
printf( "boolean: %d\n", 3 || 0 ) ;
return 0;
}
what do you think the above code prints out? How is a programmer not to
believe boolean contexts truncate to 0 and 1 after experiments like
this?
Have you never performed any?
Did you never read /C Traps and Pitfalls/ by Koenig?
Dan Cross thinks I'm an LLM. So he must be fictional. Almost certainly
the son of Alex Cross, the fictional detective. So he's not allowed to
answer any of my posts anymore.
>
> 'Truncation' doesn't work either: you can have all-bits-zero NULL, and a
> value for 'p' of 0x123456 - truncating to one bit would give you zero,
> which is false.
>
> There is also rarely any result - no value needs to be yielded when the
> result just affects control-flow.
>
>
Ah, I see you're still writing fiction. You /must/ be a journalist.
What exactly do you mean "no value needs to yielded when the result
just affects control-flow?" Do you mean this is not allowed?
#include <stdio.h>
int main( int argc, char *argv[] ) {
switch ( argv == NULL ) case 0: printf( "argv is not NULL!\n" ) ;
return 0;
}
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-29 12:03 +0100 |
| Message-ID | <114cmm9$q9vq$1@dont-email.me> |
| In reply to | #400503 |
On 29/07/2026 09:45, Johann 'Myrkraverk' Oskarsson wrote:
> On 28/07/2026 9:17 PM, bart wrote:
>> On 28/07/2026 13:18, Johann 'Myrkraverk' Oskarsson wrote:
>>> On 28/07/2026 8:02 PM, bart wrote:
>>
>>>>
>>>> In any case, there is no conversion to int involved; it is just has
>>>> to implement that comparison by whatever means works.
>>>>
>>
>>> On the other hand, to the programmer, especially those not who have not
>>> and never will read the C language standard, it does look like the p
>>> pointer is "truncated" to an integer valued 0 or 1, in boolean context.
>>
>> It doesn't look like that all. This is just testing for 'truthiness',
>> which in many languages can be applied to data types such as strings
>> or lists.
>
> Let's test something for /truthiness/,
>
> #include <stdio.h>
>
> int main( int argc, char *argv[] ) {
>
> printf( "boolean: %d\n", 3 || 0 ) ;
>
> return 0;
> }
>
> what do you think the above code prints out? How is a programmer not to
> believe boolean contexts truncate to 0 and 1 after experiments like
> this?
You're using 'truncate' incorrectly. Normally it means masking some low
bits then zero- or sign-extending as needed.
If you truncated '4' to 1 bit but then you'd end up with 0, which is
false, but '4' itself is considered true.
A conversion of X to bool can be done explicitly using !!X, but it is
unnecessary in many contexts in C such as your example. It involves
neither conversion to an integer nor truncation.
>
> Have you never performed any?
>
> Did you never read /C Traps and Pitfalls/ by Koenig?
>
> Dan Cross thinks I'm an LLM.
No he just thinks you're a pratt.
>> There is also rarely any result - no value needs to be yielded when
>> the result just affects control-flow.
> Ah, I see you're still writing fiction. You /must/ be a journalist.
>
> What exactly do you mean "no value needs to yielded when the result
> just affects control-flow?"
I mean that this:
if (a && b == c)
is not usually the equivalent of:
cond = a && b == c;
if (cond)
or even:
c1 = !!a;
c2 = b == c;
c3 = c1 && c2;
if (c3)
No explicit boolean intermediates are generated, just a series of
comparisons and branches. Unless you have a very poor compiler backend.
In my own C compiler (an actual one) then this C:
int a, b, c;
if (a && b == c) ...;
produces this x64 code:
test R.a, R.a
jz L2
cmp R.b, R.c
jnz L2
...
No registers or variables are modified; there are no tangible
intermediate values.
> Do you mean this is not allowed?
>
> #include <stdio.h>
>
> int main( int argc, char *argv[] ) {
>
> switch ( argv == NULL ) case 0: printf( "argv is not NULL!\n" ) ;
This example is a little like:
c1 = argv == NULL;
where an actual value is needed, in this case an integer rather than
bool, which is the index value. But here a compiler is free to rearrange
it into an if-statement. So it depends.
The contexts where a conditional expression yields a Bool that is used
for conditional branching are these:
if (cond)
while (cond)
do while(cond)
for(;cond;)
cond?: (can use branching)
But switch (index) is different, even if a compiler can turn it into the
above.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 19:32 +0800 |
| Message-ID | <LxlaS.373$TxB9.178@fx07.ams4> |
| In reply to | #400516 |
On 29/07/2026 7:03 PM, bart wrote:
> On 29/07/2026 09:45, Johann 'Myrkraverk' Oskarsson wrote:
>> On 28/07/2026 9:17 PM, bart wrote:
>>> On 28/07/2026 13:18, Johann 'Myrkraverk' Oskarsson wrote:
>>>> On 28/07/2026 8:02 PM, bart wrote:
>>>
>>>>>
>>>>> In any case, there is no conversion to int involved; it is just has
>>>>> to implement that comparison by whatever means works.
>>>>>
>>>
>>>> On the other hand, to the programmer, especially those not who have not
>>>> and never will read the C language standard, it does look like the p
>>>> pointer is "truncated" to an integer valued 0 or 1, in boolean context.
>>>
>>> It doesn't look like that all. This is just testing for 'truthiness',
>>> which in many languages can be applied to data types such as strings
>>> or lists.
>>
>> Let's test something for /truthiness/,
>>
>> #include <stdio.h>
>>
>> int main( int argc, char *argv[] ) {
>>
>> printf( "boolean: %d\n", 3 || 0 ) ;
>>
>> return 0;
>> }
>>
>> what do you think the above code prints out? How is a programmer not to
>> believe boolean contexts truncate to 0 and 1 after experiments like
>> this?
>
> You're using 'truncate' incorrectly. Normally it means masking some low
> bits then zero- or sign-extending as needed.
Truncate is truncate. It's in the English dictionary. Let's ask Merriam-
Webster.
1: to shorten by or as if by cutting off truncate an essay/article
discussion
2: to replace (an edge or corner of a crystal) by a plane
Shamelessly copied from the web, like an LLM. Dan Cross can pay the
copyright penalty.
As you can see, the definition has nothing at all to do with bits.
>
> If you truncated '4' to 1 bit but then you'd end up with 0, which is
> false, but '4' itself is considered true.
But I'm not truncating 4, I'm truncating a boolean expression.
> A conversion of X to bool can be done explicitly using !!X, but it is
> unnecessary in many contexts in C such as your example. It involves
> neither conversion to an integer nor truncation.
We aren't talking about bools here, we're talking about integers. C
has its "boolean context" in integers, due to historical compatibility
with B.
>
>>
>> Have you never performed any?
>>
>> Did you never read /C Traps and Pitfalls/ by Koenig?
>>
>> Dan Cross thinks I'm an LLM.
>
> No he just thinks you're a pratt.
I don't know what a "pratt" is. Do you mind looking it up in the
dictionary for me?
>
>
>>> There is also rarely any result - no value needs to be yielded when
>>> the result just affects control-flow.
>
>> Ah, I see you're still writing fiction. You /must/ be a journalist.
>>
>> What exactly do you mean "no value needs to yielded when the result
>> just affects control-flow?"
>
> I mean that this:
>
> if (a && b == c)
>
> is not usually the equivalent of:
>
> cond = a && b == c;
> if (cond)
What do you mean? Isn't this exactly how SSA treats the code? Do you
just randomly cut off your /phi/ variables in your optimizer?
>
> or even:
>
> c1 = !!a;
> c2 = b == c;
> c3 = c1 && c2;
> if (c3)
>
> No explicit boolean intermediates are generated, just a series of
> comparisons and branches. Unless you have a very poor compiler backend.
I mean to make my compiler middleware use SSA. What does yours do? Do
you also just randomly forget some /phi/ variables?
>
> In my own C compiler (an actual one) then this C:
>
> int a, b, c;
> if (a && b == c) ...;
>
> produces this x64 code:
>
> test R.a, R.a
> jz L2
> cmp R.b, R.c
> jnz L2
> ...
>
> No registers or variables are modified; there are no tangible
> intermediate values.
Yes there are. They are in the flags register. X64 isn't MIPS.
>
>
>> Do you mean this is not allowed?
>>
>> #include <stdio.h>
>>
>> int main( int argc, char *argv[] ) {
>>
>> switch ( argv == NULL ) case 0: printf( "argv is not NULL!\n" ) ;
>
> This example is a little like:
>
> c1 = argv == NULL;
>
> where an actual value is needed, in this case an integer rather than
> bool, which is the index value. But here a compiler is free to rearrange
> it into an if-statement. So it depends.
>
> The contexts where a conditional expression yields a Bool that is used
> for conditional branching are these:
>
> if (cond)
> while (cond)
> do while(cond)
> for(;cond;)
> cond?: (can use branching)
>
>
> But switch (index) is different, even if a compiler can turn it into the
> above.
>
Yes, switch () is different, and you can force the boolean expression by
writing an explicit p == NULL there, like I did. It's "hidden" when you
put it in an if ().
Happy compiler building! Oh, and did you bother to read the /SSA-based
Compiler Design/ book, edited by Rastello, and Bouchez Tichadou?
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-29 13:42 +0100 |
| Message-ID | <114csfe$rnd4$1@dont-email.me> |
| In reply to | #400518 |
On 29/07/2026 12:32, Johann 'Myrkraverk' Oskarsson wrote: > On 29/07/2026 7:03 PM, bart wrote: >> On 29/07/2026 09:45, Johann 'Myrkraverk' Oskarsson wrote: >> You're using 'truncate' incorrectly. Normally it means masking some >> low bits then zero- or sign-extending as needed. > > Truncate is truncate. It's in the English dictionary. Let's ask Merriam- > Webster. > > 1: to shorten by or as if by cutting off truncate an essay/article > discussion > > 2: to replace (an edge or corner of a crystal) by a plane > > Shamelessly copied from the web, like an LLM. Dan Cross can pay the > copyright penalty. > > As you can see, the definition has nothing at all to do with bits. It seems to be nothing to do with pointer/integer/float to bool conversion either. >> >> If you truncated '4' to 1 bit but then you'd end up with 0, which is >> false, but '4' itself is considered true. > > But I'm not truncating 4, I'm truncating a boolean expression. I'd be interested in how you consider converting integer 8 to boolean 1, or integer 0 to boolean 0, to be 'truncation', and how you reconcile that to your dictionary definition. >> In my own C compiler (an actual one) then this C: >> >> int a, b, c; >> if (a && b == c) ...; >> >> produces this x64 code: >> >> test R.a, R.a >> jz L2 >> cmp R.b, R.c >> jnz L2 >> ... >> >> No registers or variables are modified; there are no tangible >> intermediate values. > > Yes there are. They are in the flags register. X64 isn't MIPS. Not really: * There are three implicit boolean results: 'a', 'b == c' and the result of '&&'. But the only flags used are tested only twice * We want both 'a' and 'b == c' to be True, but notice each of these tests uses the opposite logic from the other (the first needs a non-zero result and the second a zero result, since 'cmp' works by performing a subtraction, which must yield zero for equality) So there is no correspondence between how the internal machine flags behave, and the intermediate bools in the C code. >> The contexts where a conditional expression yields a Bool that is used >> for conditional branching are these: >> >> if (cond) >> while (cond) >> do while(cond) >> for(;cond;) >> cond?: (can use branching) >> >> >> But switch (index) is different, even if a compiler can turn it into >> the above. >> > > Yes, switch () is different, and you can force the boolean expression by > writing an explicit p == NULL there, like I did. It's "hidden" when you > put it in an if (). In the 'if', it directly controls branching. In the 'switch', it needs an integer value to index into a jump-table. This is in abstract machine terms.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 20:49 +0800 |
| Message-ID | <QFmaS.5696$DOD1.293@fx17.ams4> |
| In reply to | #400524 |
On 29/07/2026 8:42 PM, bart wrote: > On 29/07/2026 12:32, Johann 'Myrkraverk' Oskarsson wrote: >> On 29/07/2026 7:03 PM, bart wrote: >>> On 29/07/2026 09:45, Johann 'Myrkraverk' Oskarsson wrote: > >>> You're using 'truncate' incorrectly. Normally it means masking some >>> low bits then zero- or sign-extending as needed. >> >> Truncate is truncate. It's in the English dictionary. Let's ask >> Merriam- >> Webster. >> >> 1: to shorten by or as if by cutting off truncate an essay/article >> discussion >> >> 2: to replace (an edge or corner of a crystal) by a plane >> >> Shamelessly copied from the web, like an LLM. Dan Cross can pay the >> copyright penalty. >> >> As you can see, the definition has nothing at all to do with bits. > > It seems to be nothing to do with pointer/integer/float to bool > conversion either. > > >>> >>> If you truncated '4' to 1 bit but then you'd end up with 0, which is >>> false, but '4' itself is considered true. >> >> But I'm not truncating 4, I'm truncating a boolean expression. > > > I'd be interested in how you consider converting integer 8 to boolean 1, > or integer 0 to boolean 0, to be 'truncation', and how you reconcile > that to your dictionary definition. > >>> In my own C compiler (an actual one) then this C: >>> >>> int a, b, c; >>> if (a && b == c) ...; >>> >>> produces this x64 code: >>> >>> test R.a, R.a >>> jz L2 >>> cmp R.b, R.c >>> jnz L2 >>> ... >>> >>> No registers or variables are modified; there are no tangible >>> intermediate values. >> >> Yes there are. They are in the flags register. X64 isn't MIPS. > > Not really: Yes, really. The very instructions you used as example put their results in the flags register. > > * There are three implicit boolean results: 'a', 'b == c' and the result > of '&&'. But the only flags used are tested only twice > > * We want both 'a' and 'b == c' to be True, but notice each of these > tests uses the opposite logic from the other (the first needs a > non-zero result and the second a zero result, since 'cmp' works by > performing a subtraction, which must yield zero for equality) > > So there is no correspondence between how the internal machine flags > behave, and the intermediate bools in the C code. That's just because SSA doesn't deal with two assignments from the same operation. The C code is innocent. > > >>> The contexts where a conditional expression yields a Bool that is >>> used for conditional branching are these: >>> >>> if (cond) >>> while (cond) >>> do while(cond) >>> for(;cond;) >>> cond?: (can use branching) >>> >>> >>> But switch (index) is different, even if a compiler can turn it into >>> the above. >>> >> >> Yes, switch () is different, and you can force the boolean expression by >> writing an explicit p == NULL there, like I did. It's "hidden" when you >> put it in an if (). > In the 'if', it directly controls branching. In the 'switch', it needs > an integer value to index into a jump-table. This is in abstract machine > terms. > > In concrete machine terms, both use a label; or actually, a hardware address. The machine code doesn't use labels. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-29 16:01 +0100 |
| Message-ID | <114d4k4$uqhc$1@dont-email.me> |
| In reply to | #400526 |
On 29/07/2026 13:49, Johann 'Myrkraverk' Oskarsson wrote: > On 29/07/2026 8:42 PM, bart wrote: >>>> In my own C compiler (an actual one) then this C: >>>> >>>> int a, b, c; >>>> if (a && b == c) ...; >>>> >>>> produces this x64 code: >>>> >>>> test R.a, R.a >>>> jz L2 >>>> cmp R.b, R.c >>>> jnz L2 >>>> ... >>>> >>>> No registers or variables are modified; there are no tangible >>>> intermediate values. >>> >>> Yes there are. They are in the flags register. X64 isn't MIPS. >> >> Not really: > > Yes, really. The very instructions you used as example put their > results in the flags register. Where is the result of the && operation? > In concrete machine terms, both use a label; or actually, a hardware > address. The machine code doesn't use labels. In machine code, labels are just code addresses. Label rereferences depend on the architecture; typically these will be offsets rather than addresses. Any disassembler will be able to add labels, although it can't show the original identifiers for the same reason it can't show names of variables etc unless extra info is provided. How you actually implemented any language, including a backend? I looked at your site, and there's lots of stuff there, but no mention of anything like that.
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web