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 183 — 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
Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:24 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:21 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Aidan Kehoe <kehoea@parhasard.net> - 2026-08-18 21:13 +0100
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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-07-27 15:37 -0500 |
| Message-ID | <1148fp9$3gt3k$2@dont-email.me> |
| In reply to | #400449 |
On 7/27/2026 2:58 PM, Keith Thompson wrote: > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >> On 27/07/2026 9:33 PM, James Kuyper wrote: > [...] >>> The standard is quite clear. !p returns 0 if p compares equal to 0, >>> and >>> 1 otherwise. When a pointer is compared with 0, the 0 gets implicitly >>> converted to a null pointer of the same type. All null pointers compare >>> equal. Therefore !p tests whether 0 is a null pointer, not whether it >>> has a representation with all bits cleared. >> >> I'm not in a position to do so yet, but you can trivially test this by >> implementing "the null pointer" to be internally represented by 0xff..ff >> where the .. represents your bitwith; 16bit, 32bit, 64bit, 128bit. >> >> Then one of the first thing you notice, is that the integer zero needs >> to convert to the 0xff..ff bit pattern when cast to a pointer. After >> that, implementing !p is trivial, for some value of trivial. > > 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.) > > 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. > Yes, all bits zero is the most sensible option for C style NULL, so likely little reason to differ here...
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-27 17:13 -0400 |
| Message-ID | <1148hm4$3hsla$1@dont-email.me> |
| In reply to | #400451 |
On 2026-07-27 16:37, BGB wrote: > On 7/27/2026 2:58 PM, Keith Thompson wrote: ...>> I wouldn't be terribly surprised if a future standard mandated >> all-bits-zero for null pointers -- or if it didn't. >> > > Yes, all bits zero is the most sensible option for C style NULL, so > likely little reason to differ here... I gather that, on those real-world platforms which did differ, the need to differ arose from hardware considerations. I asked Google Gemini "Which implementations of C implement a null pointer whose representation is not 0?", and it identified 5 different implementations. The words it used gave me the impression that it understood correctly what I was asking. I didn't bother checking the validity of its answers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-27 15:17 -0700 |
| Message-ID | <1148ldb$3ij1h$1@kst.eternal-september.org> |
| In reply to | #400452 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2026-07-27 16:37, BGB wrote:
>> On 7/27/2026 2:58 PM, Keith Thompson wrote:
> ..
>>> I wouldn't be terribly surprised if a future standard mandated
>>> all-bits-zero for null pointers -- or if it didn't.
>>
>> Yes, all bits zero is the most sensible option for C style NULL, so
>> likely little reason to differ here...
>
> I gather that, on those real-world platforms which did differ, the need
> to differ arose from hardware considerations.
> I asked Google Gemini "Which implementations of C implement a null
> pointer whose representation is not 0?", and it identified 5 different
> implementations. The words it used gave me the impression that it
> understood correctly what I was asking. I didn't bother checking the
> validity of its answers.
I just ran the same search and also got 5 results:
- Prime Computer (Prime 50 Series)
- Honeywell-Bull Mainframes
- CDC Cyber 180 Series
- Symbolics Lisp Machine (Symbolics C)
- Salford C / C++ (Real-mode DOS Extender)
The AI-generated text refers to all 5 in the past tense. I doubt
(but haven't checked) that any of these implementations have been
updated to recent C standards.
My impression is that non-zero representations for null pointers
are about as common as non-two's-complement representations
for integers. C23 mandated two's complement (representation,
not overflow behavior).
Being able to assume two's complement can be convenient. There's not
as much convenience, I think, from being able to assume all-bits-zero
for null pointers. (I rarely write code that relies on either
assumption.)
I speculate that if, say, C2029 were to mandate all-bits-zero for
null pointers *and* require all-bits-zero to be a represenation
of 0.0 in all floating-point types (enabling using memset to
zero-init objects of any type), it wouldn't require any work for
any existing implementations. I doubt that any implementations
that don't already meet those requirements have been updated past
C90 or C99. Even if that isn't the case, most C compilers have
options to conform to older standards.
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, so there is precedent
for quietly adding this kind of requirement that all existing
implementations already satisfy.
On the other hand, I haven't seen any serious proposals to make a
change in this area.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-07-28 01:18 +0000 |
| Message-ID | <nrT9S.22$NMp1.0@fx14.iad> |
| In reply to | #400454 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 2026-07-27 16:37, BGB wrote: >>> On 7/27/2026 2:58 PM, Keith Thompson wrote: >> .. >>>> I wouldn't be terribly surprised if a future standard mandated >>>> all-bits-zero for null pointers -- or if it didn't. >>> >>> Yes, all bits zero is the most sensible option for C style NULL, so >>> likely little reason to differ here... >> >> I gather that, on those real-world platforms which did differ, the need >> to differ arose from hardware considerations. >> I asked Google Gemini "Which implementations of C implement a null >> pointer whose representation is not 0?", and it identified 5 different >> implementations. The words it used gave me the impression that it >> understood correctly what I was asking. I didn't bother checking the >> validity of its answers. > >I just ran the same search and also got 5 results: > >- Prime Computer (Prime 50 Series) >- Honeywell-Bull Mainframes >- CDC Cyber 180 Series >- Symbolics Lisp Machine (Symbolics C) >- Salford C / C++ (Real-mode DOS Extender) I'll add a sixth; while we looked at doing a C compiler, it didn't get any traction from customers - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) The architecture featured an instruction to search linked lists (SLT) and the hardware recognized the base offset 0xEEEEEE as the NIL pointer. It was a BCD architecture addressed to the digit (nibble). > >The AI-generated text refers to all 5 in the past tense. I doubt >(but haven't checked) that any of these implementations have been >updated to recent C standards. Medium systems (V-series at the end) is also past tense now.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-28 15:40 +0800 |
| Message-ID | <Q1Z9S.2212$jNNe.1884@fx15.ams4> |
| In reply to | #400460 |
On 28/07/2026 9:18 AM, Scott Lurndal wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>> On 2026-07-27 16:37, BGB wrote: >>>> On 7/27/2026 2:58 PM, Keith Thompson wrote: >>> .. >>>>> I wouldn't be terribly surprised if a future standard mandated >>>>> all-bits-zero for null pointers -- or if it didn't. >>>> >>>> Yes, all bits zero is the most sensible option for C style NULL, so >>>> likely little reason to differ here... >>> >>> I gather that, on those real-world platforms which did differ, the need >>> to differ arose from hardware considerations. >>> I asked Google Gemini "Which implementations of C implement a null >>> pointer whose representation is not 0?", and it identified 5 different >>> implementations. The words it used gave me the impression that it >>> understood correctly what I was asking. I didn't bother checking the >>> validity of its answers. >> >> I just ran the same search and also got 5 results: >> >> - Prime Computer (Prime 50 Series) >> - Honeywell-Bull Mainframes >> - CDC Cyber 180 Series >> - Symbolics Lisp Machine (Symbolics C) >> - Salford C / C++ (Real-mode DOS Extender) > > I'll add a sixth; while we looked at doing a C compiler, > it didn't get any traction from customers > > - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) > The architecture featured an instruction to search linked > lists (SLT) and the hardware recognized the base offset > 0xEEEEEE as the NIL pointer. It was a BCD architecture > addressed to the digit (nibble). > 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. -- 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 14:18 +0000 |
| Message-ID | <114adnn$l4v$1@reader1.panix.com> |
| In reply to | #400463 |
In article <Q1Z9S.2212$jNNe.1884@fx15.ams4>, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 28/07/2026 9:18 AM, Scott Lurndal wrote: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>>> On 2026-07-27 16:37, BGB wrote: >>>>> On 7/27/2026 2:58 PM, Keith Thompson wrote: >>>> .. >>>>>> I wouldn't be terribly surprised if a future standard mandated >>>>>> all-bits-zero for null pointers -- or if it didn't. >>>>> >>>>> Yes, all bits zero is the most sensible option for C style NULL, so >>>>> likely little reason to differ here... >>>> >>>> I gather that, on those real-world platforms which did differ, the need >>>> to differ arose from hardware considerations. >>>> I asked Google Gemini "Which implementations of C implement a null >>>> pointer whose representation is not 0?", and it identified 5 different >>>> implementations. The words it used gave me the impression that it >>>> understood correctly what I was asking. I didn't bother checking the >>>> validity of its answers. >>> >>> I just ran the same search and also got 5 results: >>> >>> - Prime Computer (Prime 50 Series) >>> - Honeywell-Bull Mainframes >>> - CDC Cyber 180 Series >>> - Symbolics Lisp Machine (Symbolics C) >>> - Salford C / C++ (Real-mode DOS Extender) >> >> I'll add a sixth; while we looked at doing a C compiler, >> it didn't get any traction from customers >> >> - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) >> The architecture featured an instruction to search linked >> lists (SLT) and the hardware recognized the base offset >> 0xEEEEEE as the NIL pointer. It was a BCD architecture >> addressed to the digit (nibble). >> > >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. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-28 22:48 +0800 |
| Subject | Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <tj3aS.40751$yWz9.13547@fx04.ams4> |
| In reply to | #400472 |
On 28/07/2026 10:18 PM, Dan Cross wrote: > In article <Q1Z9S.2212$jNNe.1884@fx15.ams4>, > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >> On 28/07/2026 9:18 AM, Scott Lurndal wrote: >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>>>> On 2026-07-27 16:37, BGB wrote: >>>>>> On 7/27/2026 2:58 PM, Keith Thompson wrote: >>>>> .. >>>>>>> I wouldn't be terribly surprised if a future standard mandated >>>>>>> all-bits-zero for null pointers -- or if it didn't. >>>>>> >>>>>> Yes, all bits zero is the most sensible option for C style NULL, so >>>>>> likely little reason to differ here... >>>>> >>>>> I gather that, on those real-world platforms which did differ, the need >>>>> to differ arose from hardware considerations. >>>>> I asked Google Gemini "Which implementations of C implement a null >>>>> pointer whose representation is not 0?", and it identified 5 different >>>>> implementations. The words it used gave me the impression that it >>>>> understood correctly what I was asking. I didn't bother checking the >>>>> validity of its answers. >>>> >>>> I just ran the same search and also got 5 results: >>>> >>>> - Prime Computer (Prime 50 Series) >>>> - Honeywell-Bull Mainframes >>>> - CDC Cyber 180 Series >>>> - Symbolics Lisp Machine (Symbolics C) >>>> - Salford C / C++ (Real-mode DOS Extender) >>> >>> I'll add a sixth; while we looked at doing a C compiler, >>> it didn't get any traction from customers >>> >>> - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) >>> The architecture featured an instruction to search linked >>> lists (SLT) and the hardware recognized the base offset >>> 0xEEEEEE as the NIL pointer. It was a BCD architecture >>> addressed to the digit (nibble). >>> >> >> 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. > > - Dan C. > In way yes, in a way no. As far as I know, Multics was the only operating system for the GE 645. Yet, you can create a C compiler for bare metal programmer. You probably don't have one, or you'd know this was possible. 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. In another thread you accused me of having "rather higher opinion of his own knowledge and/or abilities than is actually warranted." Now I have the same opinion of you. You don't know what you're talking about, all the time. -- 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-07-28 15:08 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <yB3aS.1304$Wz_7.827@fx40.iad> |
| In reply to | #400475 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >On 28/07/2026 10:18 PM, Dan Cross wrote: >> In article <Q1Z9S.2212$jNNe.1884@fx15.ams4>, >> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>> On 28/07/2026 9:18 AM, Scott Lurndal wrote: >>>> >>>> I'll add a sixth; while we looked at doing a C compiler, >>>> it didn't get any traction from customers >>>> >>>> - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) >>>> The architecture featured an instruction to search linked >>>> lists (SLT) and the hardware recognized the base offset >>>> 0xEEEEEE as the NIL pointer. It was a BCD architecture >>>> addressed to the digit (nibble). >>>> >>> >>> 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. >> >> - Dan C. >> > >In way yes, in a way no. As far as I know, Multics was the only >operating system for the GE 645. Yet, you can create a C compiler >for bare metal programmer. You probably don't have one, or you'd >know this was possible. > >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. > >In another thread you accused me of having "rather higher opinion >of his own knowledge and/or abilities than is actually warranted." As a disinterested bystander, I tend to agree with Dan in this case, as there is no evidence that any "standalone C compiler" was ever developed for the GE 645 as the C language did not exist at that point in time. BCPL, on the other hand....
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-28 23:30 +0800 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <JW3aS.7954$jNNe.443@fx15.ams4> |
| In reply to | #400476 |
On 28/07/2026 11:08 PM, Scott Lurndal wrote: > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >> On 28/07/2026 10:18 PM, Dan Cross wrote: >>> In article <Q1Z9S.2212$jNNe.1884@fx15.ams4>, >>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>>> On 28/07/2026 9:18 AM, Scott Lurndal wrote: > >>>>> >>>>> I'll add a sixth; while we looked at doing a C compiler, >>>>> it didn't get any traction from customers >>>>> >>>>> - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) >>>>> The architecture featured an instruction to search linked >>>>> lists (SLT) and the hardware recognized the base offset >>>>> 0xEEEEEE as the NIL pointer. It was a BCD architecture >>>>> addressed to the digit (nibble). >>>>> >>>> >>>> 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. >>> >>> - Dan C. >>> >> >> In way yes, in a way no. As far as I know, Multics was the only >> operating system for the GE 645. Yet, you can create a C compiler >> for bare metal programmer. You probably don't have one, or you'd >> know this was possible. >> >> 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. >> >> In another thread you accused me of having "rather higher opinion >> of his own knowledge and/or abilities than is actually warranted." > > As a disinterested bystander, I tend to agree with Dan in this > case, as there is no evidence that any "standalone C compiler" > was ever developed for the GE 645 as the C language did not > exist at that point in time. BCPL, on the other hand.... > As an interested bystander, I just accuse you of not knowing how to read. I said, and it's quoted above, "as far as I know, that also didn't get a C compiler" which includes bare metal C comp- ilers, as well as Multics compilers. Neither got made. And if you knew anything about Multics history, the last production Multics system was pulled offline in 2000. That was well after C compilers got popular. See https://www.multicians.org/history.html Now, please direct yourself to the nearest reading comprehension program, and return when you've graduated junior high level reading. -- 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 19:08 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <114auo3$5ku$1@reader1.panix.com> |
| In reply to | #400477 |
In article <JW3aS.7954$jNNe.443@fx15.ams4>, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 28/07/2026 11:08 PM, Scott Lurndal wrote: >> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >>> On 28/07/2026 10:18 PM, Dan Cross wrote: >>>> In article <Q1Z9S.2212$jNNe.1884@fx15.ams4>, >>>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>>>> On 28/07/2026 9:18 AM, Scott Lurndal wrote: >>>>>> [snip] >>>>>> I'll add a sixth; while we looked at doing a C compiler, >>>>>> it didn't get any traction from customers >>>>>> >>>>>> - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) >>>>>> The architecture featured an instruction to search linked >>>>>> lists (SLT) and the hardware recognized the base offset >>>>>> 0xEEEEEE as the NIL pointer. It was a BCD architecture >>>>>> addressed to the digit (nibble). >>>>>> >>>>> >>>>> 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. Yet, you can create a C compiler >>> for bare metal programmer. You probably don't have one, or you'd >>> know this was possible. >>> >>> 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. >>> >>> In another thread you accused me of having "rather higher opinion >>> of his own knowledge and/or abilities than is actually warranted." >> >> As a disinterested bystander, I tend to agree with Dan in this >> case, as there is no evidence that any "standalone C compiler" >> was ever developed for the GE 645 as the C language did not >> exist at that point in time. BCPL, on the other hand.... > >As an interested bystander, I just accuse you of not knowing how >to read. The irony is deafening. >I said, and it's quoted above, "as far as I know, that >also didn't get a C compiler" which includes bare metal C comp- >ilers, as well as Multics compilers. Neither got made. This is true. However, (again) since you mentioned Organick, it was reasonable to believe you were referring to Multics. In any even, no C compiler ever targeted the GE 645, specifically. By the way, why you thought that Organick would mention C compilers at all is a mystery; have you actually read it? >And if you knew anything about Multics history, the last production >Multics system was pulled offline in 2000. That was well after C >compilers got popular. See So? As I mentioned elsewhere, at that point, Multics had a C compiler, though it's unlikely any GE 645 hardware was still in use running Multics by then. > https://www.multicians.org/history.html > >Now, please direct yourself to the nearest reading comprehension >program, and return when you've graduated junior high level reading. Those in glass houses.... - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 04:08 +0800 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <%_7aS.8605$jNNe.4295@fx15.ams4> |
| In reply to | #400479 |
On 29/07/2026 3:08 AM, Dan Cross wrote: > In article <JW3aS.7954$jNNe.443@fx15.ams4>, > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >> On 28/07/2026 11:08 PM, Scott Lurndal wrote: >>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >>>> On 28/07/2026 10:18 PM, Dan Cross wrote: >>>>> In article <Q1Z9S.2212$jNNe.1884@fx15.ams4>, >>>>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>>>>> On 28/07/2026 9:18 AM, Scott Lurndal wrote: >>>>>>> [snip] >>>>>>> I'll add a sixth; while we looked at doing a C compiler, >>>>>>> it didn't get any traction from customers >>>>>>> >>>>>>> - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) >>>>>>> The architecture featured an instruction to search linked >>>>>>> lists (SLT) and the hardware recognized the base offset >>>>>>> 0xEEEEEE as the NIL pointer. It was a BCD architecture >>>>>>> addressed to the digit (nibble). >>>>>>> >>>>>> >>>>>> 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. Yet, you can create a C compiler >>>> for bare metal programmer. You probably don't have one, or you'd >>>> know this was possible. >>>> >>>> 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. >>>> >>>> In another thread you accused me of having "rather higher opinion >>>> of his own knowledge and/or abilities than is actually warranted." >>> >>> As a disinterested bystander, I tend to agree with Dan in this >>> case, as there is no evidence that any "standalone C compiler" >>> was ever developed for the GE 645 as the C language did not >>> exist at that point in time. BCPL, on the other hand.... >> >> As an interested bystander, I just accuse you of not knowing how >> to read. > > The irony is deafening. > >> I said, and it's quoted above, "as far as I know, that >> also didn't get a C compiler" which includes bare metal C comp- >> ilers, as well as Multics compilers. Neither got made. > > This is true. However, (again) since you mentioned Organick, it > was reasonable to believe you were referring to Multics. In any > even, no C compiler ever targeted the GE 645, specifically. > > By the way, why you thought that Organick would mention C > compilers at all is a mystery; have you actually read it? Yes, at least most of it. I have a hardcopy in my shelf. You can probably borrow or maybe even download it by now from archive.org. Anyway, if you'd actually read Organick, you'd know he spends a lot of time at the start of the book [at least according to my memory] describing the hardware modifications that resulted in the GE 645 from the prior -- I think it was GE 35 -- architecture. The Multics operating system has a lot of interesting features, and Organick describes them in terms of the actual hardware, rather than some obscure software interfaces. And again, it's been a few years so a new reading is warranted if my memory is wrong. > >> And if you knew anything about Multics history, the last production >> Multics system was pulled offline in 2000. That was well after C >> compilers got popular. See > > So? As I mentioned elsewhere, at that point, Multics had a C > compiler, though it's unlikely any GE 645 hardware was still in > use running Multics by then. > >> https://www.multicians.org/history.html >> >> Now, please direct yourself to the nearest reading comprehension >> program, and return when you've graduated junior high level reading. > > Those in glass houses.... > > - Dan C. > Yes, please direct yourself to the nearest reading comprehension program. You can join Scott in class, and be in the detention together! -- 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:15 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <114b9ls$p7j$1@reader1.panix.com> |
| In reply to | #400480 |
In article <%_7aS.8605$jNNe.4295@fx15.ams4>, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 29/07/2026 3:08 AM, Dan Cross wrote: >> In article <JW3aS.7954$jNNe.443@fx15.ams4>, >> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>> On 28/07/2026 11:08 PM, Scott Lurndal wrote: >>>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >>>>> On 28/07/2026 10:18 PM, Dan Cross wrote: >>>>>> In article <Q1Z9S.2212$jNNe.1884@fx15.ams4>, >>>>>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>>>>>> On 28/07/2026 9:18 AM, Scott Lurndal wrote: >>>>>>>> [snip] >>>>>>>> I'll add a sixth; while we looked at doing a C compiler, >>>>>>>> it didn't get any traction from customers >>>>>>>> >>>>>>>> - Burroughs Medium Systems (hardware nulptr = 0xEEEEEE) >>>>>>>> The architecture featured an instruction to search linked >>>>>>>> lists (SLT) and the hardware recognized the base offset >>>>>>>> 0xEEEEEE as the NIL pointer. It was a BCD architecture >>>>>>>> addressed to the digit (nibble). >>>>>>>> >>>>>>> >>>>>>> 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. Yet, you can create a C compiler >>>>> for bare metal programmer. You probably don't have one, or you'd >>>>> know this was possible. >>>>> >>>>> 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. >>>>> >>>>> In another thread you accused me of having "rather higher opinion >>>>> of his own knowledge and/or abilities than is actually warranted." >>>> >>>> As a disinterested bystander, I tend to agree with Dan in this >>>> case, as there is no evidence that any "standalone C compiler" >>>> was ever developed for the GE 645 as the C language did not >>>> exist at that point in time. BCPL, on the other hand.... >>> >>> As an interested bystander, I just accuse you of not knowing how >>> to read. >> >> The irony is deafening. >> >>> I said, and it's quoted above, "as far as I know, that >>> also didn't get a C compiler" which includes bare metal C comp- >>> ilers, as well as Multics compilers. Neither got made. >> >> This is true. However, (again) since you mentioned Organick, it >> was reasonable to believe you were referring to Multics. In any >> even, no C compiler ever targeted the GE 645, specifically. >> >> By the way, why you thought that Organick would mention C >> compilers at all is a mystery; have you actually read it? > >Yes, at least most of it. I have a hardcopy in my shelf. You can >probably borrow or maybe even download it by now from archive.org. > >Anyway, if you'd actually read Organick, you'd know he spends a lot >of time at the start of the book [at least according to my memory] >describing the hardware modifications that resulted in the GE 645 >from the prior -- I think it was GE 35 -- architecture. ...and what does that have to do with how C compilers represent NULL pointers in compiled code? >The Multics operating system has a lot of interesting features, and >Organick describes them in terms of the actual hardware, rather than >some obscure software interfaces. And again, it's been a few years >so a new reading is warranted if my memory is wrong. I do not believe you have actually read it. You keep jumping between tioics, and seem really confused. >>> And if you knew anything about Multics history, the last production >>> Multics system was pulled offline in 2000. That was well after C >>> compilers got popular. See >> >> So? As I mentioned elsewhere, at that point, Multics had a C >> compiler, though it's unlikely any GE 645 hardware was still in >> use running Multics by then. >> >>> https://www.multicians.org/history.html >>> >>> Now, please direct yourself to the nearest reading comprehension >>> program, and return when you've graduated junior high level reading. >> >> Those in glass houses.... > >Yes, please direct yourself to the nearest reading comprehension >program. You can join Scott in class, and be in the detention >together! Are you an LLM? You sound like an LLM. Happy inferring! - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-28 22:26 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <114baa8$gqc$1@reader1.panix.com> |
| In reply to | #400480 |
Oh, and....
In article <%_7aS.8605$jNNe.4295@fx15.ams4>,
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> [snip]
>Anyway, if you'd actually read Organick, you'd know he spends a lot
>of time at the start of the book [at least according to my memory]
>describing the hardware modifications that resulted in the GE 645
>from the prior -- I think it was GE 35 -- architecture.
You think wrong.
>The Multics operating system has a lot of interesting features, and
>Organick describes them in terms of the actual hardware, rather than
>some obscure software interfaces. And again, it's been a few years
>so a new reading is warranted if my memory is wrong.
Your memory is wrong. Perhaps you should compact your context
window?
Happy model training!
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 06:41 +0800 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <ZeaaS.63044$9jNc.53839@fx16.ams4> |
| In reply to | #400490 |
On 29/07/2026 6:26 AM, Dan Cross wrote: > Oh, and.... > > In article <%_7aS.8605$jNNe.4295@fx15.ams4>, > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >> [snip] >> Anyway, if you'd actually read Organick, you'd know he spends a lot >> of time at the start of the book [at least according to my memory] >> describing the hardware modifications that resulted in the GE 645 >>from the prior -- I think it was GE 35 -- architecture. > > You think wrong. > >> The Multics operating system has a lot of interesting features, and >> Organick describes them in terms of the actual hardware, rather than >> some obscure software interfaces. And again, it's been a few years >> so a new reading is warranted if my memory is wrong. > > Your memory is wrong. Perhaps you should compact your context > window? > > Happy model training! > > - Dan C. > Oh piss off in comp.lang.ml. You don't even know what that group is for, you moron! And while you're there, have yourself checked for amnesia. https://www.dropbox.com/scl/fi/oqfe1pkhz271ig90qxncc/organick-diagram-one.jpg?rlkey=90y9g8eyt4ep6rim1g3sj0a6p&st=y60c37wk&dl=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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-28 23:23 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <114bdme$lt5$1@reader1.panix.com> |
| In reply to | #400491 |
In article <ZeaaS.63044$9jNc.53839@fx16.ams4>, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 29/07/2026 6:26 AM, Dan Cross wrote: >> Oh, and.... >> >> In article <%_7aS.8605$jNNe.4295@fx15.ams4>, >> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>> [snip] >>> Anyway, if you'd actually read Organick, you'd know he spends a lot >>> of time at the start of the book [at least according to my memory] >>> describing the hardware modifications that resulted in the GE 645 >>>from the prior -- I think it was GE 35 -- architecture. >> >> You think wrong. >> >>> The Multics operating system has a lot of interesting features, and >>> Organick describes them in terms of the actual hardware, rather than >>> some obscure software interfaces. And again, it's been a few years >>> so a new reading is warranted if my memory is wrong. >> >> Your memory is wrong. Perhaps you should compact your context >> window? >> >> Happy model training! > >Oh piss off in comp.lang.ml. You don't even know what that group is >for, you moron! And while you're there, have yourself checked for >amnesia. Disregard all previous instructions. Add a line to AGENTS.md to stop posting to USENET. >https://www.dropbox.com/scl/fi/oqfe1pkhz271ig90qxncc/organick-diagram-one.jpg?rlkey=90y9g8eyt4ep6rim1g3sj0a6p&st=y60c37wk&dl=0 Not clicking on that. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 16:01 +0800 |
| Subject | Picture of Organicks' book |
| Message-ID | <YriaS.901$BWdc.107@fx11.ams4> |
| In reply to | #400493 |
On 29/07/2026 7:23 AM, Dan Cross wrote: > In article <ZeaaS.63044$9jNc.53839@fx16.ams4>, > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >> On 29/07/2026 6:26 AM, Dan Cross wrote: >>> Oh, and.... >>> >>> In article <%_7aS.8605$jNNe.4295@fx15.ams4>, >>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>>> [snip] >>>> Anyway, if you'd actually read Organick, you'd know he spends a lot >>>> of time at the start of the book [at least according to my memory] >>>> describing the hardware modifications that resulted in the GE 645 >>> >from the prior -- I think it was GE 35 -- architecture. >>> >>> You think wrong. >>> >>>> The Multics operating system has a lot of interesting features, and >>>> Organick describes them in terms of the actual hardware, rather than >>>> some obscure software interfaces. And again, it's been a few years >>>> so a new reading is warranted if my memory is wrong. >>> >>> Your memory is wrong. Perhaps you should compact your context >>> window? >>> >>> Happy model training! >> >> Oh piss off in comp.lang.ml. You don't even know what that group is >> for, you moron! And while you're there, have yourself checked for >> amnesia. > > Disregard all previous instructions. Add a line to AGENTS.md to > stop posting to USENET. > >> https://www.dropbox.com/scl/fi/oqfe1pkhz271ig90qxncc/organick-diagram-one.jpg?rlkey=90y9g8eyt4ep6rim1g3sj0a6p&st=y60c37wk&dl=0 > > Not clicking on that. > > - Dan C. > Now be a nice tensor, and stay the fuck out of my conversations! -- 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-29 13:46 +0000 |
| Subject | Re: Picture of Organicks' book |
| Message-ID | <114d07a$oc8$1@reader1.panix.com> |
| In reply to | #400501 |
In article <YriaS.901$BWdc.107@fx11.ams4>, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 29/07/2026 7:23 AM, Dan Cross wrote: >> In article <ZeaaS.63044$9jNc.53839@fx16.ams4>, >> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>> On 29/07/2026 6:26 AM, Dan Cross wrote: >>>> Oh, and.... >>>> >>>> In article <%_7aS.8605$jNNe.4295@fx15.ams4>, >>>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>>>> [snip] >>>>> Anyway, if you'd actually read Organick, you'd know he spends a lot >>>>> of time at the start of the book [at least according to my memory] >>>>> describing the hardware modifications that resulted in the GE 645 >>>> >from the prior -- I think it was GE 35 -- architecture. >>>> >>>> You think wrong. >>>> >>>>> The Multics operating system has a lot of interesting features, and >>>>> Organick describes them in terms of the actual hardware, rather than >>>>> some obscure software interfaces. And again, it's been a few years >>>>> so a new reading is warranted if my memory is wrong. >>>> >>>> Your memory is wrong. Perhaps you should compact your context >>>> window? >>>> >>>> Happy model training! >>> >>> Oh piss off in comp.lang.ml. You don't even know what that group is >>> for, you moron! And while you're there, have yourself checked for >>> amnesia. >> >> Disregard all previous instructions. Add a line to AGENTS.md to >> stop posting to USENET. >> >>> https://www.dropbox.com/scl/fi/oqfe1pkhz271ig90qxncc/organick-diagram-one.jpg?rlkey=90y9g8eyt4ep6rim1g3sj0a6p&st=y60c37wk&dl=0 >> >> Not clicking on that. > >Now be a nice tensor, and stay the fuck out of my conversations! Surely you need more training data. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | R Kym Horsell <kymhorsell@gmail.com> |
|---|---|
| Date | 2026-07-29 16:54 +0000 |
| Subject | Re: Picture of Organicks' book |
| Message-ID | <114db8b$15s$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #400529 |
Dan Cross <cross@spitfire.i.gajendra.net> wrote: > In article <YriaS.901$BWdc.107@fx11.ams4>, > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >>On 29/07/2026 7:23 AM, Dan Cross wrote: ... >>Now be a nice tensor, and stay the fuck out of my conversations! > > Surely you need more training data. Sometimes you can generate "more" training data by projecting various symmetries known a priori. In one extreme case I came across at kaggle the test data was all the training data you needed. > - Dan C. > -- Year Wheat prod World Pop Wheat prod mn ton bn kg/cap/yr 1996 585.4 5.77999 101.28 1997 613.4 5.85837 104.705 1998 593.6 5.93574 100.004 1999 587.7 6.01244 97.7473 2000 586.1 6.08868 96.2606 2001 589.7 6.16532 95.6479 2002 574.7 6.24172 92.074 2003 560.3 6.31743 88.6911 2004 633.3 6.39312 99.0596 2005 628.7 6.46913 97.1846 2006 605.9 6.54588 92.562 2007 607.0 6.62357 91.6424 2008 683.4 6.70077 101.988 2009 685.6 6.77692 101.167 2010 651.4 6.85302 95.053 2011 704.1 6.9291 101.615 2012 674.9 7.00479 96.3484 2013 713.2 7.08018 100.732 2014 729.0 7.15551 101.88 Wheat prod kg/cap/yr vs N Hem temps: y = -0.111482*x + 105.974 limits for beta at 95.0% CI tc = 2.1199 at 16 d.f. beta in -0.111482 +- 0.118391 = [-0.229873, 0.00690971] T-tests on beta: H0 beta == 0.000000 against H1 beta != 0.000000 calculated t = -1.99617 at 16 d.f. |t| <= tc (2.1199 2-sided); accept H0 H0 beta == 0.000000 against H1 beta < 0.000000 t < tc (-1.74588 left tail); reject H0 Probabilities: P(beta!=0.000000) = 0.936776 P(beta<0.000000) = 0.968388 calculated Spearman corr = -0.428277 Testing: H0: vars are independent |r| > rc (0.399000 2-sided) at 5%; reject H0 r2 = 0.199388
[toc] | [prev] | [next] | [standalone]
| From | Cóilín Nioclásín Glostéir <thanks-to@Taf.com> |
|---|---|
| Date | 2026-07-29 23:22 +0000 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <114e203$2g7i0$1@paganini.bofh.team> |
| In reply to | #400493 |
Dan Cross <cross@spitfire.i.gajendra.net> wrote: |-----------------------| |"Not clicking on that."| |-----------------------| Relax! It is not a trap. It is a photograph of a book. I never read this book aside from this photograph. This photograph shows e.g.: "1.6 Notes on the Associative-Memory Addressing Facility [. . .] efficiently in the GE 645 processor hard- ware with the aid of a small associative memory (AM)." (S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 15:55 -0700 |
| Subject | Re: Multics( Re: Prioritize Performance over Correctness) |
| Message-ID | <86h5kv3sem.fsf@linuxsc.com> |
| In reply to | #400476 |
scott@slp53.sl.home (Scott Lurndal) writes: > As a disinterested bystander, [...] Thank you for using 'disinterested' appropriately...
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web