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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-02 16:43 -0700 |
| Message-ID | <114okmr$sjni$1@kst.eternal-september.org> |
| In reply to | #400725 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote:
>> Can void* always hold a function pointer? I think not.
>
> Even on architectures with separate instruction/data spaces, I would
> say it is reasonable to require that void* can indeed hold a function
> pointer.
>
> This is because you are likely to need a pointer to some environment
> context for the function to execute in anyway, so the function pointer
> won’t point directly to the code, but to a descriptor that contains
> the pointer to the code.
Whether it would be reasonable to require it is a matter of opinion.
(IMHO it isn't.) The fact is that the C standard currently does
not require that, and an implementation where converting a function
pointer to void* loses information can be conforming.
A conforming implementation could have, for example, 64-bit object
pointers and 128-bit function pointers, and that could make sense on
some architectures. The requirement you suggest would force such
implementations to play some trick like making function pointers
point to a descriptor rather than to the function's code, hurting
efficiency for indirect function calls.
There have been changes to the C standard that make some conforming
implementations non-conforming, for example the C23 requirement
for 2's-complement signed integers. A future standard *could* do
something similar. But I see no compelling reason for such a change.
There is a proposal to introduce a new universal function pointer
type called _Any_func*, analogous to but distinct from void* for
object pointer types. Since all function pointer types are already
convertible to each other without loss of information, the case
for _Any_func* isn't quite as compelling as the case for void*.
The idea is to provide a function pointer type that's explicitly
generic (and not callable). In the current proposal, void* and
_Any_func* would be *conditionally* convertible.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3914.htm
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 12:03 -0700 |
| Message-ID | <114qom0$1ip6k$1@dont-email.me> |
| In reply to | #400725 |
On 8/2/2026 3:51 PM, Lawrence D’Oliveiro wrote: > On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote: > >> Can void* always hold a function pointer? I think not. > > Even on architectures with separate instruction/data spaces, I would > say it is reasonable to require that void* can indeed hold a function > pointer. > > This is because you are likely to need a pointer to some environment > context for the function to execute in anyway, so the function pointer > won’t point directly to the code, but to a descriptor that contains > the pointer to the code. Well, a struct with function pointers in it, yes. We can hold a pointer to said struct in a uintptr_t. That's fine.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-03 23:49 +0000 |
| Subject | Re: Prioritize Correctness Over Performance |
| Message-ID | <114r9di$1nlvl$5@dont-email.me> |
| In reply to | #400765 |
On Mon, 3 Aug 2026 12:03:27 -0700, Chris M. Thomasson wrote: > On 8/2/2026 3:51 PM, Lawrence D’Oliveiro wrote: >> >> On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote: >> >>> Can void* always hold a function pointer? I think not. >> >> Even on architectures with separate instruction/data spaces, I >> would say it is reasonable to require that void* can indeed hold a >> function pointer. >> >> This is because you are likely to need a pointer to some >> environment context for the function to execute in anyway, so the >> function pointer won’t point directly to the code, but to a >> descriptor that contains the pointer to the code. > > Well, a struct with function pointers in it, yes. We can hold a > pointer to said struct in a uintptr_t. That's fine. In case it wasn’t clear, I was talking about how the underlying implementation has to handle function pointers, not how C programmers might use them in an application program.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 19:35 -0700 |
| Subject | Re: Prioritize Correctness Over Performance |
| Message-ID | <114rj5a$1qif9$2@dont-email.me> |
| In reply to | #400789 |
On 8/3/2026 4:49 PM, Lawrence D’Oliveiro wrote: > On Mon, 3 Aug 2026 12:03:27 -0700, Chris M. Thomasson wrote: > >> On 8/2/2026 3:51 PM, Lawrence D’Oliveiro wrote: >>> >>> On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote: >>> >>>> Can void* always hold a function pointer? I think not. >>> >>> Even on architectures with separate instruction/data spaces, I >>> would say it is reasonable to require that void* can indeed hold a >>> function pointer. >>> >>> This is because you are likely to need a pointer to some >>> environment context for the function to execute in anyway, so the >>> function pointer won’t point directly to the code, but to a >>> descriptor that contains the pointer to the code. >> >> Well, a struct with function pointers in it, yes. We can hold a >> pointer to said struct in a uintptr_t. That's fine. > > In case it wasn’t clear, I was talking about how the underlying > implementation has to handle function pointers, Well that is totally implementation defined. > not how C programmers > might use them in an application program. Okay.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-03 08:08 +0800 |
| Subject | MS-DOS memory models (was: Re: Prioritize Performance over Correctness) |
| Message-ID | <XZQbS.135669$yWz9.4256@fx04.ams4> |
| In reply to | #400718 |
On 03/08/2026 5:37 AM, Chris M. Thomasson wrote:
> On 8/2/2026 2:14 PM, David Brown wrote:
>> On 01/08/2026 10:25, Chris M. Thomasson wrote:
>>> On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
>>>> On 7/30/2026 7:43 PM, Dan Cross wrote:
>>>>> In article <114h1v7$2b0po$2@dont-email.me>,
>>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>>>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote:
>>>>>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
>>>>>>>
>>>>>>>> ... the value of a pointer is the location that it points at. It's
>>>>>>>> value is never a number.
>>>>>>>
>>>>>>> In C, its value is never *directly compatible* with a number.
>>>>>>
>>>>>> Well, uintptr_t?
>>>>>
>>>>> That's a type, not a value.
>>>> Afait uintptr_t can be set to the NULL and any pointer? Then compared?
>>>
>>> I think, humm... uintptr_t can be set to a function pointer as well?
>>
>> You are not making sense here.
>>
>> Any pointer (object pointer or function pointer) can be converted to
>> any integer type. Whether or not the resulting integer value can be
>> converted back to the same pointer is implementation dependent, as is
>> the way the conversions are done.
>
> uintptr_t can help us here. They are very useful.
>
>
>> But /if/ any void* pointer can be converted to an integer type without
>> loss of information, then uintptr_t and intptr_t are unsigned and
>> signed types that can be used for the task.
>
> right.
>
>
>> They may or may not be able to represent function pointers. In
>> practice, on most systems, uintptr_t works for any data or function
>> pointer. But you have to explicitly convert pointers to the uintptr_t
>> integer type.
>>
>
> Can void* always hold a function pointer? I think not. So, that means
> that uintptr_t cannot always hold a function pointer... Right?
Yes, in practice. Everyone has forgotten that the standard verbiage for
allowing function pointers and other pointers to be different was to
account for the different memory models of MS-DOS. Specifically, the
/medium/ memory model was quite popular, and the /compact/ model was
available for the inverse case.
People that need a primer on this subject can just read Raymond
Chen.
https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=104012
>
> However, uintptr_t can always hold a void*
And function pointers, see above.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 10:16 +0200 |
| Message-ID | <114piou$14lmv$2@dont-email.me> |
| In reply to | #400718 |
On 02/08/2026 23:37, Chris M. Thomasson wrote: > On 8/2/2026 2:14 PM, David Brown wrote: >> On 01/08/2026 10:25, Chris M. Thomasson wrote: >>> On 7/30/2026 7:44 PM, Chris M. Thomasson wrote: >>>> On 7/30/2026 7:43 PM, Dan Cross wrote: >>>>> In article <114h1v7$2b0po$2@dont-email.me>, >>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >>>>>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>>>>>> >>>>>>>> ... the value of a pointer is the location that it points at. It's >>>>>>>> value is never a number. >>>>>>> >>>>>>> In C, its value is never *directly compatible* with a number. >>>>>> >>>>>> Well, uintptr_t? >>>>> >>>>> That's a type, not a value. >>>> Afait uintptr_t can be set to the NULL and any pointer? Then compared? >>> >>> I think, humm... uintptr_t can be set to a function pointer as well? >> >> You are not making sense here. >> >> Any pointer (object pointer or function pointer) can be converted to >> any integer type. Whether or not the resulting integer value can be >> converted back to the same pointer is implementation dependent, as is >> the way the conversions are done. > > uintptr_t can help us here. They are very useful. Yes, uintptr_t is the type you want to use if you need to handle an object pointer as an integer. Use it for two reasons. First, if the implementation does not support an integer type big enough to hold a void*, then the type "uintptr_t" will not exist in <stdint.h>. I don't know of any such platforms, but if one is made, then a hard compile-time error is far better than hidden problems. Secondly, assuming the type exists, it is the ideal size for the job. So always use "const uintptr_t address = (uintptr_t) pointer;", rather than using "unsigned long" or other guessed type that will be appropriate on some targets and not others. > > >> But /if/ any void* pointer can be converted to an integer type without >> loss of information, then uintptr_t and intptr_t are unsigned and >> signed types that can be used for the task. > > right. > > >> They may or may not be able to represent function pointers. In >> practice, on most systems, uintptr_t works for any data or function >> pointer. But you have to explicitly convert pointers to the uintptr_t >> integer type. >> > > Can void* always hold a function pointer? I think not. So, that means > that uintptr_t cannot always hold a function pointer... Right? > > However, uintptr_t can always hold a void* That is all correct (if uintptr_t exists, of course). On most targets, function pointers are the same size as void* pointers. But there are exceptions, with some small microcontrollers and DSPs having different kinds of pointers with different sizes, depending on the memory space involved. I have yet to see a situation where there was any reason for storing a function address in a "void*" rather than a more appropriate typedef, such as : typedef void (*FVoid)(void); Function pointers can safely be converted to other function pointer types and back again, as long as you have converted to the correct type before calling the function. You have no such guarantees with void* or uintptr_t for function pointers. (You might occasionally need to convert a function pointer to a specific sized integer type on very low-level code, such as setting up interrupt vector tables - but that is all highly non-portable code.) There have been experimental systems designed with wider pointers for data and functions, where the pointers might not fit in any integer type because they contain information about the range of memory section, or security or access control information. And there are systems (either very old, quite niche DSPs, or some microcontrollers) where pointers to different types of data can have different sizes or contain additional address space, memory bank, or byte offset information. Generally speaking, don't convert pointer types to integers unless you actually need to.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-08-03 10:41 +0100 |
| Message-ID | <114pno3$16g53$1@dont-email.me> |
| In reply to | #400734 |
On 03/08/2026 09:16, David Brown wrote: > On 02/08/2026 23:37, Chris M. Thomasson wrote: >> On 8/2/2026 2:14 PM, David Brown wrote: >>> On 01/08/2026 10:25, Chris M. Thomasson wrote: >>>> On 7/30/2026 7:44 PM, Chris M. Thomasson wrote: >>>>> On 7/30/2026 7:43 PM, Dan Cross wrote: >>>>>> In article <114h1v7$2b0po$2@dont-email.me>, >>>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>>>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >>>>>>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>>>>>>> >>>>>>>>> ... the value of a pointer is the location that it points at. It's >>>>>>>>> value is never a number. >>>>>>>> >>>>>>>> In C, its value is never *directly compatible* with a number. >>>>>>> >>>>>>> Well, uintptr_t? >>>>>> >>>>>> That's a type, not a value. >>>>> Afait uintptr_t can be set to the NULL and any pointer? Then compared? >>>> >>>> I think, humm... uintptr_t can be set to a function pointer as well? >>> >>> You are not making sense here. >>> >>> Any pointer (object pointer or function pointer) can be converted to >>> any integer type. Whether or not the resulting integer value can be >>> converted back to the same pointer is implementation dependent, as is >>> the way the conversions are done. >> >> uintptr_t can help us here. They are very useful. > > Yes, uintptr_t is the type you want to use if you need to handle an > object pointer as an integer. Use it for two reasons. > > First, if the implementation does not support an integer type big enough > to hold a void*, then the type "uintptr_t" will not exist in <stdint.h>. > I don't know of any such platforms, but if one is made, then a hard > compile-time error is far better than hidden problems. > > Secondly, assuming the type exists, it is the ideal size for the job. > > So always use "const uintptr_t address = (uintptr_t) pointer;", rather > than using "unsigned long" or other guessed type that will be > appropriate on some targets and not others. > >> >> >>> But /if/ any void* pointer can be converted to an integer type >>> without loss of information, then uintptr_t and intptr_t are unsigned >>> and signed types that can be used for the task. >> >> right. >> >> >>> They may or may not be able to represent function pointers. In >>> practice, on most systems, uintptr_t works for any data or function >>> pointer. But you have to explicitly convert pointers to the >>> uintptr_t integer type. >>> >> >> Can void* always hold a function pointer? I think not. So, that means >> that uintptr_t cannot always hold a function pointer... Right? >> >> However, uintptr_t can always hold a void* > > That is all correct (if uintptr_t exists, of course). > > On most targets, function pointers are the same size as void* pointers. > But there are exceptions, with some small microcontrollers and DSPs > having different kinds of pointers with different sizes, depending on > the memory space involved. I have yet to see a situation where there > was any reason for storing a function address in a "void*" rather than a > more appropriate typedef, such as : > > typedef void (*FVoid)(void); dlsym requires that pointer-to-function is compatible with a void* > > Function pointers can safely be converted to other function pointer > types and back again, as long as you have converted to the correct type > before calling the function. You have no such guarantees with void* or > uintptr_t for function pointers. > > (You might occasionally need to convert a function pointer to a specific > sized integer type on very low-level code, such as setting up interrupt > vector tables - but that is all highly non-portable code.) > > There have been experimental systems designed with wider pointers for > data and functions, where the pointers might not fit in any integer type > because they contain information about the range of memory section, or > security or access control information. And there are systems (either > very old, quite niche DSPs, or some microcontrollers) where pointers to > different types of data can have different sizes or contain additional > address space, memory bank, or byte offset information. Generally > speaking, don't convert pointer types to integers unless you actually > need to. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 12:28 +0200 |
| Message-ID | <114pqg5$17lne$1@dont-email.me> |
| In reply to | #400736 |
On 03/08/2026 11:41, Richard Harnden wrote: > On 03/08/2026 09:16, David Brown wrote: >> On most targets, function pointers are the same size as void* >> pointers. But there are exceptions, with some small microcontrollers >> and DSPs having different kinds of pointers with different sizes, >> depending on the memory space involved. I have yet to see a situation >> where there was any reason for storing a function address in a "void*" >> rather than a more appropriate typedef, such as : >> >> typedef void (*FVoid)(void); > > dlsym requires that pointer-to-function is compatible with a void* > As I say, I have yet to see a situation where using void* for function pointers was more appropriate than using a function pointer type. If the OS system calls or standard OS libraries makes it a requirement that function pointers are converted to or from void* for some calls, then of course you need to follow those requirements - it's the people who designed the interfaces that made questionable design choices.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-03 19:23 +0800 |
| Subject | Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) |
| Message-ID | <5T_bS.71191$4Fu9.56234@fx05.ams4> |
| In reply to | #400737 |
On 03/08/2026 6:28 PM, David Brown wrote: > On 03/08/2026 11:41, Richard Harnden wrote: >> On 03/08/2026 09:16, David Brown wrote: > >>> On most targets, function pointers are the same size as void* >>> pointers. But there are exceptions, with some small microcontrollers >>> and DSPs having different kinds of pointers with different sizes, >>> depending on the memory space involved. I have yet to see a >>> situation where there was any reason for storing a function address >>> in a "void*" rather than a more appropriate typedef, such as : >>> >>> typedef void (*FVoid)(void); >> >> dlsym requires that pointer-to-function is compatible with a void* >> > > As I say, I have yet to see a situation where using void* for function > pointers was more appropriate than using a function pointer type. If > the OS system calls or standard OS libraries makes it a requirement that > function pointers are converted to or from void* for some calls, then of > course you need to follow those requirements - it's the people who > designed the interfaces that made questionable design choices. > Nope, you're wrong. You're dead wrong. The world isn't built on C, even though here in comp.lang.c we like to pretend it is. Several language environments allow function generation on the fly, these functions need to be garbage collected. Common Lisp is an example, therefore comp.lang.lisp is added to this discussion. I've also added comp.theory so Mild Shock can comment. You will have to go out of your way to make a computer architecture incompatible with garbage collected and heap allocated binary code, something I've been told SBCL does internally [1] to create an archi- tecture that has different * sizeof ( void * ), and * sizeof ( void (*)( void ) ), and when you do that, I'll just claim you're making a /malicious computer architecture/ and refuse to use it. [1] I've not looked at the code, but told the garbage collector can and will at least move the code around, if not collect it. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 14:01 +0200 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114pvvh$17lne$2@dont-email.me> |
| In reply to | #400738 |
On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: Would you /please/ stop adding bunches of random newsgroups to posts? You are making a mess of many newsgroups here, filling them with drivel of no interest to the regulars in the groups. Regulars in comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I presume, care about the theory of computation - not C or Lisp. Usenet groups are not controlled or governed, and no one can stop you making the posts you make. But be very clear on this - your behaviour is seriously anti-social, rude, and counter-productive. A discussion community, such as a Usenet group, "belongs" to the people that follow the group and post there regularly. Filling a group with cross-posts that inevitably fall off-topic is nothing short of vandalism. I am going to make the assumption that your bad habits here are because you genuinely believe the cross-posting to be a good idea and you simply don't understand the consequences, but I sincerely hope that you reconsider. So I will answer your C points below. But you have already alienated several of the C experts in this group - failing to follow the style and standards of a community means you will not get the information or discussions you came here for. If you want to post here on the C language - that would be great, and it's always need to see new people joining in. > On 03/08/2026 6:28 PM, David Brown wrote: >> On 03/08/2026 11:41, Richard Harnden wrote: >>> On 03/08/2026 09:16, David Brown wrote: >> >>>> On most targets, function pointers are the same size as void* >>>> pointers. But there are exceptions, with some small microcontrollers >>>> and DSPs having different kinds of pointers with different sizes, >>>> depending on the memory space involved. I have yet to see a >>>> situation where there was any reason for storing a function address >>>> in a "void*" rather than a more appropriate typedef, such as : >>>> >>>> typedef void (*FVoid)(void); >>> >>> dlsym requires that pointer-to-function is compatible with a void* >>> >> >> As I say, I have yet to see a situation where using void* for function >> pointers was more appropriate than using a function pointer type. If >> the OS system calls or standard OS libraries makes it a requirement >> that function pointers are converted to or from void* for some calls, >> then of course you need to follow those requirements - it's the people >> who designed the interfaces that made questionable design choices. >> > > Nope, you're wrong. You're dead wrong. The world isn't built on C, > even though here in comp.lang.c we like to pretend it is. > You can't jump into a group for a week and pretend to speak for it. People in comp.lang.c do not think the world is built on C - they /know/ that a great deal of key software is built in and on C, they /know/ that a great of cross-language interfaces, APIs, ABIs, and libraries are build around C and C concepts. They know that discussions about C, such as the thread here, are about C. They know that Lisp is not C, nor is C the only programming language, and they know things are done differently in different languages. In C, function pointers and object pointers are different concepts and good design keeps those different concepts separate. Most, but not all, targets for C have a single simple flat memory model in which addresses of data and addresses of code have the same underlying implementation in the hardware - that does not mean it is a good idea to mix these types of pointer at the C language level - especially as there is rarely anything to be gained by it. > Several language environments allow function generation on the fly, > these functions need to be garbage collected. Common Lisp is an > example, therefore comp.lang.lisp is added to this discussion. > Several languages are not C, and are not relevant to C. There are hundreds of real-world programming languages that are not C, and which may or may not allow function generation on the fly - none of them, including Lisp, are relevant here, nor are any of their newsgroups appropriate. And there is no relation between having a common format for data and code pointers, and having support for generating functions at run-time. Python allows run-time function generation, but has no concept of either function pointers or data pointers. C++ allows run-time function generation, but has a clear distinction between data pointers and function pointers (with the same model there as C). > I've also added comp.theory so Mild Shock can comment. Please don't. This is not about computation theory. If someone else wants to join in a C discussion in a C group, talking about C, then that's fine. > > You will have to go out of your way to make a computer architecture > incompatible with garbage collected and heap allocated binary code, > something I've been told SBCL does internally [1] to create an archi- > tecture that has different > > * sizeof ( void * ), and > * sizeof ( void (*)( void ) ), > > and when you do that, I'll just claim you're making a /malicious > computer architecture/ and refuse to use it. > > > [1] I've not looked at the code, but told the garbage collector can > and will at least move the code around, if not collect it. C does not use garbage collection. C does not use "heap allocated binary code". Other languages may do, and may have different ways of addressing or identifying the code. We are talking here about C. And in C, even if function pointers have the same size as void* on most platforms, the two classes of pointers are entirely distinct. You need to go out of your way (via explicit casts) to mix them in some way, and that is very rarely a useful thing to do.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-03 22:52 +0800 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <VW1cS.103376$aXr.29782@fx18.ams4> |
| In reply to | #400739 |
On 03/08/2026 8:01 PM, David Brown wrote: > On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: > > Would you /please/ stop adding bunches of random newsgroups to posts? > You are making a mess of many newsgroups here, filling them with drivel > of no interest to the regulars in the groups. Regulars in > comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I > presume, care about the theory of computation - not C or Lisp. No. The reason being, assholes like Scott Lurndal owe me an apology. There are more of them. When you get the "regulars" to behave like normal human beings, I might too. But that said, none of you know how to behave like regular humans, so why should I bother to respect your "rules." Jut add me to your killfile and be done with it. > > Usenet groups are not controlled or governed, and no one can stop you > making the posts you make. But be very clear on this - your behaviour > is seriously anti-social, rude, and counter-productive. A discussion > community, such as a Usenet group, "belongs" to the people that follow > the group and post there regularly. Filling a group with cross-posts > that inevitably fall off-topic is nothing short of vandalism. I am > going to make the assumption that your bad habits here are because you > genuinely believe the cross-posting to be a good idea and you simply > don't understand the consequences, but I sincerely hope that you > reconsider. So I will answer your C points below. But you have already > alienated several of the C experts in this group - failing to follow the > style and standards of a community means you will not get the > information or discussions you came here for. > No, the "regulars" are extremely anti-social, and quite moronic. You have, over the years, completely ruined your own "space" for conver- sations. I don't need a /C expert/ in my life. I am one. What I need, is at best, humans who know how to be humans. You don't seem to be one, but I'll at least consider to continue to read your reply. > If you want to post here on the C language - that would be great, and > it's always need to see new people joining in. > >> On 03/08/2026 6:28 PM, David Brown wrote: >>> On 03/08/2026 11:41, Richard Harnden wrote: >>>> On 03/08/2026 09:16, David Brown wrote: >>> >>>>> On most targets, function pointers are the same size as void* >>>>> pointers. But there are exceptions, with some small >>>>> microcontrollers and DSPs having different kinds of pointers with >>>>> different sizes, depending on the memory space involved. I have >>>>> yet to see a situation where there was any reason for storing a >>>>> function address in a "void*" rather than a more appropriate >>>>> typedef, such as : >>>>> >>>>> typedef void (*FVoid)(void); >>>> >>>> dlsym requires that pointer-to-function is compatible with a void* >>>> >>> >>> As I say, I have yet to see a situation where using void* for >>> function pointers was more appropriate than using a function pointer >>> type. If the OS system calls or standard OS libraries makes it a >>> requirement that function pointers are converted to or from void* for >>> some calls, then of course you need to follow those requirements - >>> it's the people who designed the interfaces that made questionable >>> design choices. >>> >> >> Nope, you're wrong. You're dead wrong. The world isn't built on C, >> even though here in comp.lang.c we like to pretend it is. >> > > You can't jump into a group for a week and pretend to speak for it. > People in comp.lang.c do not think the world is built on C - they /know/ > that a great deal of key software is built in and on C, they /know/ that > a great of cross-language interfaces, APIs, ABIs, and libraries are > build around C and C concepts. They know that discussions about C, such > as the thread here, are about C. They know that Lisp is not C, nor is C > the only programming language, and they know things are done differently > in different languages. If they don't, why do they act like it? > > In C, function pointers and object pointers are different concepts and > good design keeps those different concepts separate. Most, but not all, > targets for C have a single simple flat memory model in which addresses > of data and addresses of code have the same underlying implementation in > the hardware - that does not mean it is a good idea to mix these types > of pointer at the C language level - especially as there is rarely > anything to be gained by it. > >> Several language environments allow function generation on the fly, >> these functions need to be garbage collected. Common Lisp is an >> example, therefore comp.lang.lisp is added to this discussion. >> > > Several languages are not C, and are not relevant to C. There are > hundreds of real-world programming languages that are not C, and which > may or may not allow function generation on the fly - none of them, > including Lisp, are relevant here, nor are any of their newsgroups > appropriate. You are completely forgetting that many, many languages are implemented in C. Including Appels's Tiger. > > And there is no relation between having a common format for data and > code pointers, and having support for generating functions at run-time. > Python allows run-time function generation, but has no concept of either > function pointers or data pointers. C++ allows run-time function > generation, but has a clear distinction between data pointers and > function pointers (with the same model there as C). I'd like to know, how you intend to implement a heap allocated function, in C, if you cannot just use whatever malloc() returns? > >> I've also added comp.theory so Mild Shock can comment. > > Please don't. This is not about computation theory. If someone else > wants to join in a C discussion in a C group, talking about C, then > that's fine. > We are no longer just talking about C. We are talking about /malicious computer architectures/. >> >> You will have to go out of your way to make a computer architecture >> incompatible with garbage collected and heap allocated binary code, >> something I've been told SBCL does internally [1] to create an archi- >> tecture that has different >> >> * sizeof ( void * ), and >> * sizeof ( void (*)( void ) ), >> >> and when you do that, I'll just claim you're making a /malicious >> computer architecture/ and refuse to use it. >> >> >> [1] I've not looked at the code, but told the garbage collector can >> and will at least move the code around, if not collect it. > > C does not use garbage collection. C does not use "heap allocated > binary code". Other languages may do, and may have different ways of > addressing or identifying the code. We are talking here about C. > > And in C, even if function pointers have the same size as void* on most > platforms, the two classes of pointers are entirely distinct. You need > to go out of your way (via explicit casts) to mix them in some way, and > that is very rarely a useful thing to do. > > Many garbage collectors are implemented in C. Have you used one? -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 19:41 +0200 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114qjs0$1gr0g$1@dont-email.me> |
| In reply to | #400747 |
On 03/08/2026 16:52, Johann 'Myrkraverk' Oskarsson wrote: > On 03/08/2026 8:01 PM, David Brown wrote: >> On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: >> >> Would you /please/ stop adding bunches of random newsgroups to posts? >> You are making a mess of many newsgroups here, filling them with >> drivel of no interest to the regulars in the groups. Regulars in >> comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I >> presume, care about the theory of computation - not C or Lisp. > > No. The reason being, assholes like Scott Lurndal owe me an apology. > > There are more of them. When you get the "regulars" to behave like > normal human beings, I might too. > > But that said, none of you know how to behave like regular humans, > so why should I bother to respect your "rules." > > Jut add me to your killfile and be done with it. > Okay then. I had some hope that you might be able to bring something useful to a conversation, but that hope seems to be in vain. Since you have such a low opinion of this group, and such a high opinion of your own C knowledge, I'd suggest you leave. You don't want to listen to us, and we don't want to listen to you. There is no point in you posting here, except perhaps for petty vindictiveness.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 13:13 -0700 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114qspl$1k97b$2@dont-email.me> |
| In reply to | #400756 |
On 8/3/2026 10:41 AM, David Brown wrote: > On 03/08/2026 16:52, Johann 'Myrkraverk' Oskarsson wrote: >> On 03/08/2026 8:01 PM, David Brown wrote: >>> On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: >>> >>> Would you /please/ stop adding bunches of random newsgroups to posts? >>> You are making a mess of many newsgroups here, filling them with >>> drivel of no interest to the regulars in the groups. Regulars in >>> comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I >>> presume, care about the theory of computation - not C or Lisp. >> >> No. The reason being, assholes like Scott Lurndal owe me an apology. >> >> There are more of them. When you get the "regulars" to behave like >> normal human beings, I might too. >> >> But that said, none of you know how to behave like regular humans, >> so why should I bother to respect your "rules." >> >> Jut add me to your killfile and be done with it. >> > Okay then. > > I had some hope that you might be able to bring something useful to a > conversation, but that hope seems to be in vain. I think so. Plonked the mild shock. I tried as well. > Since you have such a low opinion of this group, and such a high opinion > of your own C knowledge, I'd suggest you leave. You don't want to > listen to us, and we don't want to listen to you. There is no point in > you posting here, except perhaps for petty vindictiveness. I almost have to agree.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 13:10 -0700 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114qsjg$1k97b$1@dont-email.me> |
| In reply to | #400747 |
On 8/3/2026 7:52 AM, Johann 'Myrkraverk' Oskarsson wrote: > On 03/08/2026 8:01 PM, David Brown wrote: >> On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: >> >> Would you /please/ stop adding bunches of random newsgroups to posts? >> You are making a mess of many newsgroups here, filling them with >> drivel of no interest to the regulars in the groups. Regulars in >> comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I >> presume, care about the theory of computation - not C or Lisp. > > No. The reason being, assholes like Scott Lurndal owe me an apology. [...] Oh wow. Are you a sock puppet of the minor shocker? Sigh.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-03 14:29 +0000 |
| Subject | Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) |
| Message-ID | <UA1cS.12216$B3ve.269@fx06.iad> |
| In reply to | #400738 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >On 03/08/2026 6:28 PM, A respected comp.lang.c poster wrote: >Nope, you're wrong. You're dead wrong. The world isn't built on C, >even though here in comp.lang.c we like to pretend it is. Hey dipshit, you're responding to a post in comp.lang.c and cross-posting your reply to other unrelated groups. Please don't do that.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-03 18:10 +0200 |
| Subject | Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) |
| Message-ID | <114qei6$t1uc$1@solani.org> |
| In reply to | #400738 |
Hi, > I've also added comp.theory so Mild Shock can comment. > that has different > * sizeof ( void * ), and > * sizeof ( void (*)( void ) ), Could indicate a data RAM and code ROM model. Which has then the advantage of: Modern operating systems like Windows 11 enforce strict Data Execution Prevention (DEP) (or NX/XD bit security features) to prevent malicious programs from injecting and executing code inside data-only memory regions. https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/ I adopted data RAM and code ROM model for pi-WAM from Hack, which has the same separation: Slide 58, Hack Computer https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view But my motivation was not Johnny Depp prevention. Rather the caching of GPUs. Because WGSL allows storage annotations read_write and read. I use read_write for the data RAM of my Hack VM variant, and read for the code ROM of my Hack VM variant. You can see that here, its open source: @group(0) @binding(0) var<storage, read> code: array<i32>; @group(0) @binding(1) var<storage, read_write> state: array<i32>; 11.4 Giga Lips with a Budget Laptop https://github.com/Jean-Luc-Picard-2021/gigabudget Hope this Helps! Bye Johann 'Myrkraverk' Oskarsson schrieb: > On 03/08/2026 6:28 PM, David Brown wrote: >> On 03/08/2026 11:41, Richard Harnden wrote: >>> On 03/08/2026 09:16, David Brown wrote: >> >>>> On most targets, function pointers are the same size as void* >>>> pointers. But there are exceptions, with some small microcontrollers >>>> and DSPs having different kinds of pointers with different sizes, >>>> depending on the memory space involved. I have yet to see a >>>> situation where there was any reason for storing a function address >>>> in a "void*" rather than a more appropriate typedef, such as : >>>> >>>> typedef void (*FVoid)(void); >>> >>> dlsym requires that pointer-to-function is compatible with a void* >>> >> >> As I say, I have yet to see a situation where using void* for function >> pointers was more appropriate than using a function pointer type. If >> the OS system calls or standard OS libraries makes it a requirement >> that function pointers are converted to or from void* for some calls, >> then of course you need to follow those requirements - it's the people >> who designed the interfaces that made questionable design choices. >> > > Nope, you're wrong. You're dead wrong. The world isn't built on C, > even though here in comp.lang.c we like to pretend it is. > > Several language environments allow function generation on the fly, > these functions need to be garbage collected. Common Lisp is an > example, therefore comp.lang.lisp is added to this discussion. > > I've also added comp.theory so Mild Shock can comment. > > You will have to go out of your way to make a computer architecture > incompatible with garbage collected and heap allocated binary code, > something I've been told SBCL does internally [1] to create an archi- > tecture that has different > > * sizeof ( void * ), and > * sizeof ( void (*)( void ) ), > > and when you do that, I'll just claim you're making a /malicious > computer architecture/ and refuse to use it. > > > [1] I've not looked at the code, but told the garbage collector can > and will at least move the code around, if not collect it.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-03 18:15 +0200 |
| Subject | But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) |
| Message-ID | <114qerq$t244$1@solani.org> |
| In reply to | #400751 |
Hi, Well there are two viewpoint, the "client" of the GPU, which is the CPU, and the "server" of the GPU, which is the command processor queue of the GPU device. So basically as a CPU client I can write the memory area, that is later mapped to my GPU code storage. And this way have a compiler, even written in Prolog, that compiles pi-WAM to my Hack VM, that can then be then deployed to GPU. You could also try the same with a Tiny LISP VM. And a grown up LISP to act as the compiler. Would be a similar exercise. Have Fun! Bye Mild Shock schrieb: > Hi, > > > I've also added comp.theory so Mild Shock can comment. > > > that has different > > * sizeof ( void * ), and > > * sizeof ( void (*)( void ) ), > > Could indicate a data RAM and code ROM model. > Which has then the advantage of: > > Modern operating systems like Windows 11 > enforce strict Data Execution Prevention (DEP) > (or NX/XD bit security features) to prevent > malicious programs from injecting and executing > code inside data-only memory regions. > https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/ > > I adopted data RAM and code ROM model for > pi-WAM from Hack, which has the same separation: > > Slide 58, Hack Computer > https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view > > But my motivation was not Johnny Depp prevention. > Rather the caching of GPUs. Because WGSL > allows storage annotations read_write and > > read. I use read_write for the data RAM > of my Hack VM variant, and read for the > code ROM of my Hack VM variant. You can > > see that here, its open source: > > @group(0) @binding(0) var<storage, read> code: array<i32>; > @group(0) @binding(1) var<storage, read_write> state: array<i32>; > > 11.4 Giga Lips with a Budget Laptop > https://github.com/Jean-Luc-Picard-2021/gigabudget > > Hope this Helps! > > Bye > > Johann 'Myrkraverk' Oskarsson schrieb: >> On 03/08/2026 6:28 PM, David Brown wrote: >>> On 03/08/2026 11:41, Richard Harnden wrote: >>>> On 03/08/2026 09:16, David Brown wrote: >>> >>>>> On most targets, function pointers are the same size as void* >>>>> pointers. But there are exceptions, with some small >>>>> microcontrollers and DSPs having different kinds of pointers with >>>>> different sizes, depending on the memory space involved. I have >>>>> yet to see a situation where there was any reason for storing a >>>>> function address in a "void*" rather than a more appropriate >>>>> typedef, such as : >>>>> >>>>> typedef void (*FVoid)(void); >>>> >>>> dlsym requires that pointer-to-function is compatible with a void* >>>> >>> >>> As I say, I have yet to see a situation where using void* for >>> function pointers was more appropriate than using a function pointer >>> type. If the OS system calls or standard OS libraries makes it a >>> requirement that function pointers are converted to or from void* for >>> some calls, then of course you need to follow those requirements - >>> it's the people who designed the interfaces that made questionable >>> design choices. >>> >> >> Nope, you're wrong. You're dead wrong. The world isn't built on C, >> even though here in comp.lang.c we like to pretend it is. >> >> Several language environments allow function generation on the fly, >> these functions need to be garbage collected. Common Lisp is an >> example, therefore comp.lang.lisp is added to this discussion. >> >> I've also added comp.theory so Mild Shock can comment. >> >> You will have to go out of your way to make a computer architecture >> incompatible with garbage collected and heap allocated binary code, >> something I've been told SBCL does internally [1] to create an archi- >> tecture that has different >> >> * sizeof ( void * ), and >> * sizeof ( void (*)( void ) ), >> >> and when you do that, I'll just claim you're making a /malicious >> computer architecture/ and refuse to use it. >> >> >> [1] I've not looked at the code, but told the garbage collector can >> and will at least move the code around, if not collect it. >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-07 14:37 +0200 |
| Subject | GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) |
| Message-ID | <1154jip$296j$3@solani.org> |
| In reply to | #400752 |
Hi, How it started, NVIDIA being cool: NCCL provides routines such as all-gather, all-reduce, broadcast, reduce, reduce-scatter, and point-to-point send and receive. These routines are optimized to achieve high bandwidth and low latency over PCIe, NVIDIA NVLink™, and other high-speed interconnects within a node and over NVIDIA networking across nodes. https://developer.nvidia.com/nccl How its going, vLLM trying to be cool: [RFC]: Native Weight Syncing APIs However, there are no standardized methods for performing online weight syncing. Open source projects like SkyRL, VeRL, and TRL need to include their own implementations of the weight syncing infrastructure, leading to added complexity for developers seeking to adopt vLLM as their inference server for post-training workloads. https://github.com/vllm-project/vllm/issues/31848 How much Workers are enough? I guess it depends on I/O parallelism, CPU Memory parallelism, CPU Processing parallelism, and now also GPU Memory parallelism and GPU Processing parallelism, and last but least you might have a couple DMAs sitting here and there, or even invoking a sort of RDMA. Quite amazing! Bye Mild Shock schrieb: > Hi, > > Well there are two viewpoint, the "client" > of the GPU, which is the CPU, and the "server" > of the GPU, which is the command processor > > queue of the GPU device. So basically as > a CPU client I can write the memory area, > that is later mapped to my GPU code storage. > > And this way have a compiler, even written > in Prolog, that compiles pi-WAM to my Hack VM, > that can then be then deployed to GPU. > > You could also try the same with a Tiny > LISP VM. And a grown up LISP to act as > the compiler. Would be a similar exercise. > > Have Fun! > > Bye > > Mild Shock schrieb: >> Hi, >> >> > I've also added comp.theory so Mild Shock can comment. >> >> > that has different >> > * sizeof ( void * ), and >> > * sizeof ( void (*)( void ) ), >> >> Could indicate a data RAM and code ROM model. >> Which has then the advantage of: >> >> Modern operating systems like Windows 11 >> enforce strict Data Execution Prevention (DEP) >> (or NX/XD bit security features) to prevent >> malicious programs from injecting and executing >> code inside data-only memory regions. >> https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/ >> >> I adopted data RAM and code ROM model for >> pi-WAM from Hack, which has the same separation: >> >> Slide 58, Hack Computer >> https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view >> >> But my motivation was not Johnny Depp prevention. >> Rather the caching of GPUs. Because WGSL >> allows storage annotations read_write and >> >> read. I use read_write for the data RAM >> of my Hack VM variant, and read for the >> code ROM of my Hack VM variant. You can >> >> see that here, its open source: >> >> @group(0) @binding(0) var<storage, read> code: array<i32>; >> @group(0) @binding(1) var<storage, read_write> state: array<i32>; >> >> 11.4 Giga Lips with a Budget Laptop >> https://github.com/Jean-Luc-Picard-2021/gigabudget >> >> Hope this Helps! >> >> Bye >> >> Johann 'Myrkraverk' Oskarsson schrieb: >>> On 03/08/2026 6:28 PM, David Brown wrote: >>>> On 03/08/2026 11:41, Richard Harnden wrote: >>>>> On 03/08/2026 09:16, David Brown wrote: >>>> >>>>>> On most targets, function pointers are the same size as void* >>>>>> pointers. But there are exceptions, with some small >>>>>> microcontrollers and DSPs having different kinds of pointers with >>>>>> different sizes, depending on the memory space involved. I have >>>>>> yet to see a situation where there was any reason for storing a >>>>>> function address in a "void*" rather than a more appropriate >>>>>> typedef, such as : >>>>>> >>>>>> typedef void (*FVoid)(void); >>>>> >>>>> dlsym requires that pointer-to-function is compatible with a void* >>>>> >>>> >>>> As I say, I have yet to see a situation where using void* for >>>> function pointers was more appropriate than using a function pointer >>>> type. If the OS system calls or standard OS libraries makes it a >>>> requirement that function pointers are converted to or from void* >>>> for some calls, then of course you need to follow those requirements >>>> - it's the people who designed the interfaces that made questionable >>>> design choices. >>>> >>> >>> Nope, you're wrong. You're dead wrong. The world isn't built on C, >>> even though here in comp.lang.c we like to pretend it is. >>> >>> Several language environments allow function generation on the fly, >>> these functions need to be garbage collected. Common Lisp is an >>> example, therefore comp.lang.lisp is added to this discussion. >>> >>> I've also added comp.theory so Mild Shock can comment. >>> >>> You will have to go out of your way to make a computer architecture >>> incompatible with garbage collected and heap allocated binary code, >>> something I've been told SBCL does internally [1] to create an archi- >>> tecture that has different >>> >>> * sizeof ( void * ), and >>> * sizeof ( void (*)( void ) ), >>> >>> and when you do that, I'll just claim you're making a /malicious >>> computer architecture/ and refuse to use it. >>> >>> >>> [1] I've not looked at the code, but told the garbage collector can >>> and will at least move the code around, if not collect it. >> >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-07 18:07 +0200 |
| Subject | What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) |
| Message-ID | <1154vsi$2mto$3@solani.org> |
| In reply to | #400915 |
Hi, Recently there was a paper somebody mentioning a flit doing a ACK or NACK, to express backpressure inside a Network on a Chip. But what is a flit? It seems multiple flits can be used to create the message passing in one directiob before the ACK or NACK in the other direction? "The growing need for performance from computing systems drove the industry into the multi-core and many-core arena. In this setup, the execution of a kernel (a program) is split across multiple processors and the computation happens in parallel Flits represent logical units of information, while phits represent the physical domain, that is, phits represent the number of bits that can be transferred in parallel in a single cycle. Consider the Cray T3D. It has an interconnection network which uses flit level message flow control wherein each flit is composed of eight 16-bit phits. That means its flit size is 128bits and phit size is 16bits. Also consider the IBM SP2 switch. It also uses the flit level message flow control, but its flit size is equal to its phit size, which is set to 8 bits." https://en.wikipedia.org/wiki/Flit_(computer_networking)#Example Well my idea how this is realized in silicon is rather foggy, I mean even the Hack project from Nand 2 Tetris, does not show some gate level schemes for flits and phits. Could be an interesting extension. But somehow the image of flits and phits inspired my channel objects here below. But I am afraid they are fire and forget, no ACK and NACK: π-WAM Contest: 1 Million Packets with Prolog https://medium.com/2989/ec3e91551773 Its amazing that a max_size(1) buffer can beat an unbounded buffer! LoL Bye Mild Shock schrieb: > Hi, > > How it started, NVIDIA being cool: > > NCCL provides routines such as all-gather, > all-reduce, broadcast, reduce, reduce-scatter, > and point-to-point send and receive. These > routines are optimized to achieve high > bandwidth and low latency over PCIe, > NVIDIA NVLink™, and other high-speed > interconnects within a node and over > NVIDIA networking across nodes. > https://developer.nvidia.com/nccl > > How its going, vLLM trying to be cool: > > [RFC]: Native Weight Syncing APIs > However, there are no standardized methods for > performing online weight syncing. Open source projects > like SkyRL, VeRL, and TRL need to include their > own implementations of the weight syncing > infrastructure, leading to added complexity > for developers seeking to adopt vLLM as their > inference server for post-training workloads. > https://github.com/vllm-project/vllm/issues/31848 > > How much Workers are enough? I guess it depends > on I/O parallelism, CPU Memory parallelism, CPU > Processing parallelism, and now also > > GPU Memory parallelism and GPU Processing > parallelism, and last but least you might have > a couple DMAs sitting here and there, > > or even invoking a sort of RDMA. Quite amazing! > > Bye > > Mild Shock schrieb: >> Hi, >> >> Well there are two viewpoint, the "client" >> of the GPU, which is the CPU, and the "server" >> of the GPU, which is the command processor >> >> queue of the GPU device. So basically as >> a CPU client I can write the memory area, >> that is later mapped to my GPU code storage. >> >> And this way have a compiler, even written >> in Prolog, that compiles pi-WAM to my Hack VM, >> that can then be then deployed to GPU. >> >> You could also try the same with a Tiny >> LISP VM. And a grown up LISP to act as >> the compiler. Would be a similar exercise. >> >> Have Fun! >> >> Bye >> >> Mild Shock schrieb: >>> Hi, >>> >>> > I've also added comp.theory so Mild Shock can comment. >>> >>> > that has different >>> > * sizeof ( void * ), and >>> > * sizeof ( void (*)( void ) ), >>> >>> Could indicate a data RAM and code ROM model. >>> Which has then the advantage of: >>> >>> Modern operating systems like Windows 11 >>> enforce strict Data Execution Prevention (DEP) >>> (or NX/XD bit security features) to prevent >>> malicious programs from injecting and executing >>> code inside data-only memory regions. >>> https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/ >>> >>> I adopted data RAM and code ROM model for >>> pi-WAM from Hack, which has the same separation: >>> >>> Slide 58, Hack Computer >>> https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view >>> >>> But my motivation was not Johnny Depp prevention. >>> Rather the caching of GPUs. Because WGSL >>> allows storage annotations read_write and >>> >>> read. I use read_write for the data RAM >>> of my Hack VM variant, and read for the >>> code ROM of my Hack VM variant. You can >>> >>> see that here, its open source: >>> >>> @group(0) @binding(0) var<storage, read> code: array<i32>; >>> @group(0) @binding(1) var<storage, read_write> state: array<i32>; >>> >>> 11.4 Giga Lips with a Budget Laptop >>> https://github.com/Jean-Luc-Picard-2021/gigabudget >>> >>> Hope this Helps! >>> >>> Bye >>> >>> Johann 'Myrkraverk' Oskarsson schrieb: >>>> On 03/08/2026 6:28 PM, David Brown wrote: >>>>> On 03/08/2026 11:41, Richard Harnden wrote: >>>>>> On 03/08/2026 09:16, David Brown wrote: >>>>> >>>>>>> On most targets, function pointers are the same size as void* >>>>>>> pointers. But there are exceptions, with some small >>>>>>> microcontrollers and DSPs having different kinds of pointers with >>>>>>> different sizes, depending on the memory space involved. I have >>>>>>> yet to see a situation where there was any reason for storing a >>>>>>> function address in a "void*" rather than a more appropriate >>>>>>> typedef, such as : >>>>>>> >>>>>>> typedef void (*FVoid)(void); >>>>>> >>>>>> dlsym requires that pointer-to-function is compatible with a void* >>>>>> >>>>> >>>>> As I say, I have yet to see a situation where using void* for >>>>> function pointers was more appropriate than using a function >>>>> pointer type. If the OS system calls or standard OS libraries >>>>> makes it a requirement that function pointers are converted to or >>>>> from void* for some calls, then of course you need to follow those >>>>> requirements - it's the people who designed the interfaces that >>>>> made questionable design choices. >>>>> >>>> >>>> Nope, you're wrong. You're dead wrong. The world isn't built on C, >>>> even though here in comp.lang.c we like to pretend it is. >>>> >>>> Several language environments allow function generation on the fly, >>>> these functions need to be garbage collected. Common Lisp is an >>>> example, therefore comp.lang.lisp is added to this discussion. >>>> >>>> I've also added comp.theory so Mild Shock can comment. >>>> >>>> You will have to go out of your way to make a computer architecture >>>> incompatible with garbage collected and heap allocated binary code, >>>> something I've been told SBCL does internally [1] to create an archi- >>>> tecture that has different >>>> >>>> * sizeof ( void * ), and >>>> * sizeof ( void (*)( void ) ), >>>> >>>> and when you do that, I'll just claim you're making a /malicious >>>> computer architecture/ and refuse to use it. >>>> >>>> >>>> [1] I've not looked at the code, but told the garbage collector can >>>> and will at least move the code around, if not collect it. >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-09 21:22 +0200 |
| Subject | Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) |
| Message-ID | <115ak0p$6g3f$3@solani.org> |
| In reply to | #400917 |
Hi, How it started: Filming a vitamin B12 photoreceptor in action https://www.psi.ch/de/news/science-features/filming-a-vitamin-b12-photoreceptor-in-action How its going: Elon Musk's potential FEL route could challenge EUV lithography https://www.kucoin.com/news/flash/elon-musk-s-potential-fel-route-could-challenge-euv-lithography Who will win the Nano Atom mover race, will the USA OutChip its competitor China and its supplier Asia in the next years? Bye Mild Shock schrieb: > Hi, > > Recently there was a paper somebody mentioning > a flit doing a ACK or NACK, to express > backpressure inside a Network on a Chip. > > But what is a flit? It seems multiple > flits can be used to create the message > passing in one directiob before the > > ACK or NACK in the other direction? > > "The growing need for performance from > computing systems drove the industry into > the multi-core and many-core arena. In this > setup, the execution of a kernel (a program) > is split across multiple processors and the > computation happens in parallel > > Flits represent logical units of information, > while phits represent the physical domain, > that is, phits represent the number of bits > that can be transferred in parallel in a > single cycle. Consider the Cray T3D. It has > an interconnection network which uses > > flit level message flow control wherein each > flit is composed of eight 16-bit phits. That > means its flit size is 128bits and phit size > is 16bits. Also consider the IBM SP2 switch. > It also uses the flit level message flow > control, but its flit size is equal to its > phit size, which is set to 8 bits." > https://en.wikipedia.org/wiki/Flit_(computer_networking)#Example > > Well my idea how this is realized in silicon > is rather foggy, I mean even the Hack project > from Nand 2 Tetris, does not show some gate level > schemes for flits and phits. > > Could be an interesting extension. But somehow > the image of flits and phits inspired my channel > objects here below. But I am afraid they are fire > and forget, no ACK and NACK: > > π-WAM Contest: 1 Million Packets with Prolog > https://medium.com/2989/ec3e91551773 > > Its amazing that a max_size(1) buffer > can beat an unbounded buffer! > > LoL > > Bye > > Mild Shock schrieb: >> Hi, >> >> How it started, NVIDIA being cool: >> >> NCCL provides routines such as all-gather, >> all-reduce, broadcast, reduce, reduce-scatter, >> and point-to-point send and receive. These >> routines are optimized to achieve high >> bandwidth and low latency over PCIe, >> NVIDIA NVLink™, and other high-speed >> interconnects within a node and over >> NVIDIA networking across nodes. >> https://developer.nvidia.com/nccl >> >> How its going, vLLM trying to be cool: >> >> [RFC]: Native Weight Syncing APIs >> However, there are no standardized methods for >> performing online weight syncing. Open source projects >> like SkyRL, VeRL, and TRL need to include their >> own implementations of the weight syncing >> infrastructure, leading to added complexity >> for developers seeking to adopt vLLM as their >> inference server for post-training workloads. >> https://github.com/vllm-project/vllm/issues/31848 >> >> How much Workers are enough? I guess it depends >> on I/O parallelism, CPU Memory parallelism, CPU >> Processing parallelism, and now also >> >> GPU Memory parallelism and GPU Processing >> parallelism, and last but least you might have >> a couple DMAs sitting here and there, >> >> or even invoking a sort of RDMA. Quite amazing! >> >> Bye >> >> Mild Shock schrieb: >>> Hi, >>> >>> Well there are two viewpoint, the "client" >>> of the GPU, which is the CPU, and the "server" >>> of the GPU, which is the command processor >>> >>> queue of the GPU device. So basically as >>> a CPU client I can write the memory area, >>> that is later mapped to my GPU code storage. >>> >>> And this way have a compiler, even written >>> in Prolog, that compiles pi-WAM to my Hack VM, >>> that can then be then deployed to GPU. >>> >>> You could also try the same with a Tiny >>> LISP VM. And a grown up LISP to act as >>> the compiler. Would be a similar exercise. >>> >>> Have Fun! >>> >>> Bye >>> >>> Mild Shock schrieb: >>>> Hi, >>>> >>>> > I've also added comp.theory so Mild Shock can comment. >>>> >>>> > that has different >>>> > * sizeof ( void * ), and >>>> > * sizeof ( void (*)( void ) ), >>>> >>>> Could indicate a data RAM and code ROM model. >>>> Which has then the advantage of: >>>> >>>> Modern operating systems like Windows 11 >>>> enforce strict Data Execution Prevention (DEP) >>>> (or NX/XD bit security features) to prevent >>>> malicious programs from injecting and executing >>>> code inside data-only memory regions. >>>> https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/ >>>> >>>> I adopted data RAM and code ROM model for >>>> pi-WAM from Hack, which has the same separation: >>>> >>>> Slide 58, Hack Computer >>>> https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view >>>> >>>> But my motivation was not Johnny Depp prevention. >>>> Rather the caching of GPUs. Because WGSL >>>> allows storage annotations read_write and >>>> >>>> read. I use read_write for the data RAM >>>> of my Hack VM variant, and read for the >>>> code ROM of my Hack VM variant. You can >>>> >>>> see that here, its open source: >>>> >>>> @group(0) @binding(0) var<storage, read> code: array<i32>; >>>> @group(0) @binding(1) var<storage, read_write> state: array<i32>; >>>> >>>> 11.4 Giga Lips with a Budget Laptop >>>> https://github.com/Jean-Luc-Picard-2021/gigabudget >>>> >>>> Hope this Helps! >>>> >>>> Bye >>>> >>>> Johann 'Myrkraverk' Oskarsson schrieb: >>>>> On 03/08/2026 6:28 PM, David Brown wrote: >>>>>> On 03/08/2026 11:41, Richard Harnden wrote: >>>>>>> On 03/08/2026 09:16, David Brown wrote: >>>>>> >>>>>>>> On most targets, function pointers are the same size as void* >>>>>>>> pointers. But there are exceptions, with some small >>>>>>>> microcontrollers and DSPs having different kinds of pointers >>>>>>>> with different sizes, depending on the memory space involved. I >>>>>>>> have yet to see a situation where there was any reason for >>>>>>>> storing a function address in a "void*" rather than a more >>>>>>>> appropriate typedef, such as : >>>>>>>> >>>>>>>> typedef void (*FVoid)(void); >>>>>>> >>>>>>> dlsym requires that pointer-to-function is compatible with a void* >>>>>>> >>>>>> >>>>>> As I say, I have yet to see a situation where using void* for >>>>>> function pointers was more appropriate than using a function >>>>>> pointer type. If the OS system calls or standard OS libraries >>>>>> makes it a requirement that function pointers are converted to or >>>>>> from void* for some calls, then of course you need to follow those >>>>>> requirements - it's the people who designed the interfaces that >>>>>> made questionable design choices. >>>>>> >>>>> >>>>> Nope, you're wrong. You're dead wrong. The world isn't built on C, >>>>> even though here in comp.lang.c we like to pretend it is. >>>>> >>>>> Several language environments allow function generation on the fly, >>>>> these functions need to be garbage collected. Common Lisp is an >>>>> example, therefore comp.lang.lisp is added to this discussion. >>>>> >>>>> I've also added comp.theory so Mild Shock can comment. >>>>> >>>>> You will have to go out of your way to make a computer architecture >>>>> incompatible with garbage collected and heap allocated binary code, >>>>> something I've been told SBCL does internally [1] to create an archi- >>>>> tecture that has different >>>>> >>>>> * sizeof ( void * ), and >>>>> * sizeof ( void (*)( void ) ), >>>>> >>>>> and when you do that, I'll just claim you're making a /malicious >>>>> computer architecture/ and refuse to use it. >>>>> >>>>> >>>>> [1] I've not looked at the code, but told the garbage collector can >>>>> and will at least move the code around, if not collect it. >>>> >>> >> >
[toc] | [prev] | [next] | [standalone]
Page 6 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