Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.lisp > #61270 > unrolled thread
| Started by | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| First post | 2026-08-03 19:23 +0800 |
| Last post | 2026-08-04 15:10 +0200 |
| Articles | 20 on this page of 86 — 19 participants |
Back to article view | Back to comp.lang.lisp
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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 (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
Re: Malicious Computer Architecture Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:26 -0300
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
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 22:49 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:32 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Anthk GM <anthk@disroot.org> - 2026-09-15 17:10 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 18:08 +0000
You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-09-15 20:21 +0200
Re: You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 20:05 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 02:08 -0400
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-21 15:25 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 16:28 -0400
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:27 +0800
William A. Howard solved all his 99 problems (Re: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-08-23 01:48 +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 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
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:45 +0800
Re: Malicious Computer Architecture Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> - 2026-08-04 18:13 +0000
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:48 +0800
Re: Malicious Computer Architecture Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> - 2026-08-04 22:01 +0000
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 06:25 +0800
GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:37 -0300
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Madhu <enometh@meer.net> - 2026-09-04 08:36 +0530
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-15 12:19 -0300
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Madhu <enometh@meer.net> - 2026-09-17 12:17 +0530
Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-17 21:12 +0000
Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 09:59 -0400
Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-18 22:00 +0000
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 10:12 -0400
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-18 22:01 +0000
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:30 -0400
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 23:50 +0000
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) tfb <tfb@work.it.out> - 2026-10-06 05:11 +0000
Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-10-06 08:30 +0100
Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-19 14:47 +0100
Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-19 21:58 +0000
Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-19 23:24 +0100
Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-19 17:23 -0700
Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-20 03:05 -0400
Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:20 +0000
Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-20 22:20 +0100
Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-20 16:18 -0700
Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-21 12:56 -0400
Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-22 12:22 +0530
Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-22 10:15 -0700
Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-23 07:33 +0530
Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-23 07:22 +0100
Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-24 03:06 -0700
Re: GNU Emacs native compiled functions Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-26 04:45 +0000
Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-27 16:24 +0530
Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-27 15:02 -0700
Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-28 10:53 +0530
Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:47 -0400
Re: GNU Emacs native compiled functions Anton Antimo <anton@safunu.org> - 2026-09-24 10:25 -0300
Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:49 -0400
Re: GNU Emacs native compiled functions Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-23 13:59 +0000
Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:22 +0000
Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-09-24 20:01 +0000
Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-24 20:55 +0000
Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:41 -0400
Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-21 00:18 +0000
Re: GNU Emacs native compiled functions antispam@fricas.org (Waldek Hebisch) - 2026-09-21 19:06 +0000
Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 00:42 +0000
Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:26 +0000
Re: GNU Emacs native compiled functions antispam@fricas.org (Waldek Hebisch) - 2026-09-25 21:54 +0000
Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 20:13 -0400
Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 17:51 +0000
Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:02 +0000
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
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-21 15:25 +0800 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <D3ThS.205749$_cVb.160791@fx11.ams4> |
| In reply to | #61515 |
On 21/08/2026 2:08 PM, George Neuner wrote: > On Tue, 18 Aug 2026 22:49:18 -0000 (UTC), Lawrence D´Oliveiro > <ldo@nz.invalid> wrote: > >> On Tue, 18 Aug 2026 21:13:10 +0100, Aidan Kehoe wrote: >> >>> I coded Prolog in 1998-1999. It is not oriented to the underlying >>> machine in any useful way, and its syntax is not human-friendly. I >>> don’t recommend it. >> >> I did briefly flirt with it, a decade earlier. I found it “very high >> level”, in that its brute-force pattern-matching-plus-backtracking >> execution paradigm was well-suited to solving certain kinds of logic >> problems (it’s in the name of the language after all). Though I guess >> you’d get a blowup in execution time and memory in more complex >> real-world situations. >> >> You know the old “Who Owns The Zebra?” logic puzzle (or some variant >> thereof)? You basically code the given clues directly into Prolog, run >> the result as a program, and out pops the answer. > > If the task involves a rule-based decision system, then Prolog can be > a reasonable tool for the job. But in my experience most Prologs > don't interface well - to the world, or to libraries written in other > languages. > > Prolog uses backward chaining Horn logic - essentially you start with > a [generic] "answer" in the form of a rule and look to see if the rule > can be supported by facts in your database. > > Sometimes you want to work the other way, ie. go forward from facts to > rules that are supported by them. Prolog can't do that. > > > There are plenty of problems that can benefit from a Prolog-style rule > system, but if you need one I think it is better to use an embeddable > implementation, and write your main program in a language that is more > suitable to interfacing with the world. > > There are embeddable Prologs and [Horn logic] workalike libraries > available for a number of languages. Indeed. I recall reading a book that showed how to implement Prolog style logic reasoning in Lisp. Not sure if that was S.I.C.P. Or am I remembering the famous lectures, from the 80s? In any case, implementing Prolog-style rules and then just using them in a larger programming language seemed trivial at the time. I have no practical experience with this, however. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-08-21 16:28 -0400 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <83ah8lphjecqntpehi9rfjk1ct642qcf4t@4ax.com> |
| In reply to | #61517 |
On Fri, 21 Aug 2026 15:25:23 +0800, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 21/08/2026 2:08 PM, George Neuner wrote: > >> There are embeddable Prologs and [Horn logic] workalike libraries >> available for a number of languages. > >Indeed. I recall reading a book that showed how to implement Prolog >style logic reasoning in Lisp. Not sure if that was S.I.C.P. Yes, S.I.C.P. presents a simple implementation of logic processing. [It was targeted to Scheme though - not Lisp]. Far better - and more on topic in C.L.L - is Tanimoto's "The Elements of Artificial Intelligence Using Common Lisp". >Or am I remembering the famous lectures, from the 80s? No doubt you might be. Rule-based decision logic was a hot topic back then. >In any case, implementing Prolog-style rules and then just using them >in a larger programming language seemed trivial at the time. I have >no practical experience with this, however. Horn logic is simple. 8-) What is not so simple is how best to organize the rule-base for rapid searching. Recall that the rule/fact-base is /content/ addressable memory, and that rules can modify it by adding or deleting facts and rules. You might immediately think "well, a hash table is a CAM" - and certainly hash tables will work - but any simple implementation is guaranteed to be poorly performing. Also implementing a fast unification style matcher is a PITA - fortunately there are good match libraries to use. The other hurdle is search backtracking /with cuts/. Backtracking is not difficult, but implementing cuts can be problematic. In Prolog, cuts (the ! operator) prevent backtracking from the cut point - it has the effect of constraining the search to trying to match the current rule [Note that searching / matching the "current rule" still may involve backtracking. Cuts don't stop backtracking, but rather they give the programmer some control over it.]
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-19 08:27 +0800 |
| Subject | Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] |
| Message-ID | <qL6hS.1098978$la89.964421@fx06.ams4> |
| In reply to | #61501 |
On 19/08/2026 4:13 AM, Aidan Kehoe wrote: > > Ar an naoú lá déag de mí Lúnasa, scríobh Johann Oskarsson: > > > On 18/08/2026 10:26 PM, Mild Shock wrote: > > > [...] No Wonder that the EyeProlog "why" feature produces > > > nonsense. Even a Flea circus is less crazy. > > > > Does wearing an eye patch help when writing Prolog? I ask because I > > have never coded any Prolog before. > > I coded Prolog in 1998-1999. It is not oriented to the underlying machine in > any useful way, and its syntax is not human-friendly. I don’t recommend it. Dear Aidan, Thank you for that summary. Now I positively know that I am in no hurry to dabble in Prolog, eye patch or no eye patch; see below. > > > Corollary, since an eye patch would hide my central heterochromia, would > > that not hinder my ability to reason? > > No comment. > This was an oblique and opaque reference to the great literary work of Torako of Japan called /Chuunibyou demo Koi ga Shitai/, or /Love, Chunibyo & Other Delusions/ and while I don't like to link to Wikipedia, it has a picture of the eye patch in question, so you can gaze upon the wonder that is Rikka Taka- nashi, https://en.wikipedia.org/wiki/Love,_Chunibyo_%26_Other_Delusions and I sincerely hope that you consider adding this work of great litera- ture to your no-doubt ever-growing pile of Tsundoku. And unlike the literary work, or anime if you prefer, my central hetero- chromia is not something I can just turn on and off; it's always there. I do not have an /evil eye/, at least in the traditional sense of liter- ary fantasy, but am willing to dabble in evil according to the dogma of the G.N.U. fantasy reality. And on the subject of such evils, you'll see me join the XEmacs list of mails in the near future, so I added comp.emacs.xemacs to this discuss- ion. Best wishes! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-23 01:48 +0200 |
| Subject | William A. Howard solved all his 99 problems (Re: Loderunner Enemy AI better than SWI-Prolog?) |
| Message-ID | <116dcfp$uk0e$3@solani.org> |
| In reply to | #61497 |
Hi, Woa! I am impressed: Howard died in Chicago on March 13, 2026, at the age of 99. https://en.wikipedia.org/wiki/William_Alvin_Howard I recomend every body reading his original Curry-Howard Isomorphism paper. He even mentions sigma types, calling it Strong existence (choice operators): THE FORMULAE-AS-TYPES NOTION OF CONSTRUCTION https://www.cs.cmu.edu/~crary/819-f09/Howard80.pdf Can you derive a Prolog program for proof normalization? A good setting to read the paper is a greek FKK beach. Bye Mild Shock schrieb: > Hi, > > Sometimes I think the Loderunner Enemy AI > was way ahead of its time: > > Lode Runner - Broderbund - 1983 - Apple II > https://www.youtube.com/watch?v=pJZJepU8law > > Meanwhile SWI-Prolog Prologers even don't know > whether a Prolog text is CNF or DNF: > > Sets of rules as conjunctions and/or disjunctions > https://swi-prolog.discourse.group/t/sets-of-rules-as-conjunctions-and-or-disjunctions/9779 > > > No Wonder that the EyeProlog "why" feature produces > nonsense. Even a Flea circus is less crazy. > > Bye > > P.S.: If only there would exist something like > universities where one can take a basic course in > FOL, and then a world wide web, where one can > > lookup clark equational theory, clark completion, > curry howard correspondence, etc.. etc.. > > Mild Shock schrieb: >> Hi, >> >> Obviously to generate AI Surprises, >> you have to stand on the shoulder of >> giants. Otherwise you will not discover >> >> surprises, right? Only mediocre deja vues. >> For this purpose, and maybe otherwise >> related, in a discussion concerning the future >> >> of the library, Marvin Minsky and Edward A. >> Feigenbaum endorsed the idea for books >> to ‘talk to each other’: >> >> LET DOCUMENTS TALK TO EACH OTHER >> Z. CHEN - 1993 >> doi.org/10.1108/eb026910 >> >> Now we have: >> >> THE MACHINES ARE STUDYING >> THE HUMANS ARE SCROLLING >> https://9gag.com/gag/a9yQ16o >> >> Bye >> >> P.S.: But who was Marvin Minsky, and would it >> be important to use symbolic AI? >> >> The Perceptron Controversy >> Yuxi Liu - 2024 >> https://yuxi.ml/essays/perceptron-controversy >> >> Mild Shock schrieb: >>> 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]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-11 16:27 +0200 |
| Subject | The Mac Neo is a Budget Monster [GPU Channels] (Re: What are Flits and Phits? [Network on a Chip]) |
| Message-ID | <115fbgm$9vhm$3@solani.org> |
| In reply to | #61325 |
Hi, Now I implemented some multiple producer and multiple consumer channel objects for WebGPU. The only API to integrate it user facing into pi-WAM is this single predicate: /** * flit(C): * The predicate succeeds in C with a new channel. The channel * can be used from within GPU backed π-WAM logical threads. */ The Mac Neo is a Budget Monster. While the Ryzen AI Laptop cost around 1300.- CHF. The Mac Neo was around 600.- CHF with all extras. Here some performance results, checking out whether channel objects scale, when increasing their number to communicate the same 1 millon packets: Java performance: AI Laptop Single Double Ryzen 705.1 337.4 Neo 669.4 239.9 WebGPU performance: AI Laptop Single Double Ryzen 731.8 392.9 Neo 932.8 483.5 Cool! Java is also pretty cool, their semaphore library is top notch. I couldn't replicate the resulst with JavaScript yet, seems their Atomics.wait() resp. Atomics.waitAsync() is totally broken, using futex is mutex for fools somehow. I also found some gremlins attacking one of the GPUs. The Intel AI Laptop fails the above experiment. Maybe its a driver Vulkan versus OpenCL or something problem, or the Lunar lake architecture is nonsense. 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]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-11 16:51 +0200 |
| Subject | The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels]) |
| Message-ID | <115fcu9$a0tm$1@solani.org> |
| In reply to | #61377 |
Hi, We didn't find yet a library for our Think that would support webgpu on the ARM architecture, so its back to the browser flag and testing there. The node.js package comes only with: dist +-- d3dcompiler_47.dll +-- darwin-universal.dawn.node +-- linux-arm64.dawn.node +-- linux-x64.dawn.node +-- win32-x64.dawn.node Its a similar situation like with SVN. In some communities its not common to provide a ARM build. They rather use x86 till the end of the universe. Although we think initiatives like the x86 Ecosystem Advisory Group could be a clever marketing trick to hide a funeral service. Adding "luminaries" such as Tim Sweeney and Linus Torvald to the panel, is even more so a joke, given that intel produces mutex bottlenecks instead of futex, where f stands for fast, in their GPU infrastructure. So who is the teacher and who are the students? But why even try to create a collation against ARM, it doesn't make any sense. Bye Mild Shock schrieb: > Hi, > > Now I implemented some multiple producer > and multiple consumer channel objects for > WebGPU. The only API to integrate it user > > facing into pi-WAM is this single predicate: > > /** > * flit(C): > * The predicate succeeds in C with a new channel. The channel > * can be used from within GPU backed π-WAM logical threads. > */ > > The Mac Neo is a Budget Monster. While the > Ryzen AI Laptop cost around 1300.- CHF. > The Mac Neo was around 600.- CHF with all > > extras. Here some performance results, > checking out whether channel objects scale, > when increasing their number to > > communicate the same 1 millon packets: > > Java performance: > > AI Laptop Single Double > Ryzen 705.1 337.4 > Neo 669.4 239.9 > > WebGPU performance: > > AI Laptop Single Double > Ryzen 731.8 392.9 > Neo 932.8 483.5 > > Cool! Java is also pretty cool, their > semaphore library is top notch. I couldn't > replicate the resulst with JavaScript yet, > > seems their Atomics.wait() resp. Atomics.waitAsync() > is totally broken, using futex is mutex for > fools somehow. I also found some gremlins > > attacking one of the GPUs. The Intel AI Laptop > fails the above experiment. Maybe its a driver > Vulkan versus OpenCL or something problem, > > or the Lunar lake architecture is nonsense. > > 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]
| From | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| Date | 2026-08-03 19:51 +0100 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <27248.58134.739884.512819@parhasard.net> |
| In reply to | #61270 |
Ar an triú lá de mí Lúnasa, scríobh Johann Oskarsson: > 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. The habit when I read comp.lang.c it was to assert that standard C was all that was worth discussing (yes, yes, it’s phrased as standard C is on topic, everything else isn’t; but there wasn’t the activity in the architecture-specific groups for them to be helpful when I was reading it). This is even more ridiculous; almost all the C infrastructure out there relies on what is undefined behaviour by the letter of the standard. But it’s still C, and it’s worth understanding and worth writing. Oh well, thank you the autoconf maintainers, thank you the cmake maintainers, shame about the difficulty with cross-compiling. > 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 I haven’t gone into the weeds of the GNU Emacs native-compiled function implementation, but it has to be doing something similar. The functions are not in the data segment, they’re not in BSS, they’re not on the stack; that leaves the heap. > * 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. Note that GCC on AMD64 produces function pointers that are one-byte aligned, which to me is a similar philosophy. There cannot be any performance advantage to that. > [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. -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after fourteen pints of stout’ (C. Moore)
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-05 00:22 +0800 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <blocS.832$Be5.329@fx13.ams4> |
| In reply to | #61274 |
On 04/08/2026 2:51 AM, Aidan Kehoe wrote:
Hello Aidan,
We haven't spoken for a long time, and I guess we're moving in different
social circles now.
You will find it amusing that my patch to the FreeBSD kernel, the one
that kind of tunes the TCP/IP stack, is presumably used by Whatsapp as
well.
At least, that's the rumor I heard; I wouldn't know the truth as I don't
work for Whatsapp. I thought only 5ch and Netflix had sites large
enough to make use of it. Well, sites both large enough, and hosted on
FreeBSD.
I promised myself to look into it later, and if I'm right -- at least,
that my patch is still there and all -- I'll let you know.
It's always fun to know that whenever someone streams from Netflix, the
TCP/IP patch I applied is being used; though I cannot say that it
streams through my code; it wasn't that kind of patch.
And I didn't, and don't work for Netflix either.
I hope you're also leaving trails of patches in various operating
systems that everyone on the planet, more or less, makes use of.
>
> Ar an triú lá de mí Lúnasa, scríobh Johann Oskarsson:
>
> > 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.
>
> The habit when I read comp.lang.c it was to assert that standard C was all that
> was worth discussing (yes, yes, it’s phrased as standard C is on topic,
> everything else isn’t; but there wasn’t the activity in the
> architecture-specific groups for them to be helpful when I was reading it).
> This is even more ridiculous; almost all the C infrastructure out there relies
> on what is undefined behaviour by the letter of the standard. But it’s still C,
> and it’s worth understanding and worth writing.
Yes, I remember that. I believe I came across a FAQ, probably comp.os.
msdos.programmer, that said because comp.lang.c was full of standard
thumping trolls, a lot of regular programming, even Win32 got discussed
there. Yes, I'll quote.
> Why does the newsgroup seem to be so C-oriented sometimes?
> There are two reasons. First, comp.lang.c and
> comp.lang.pascal have evolved in different
> directions. Comp.lang.pascal has split into discussions
> about individual Pascal compilers. comp.lang.pascal.borland
> welcomes discussion specific to Turbo Pascal, and the other
> new groups likewise. Turbo Pascal programmers tend to find
> DOS questions welcomed in comp.lang.pascal.borland, so that
> comp.os.msdos.programmer gets less of the "DOS in Turbo
> Pascal" traffic. On the other hand, comp.lang.c has stayed
> closer to talking only about the C language, and
> vendor-specific or operating-system-specific questions are
> not welcome. This tends to push questions about disks, DOS
> file structure, video, the keyboard, TSRs, etc. to
> comp.os.msdos.programmer even when those programs are
> written in C.
So my take on it, is that the standard thumping trolls in comp.lang.c
were already a problem in the 90s. They just didn't know it, didn't
care, and nobody challenged them about it. Until now.
I am challenging their rule. And they can whine, and they can bluster,
but nobody cares about their mistaken sense of prestige and power.
They claim my cross posting is annoying. As far as I'm aware, I'm
basically screaming into the void with my cross posts, because there
isn't enough traffic in the other groups to warrant complaints about it.
>
> Oh well, thank you the autoconf maintainers, thank you the cmake maintainers,
> shame about the difficulty with cross-compiling.
On that subject, I have to agree. I've largely given up on both for my
own projects. The problems with these tools isn't when they work, it's
when they don't. It can be a nightmare to get to the first build on a
platform where the build system doesn't work.
I currently believe both tools make porting to a /different enough
platform/ basically impossible. And that's based on hard earned
experience.
>
> > 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
>
> I haven’t gone into the weeds of the GNU Emacs native-compiled function
> implementation, but it has to be doing something similar. The functions are not
> in the data segment, they’re not in BSS, they’re not on the stack; that leaves
> the heap.
And not to mention the operating system interfaces. I'll name mmap(),
and Win32 has its equivalent, and while I'm not sure, OpenVMS might be
different too.
All of them return the equivalent of void *. So what are the program-
mers of the JVM, CLR, and other virtual machines to do? They'll have
to rely on this "undefined behaviour."
>
> > * 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.
>
> Note that GCC on AMD64 produces function pointers that are one-byte aligned,
> which to me is a similar philosophy. There cannot be any performance advantage
> to that.
Can you please expand on that? I'm not sure what you mean, and I hope
it doesn't create function pointers at strictly odd addresses, because
that's what it sounds like to me.
>
> > [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.
>
Best wishes, and happy XEmacs coding!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-08-04 19:10 +0100 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114t9u9$2c1qh$1@dont-email.me> |
| In reply to | #61279 |
On 04/08/2026 17:22, Johann 'Myrkraverk' Oskarsson wrote: > And not to mention the operating system interfaces. I'll name mmap(), > and Win32 has its equivalent, and while I'm not sure, OpenVMS might be > different too. > > All of them return the equivalent of void *. So what are the program- > mers of the JVM, CLR, and other virtual machines to do? They'll have > to rely on this "undefined behaviour." I suspect its because I'm not a genius like you, but ... malloc(3) also returns a void* and that is perfectly well defined, is used everywhere and never caused anybody any problems. ... it seems to me you are, as usual, talking bollocks.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-08-06 21:55 +0000 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <20260806143922.203@kylheku.com> |
| In reply to | #61279 |
On 2026-08-04, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: > Yes, I remember that. I believe I came across a FAQ, probably comp.os. > msdos.programmer, that said because comp.lang.c was full of standard > thumping trolls, a lot of regular programming, even Win32 got discussed > there. Yes, I'll quote. I don't believe that only standard C should be discussed in comp.lang.c. There is room for dialects. E.g. GNU C is C. Once we are in the weeds of a platform specific kernel function that can do anything whatsoever, the discussion of what it does doesn't relate to C. You can call it out of assembly language or Fortran; it doesn't matter. Standard thumping and standard thumpers are useful, because it is usually good to be informed about whether something we are doing in the code is required to work, by the standard, or not. (If not, then by what: by what requirements, or else theory of operation, is it assured that the code works as believed.) Sometimes standard thumpers can point out a standard-conforming way of doing something that has no disadvantages, or at least few disadvantages, compared to the nonstandard way being presented. C is a very unsafe language; a program that compiles with silence at the highest diagnostic level of your compiler of choice could have serious flaws. The standard is the primary (though not the only) source that informs the scrutiny of C programs for undiagnosed/undiagnosable problems. > So my take on it, is that the standard thumping trolls in comp.lang.c > were already a problem in the 90s. They just didn't know it, didn't > care, and nobody challenged them about it. Until now. On the contrary, standard-thumping in comp.lang.c has been regularly challenged for decades by numerous visitors; everyone who tried it so far bounced off, and came down with an unpleasant bump. :) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-07 06:31 +0800 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <8X7dS.14$354.9@fx13.ams4> |
| In reply to | #61310 |
On 07/08/2026 5:55 AM, Kaz Kylheku wrote: > On 2026-08-04, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: Dear Kaz, I'll let you have the final word on what you said in you previous post, and not comment further on the things I snipped from this one. >> So my take on it, is that the standard thumping trolls in comp.lang.c >> were already a problem in the 90s. They just didn't know it, didn't >> care, and nobody challenged them about it. Until now. > > On the contrary, standard-thumping in comp.lang.c has been regularly > challenged for decades by numerous visitors; everyone who tried it so > far bounced off, and came down with an unpleasant bump. :) > Thank you for the warning. I'll endeavour not to run out of stamina, and plan to spend my attribute points in stamina on my next level up. These standard thumping trolls do need to be challanged, and right- fully so. There are ways to do it, and there are ways that -- result in failure. I hope my method will be a success, and we'll know in a few years how well I did. Thanks to disbelief in me, I have added surrealism to my attack vector, and that irritates the standard thumping trolls even further. And it makes me happier. Good luck, and happy C compiling! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| Date | 2026-08-06 23:01 +0100 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <27253.1071.416806.842336@parhasard.net> |
| In reply to | #61279 |
Ar an cúigiú lá de mí Lúnasa, scríobh Johann Oskarsson: > On 04/08/2026 2:51 AM, Aidan Kehoe wrote: > > Hello Aidan, > > We haven't spoken for a long time, and I guess we're moving in different > social circles now. I spent 2012-present debugging people, and until 2021ish without the time away from that to maintain a social circle or do any XEmacs work. My social circle just shrank! > You will find it amusing that my patch to the FreeBSD kernel, the one > that kind of tunes the TCP/IP stack, is presumably used by Whatsapp as > well. > > At least, that's the rumor I heard; I wouldn't know the truth as I don't > work for Whatsapp. I thought only 5ch and Netflix had sites large > enough to make use of it. Well, sites both large enough, and hosted on > FreeBSD. > > I promised myself to look into it later, and if I'm right -- at least, > that my patch is still there and all -- I'll let you know. Good. > It's always fun to know that whenever someone streams from Netflix, the > TCP/IP patch I applied is being used; though I cannot say that it > streams through my code; it wasn't that kind of patch. > > And I didn't, and don't work for Netflix either. > > I hope you're also leaving trails of patches in various operating > systems that everyone on the planet, more or less, makes use of. There’s enough to do with XEmacs plus running a business plus a three year old daughter plus a fiancée, that I don’t anticipate any OS patches from me this decade. Still, I save lives, and more importantly, prevent large strokes. > > Ar an triú lá de mí Lúnasa, scríobh Johann Oskarsson: > > > > > 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. > > > > The habit when I read comp.lang.c it was to assert that standard C was > > all that was worth discussing (yes, yes, it’s phrased as standard C is on > > topic, everything else isn’t; but there wasn’t the activity in the > > architecture-specific groups for them to be helpful when I was reading > > it). This is even more ridiculous; almost all the C infrastructure out > > there relies on what is undefined behaviour by the letter of the > > standard. But it’s still C, and it’s worth understanding and worth > > writing. > > Yes, I remember that. I believe I came across a FAQ, probably comp.os. > msdos.programmer, that said because comp.lang.c was full of standard > thumping trolls, a lot of regular programming, even Win32 got discussed > there. Yes, I'll quote. > > > Why does the newsgroup seem to be so C-oriented sometimes? > > There are two reasons. First, comp.lang.c and > > comp.lang.pascal have evolved in different > > directions. Comp.lang.pascal has split into discussions > > about individual Pascal compilers. comp.lang.pascal.borland > > welcomes discussion specific to Turbo Pascal, and the other > > new groups likewise. Turbo Pascal programmers tend to find > > DOS questions welcomed in comp.lang.pascal.borland, so that > > comp.os.msdos.programmer gets less of the "DOS in Turbo > > Pascal" traffic. On the other hand, comp.lang.c has stayed > > closer to talking only about the C language, and > > vendor-specific or operating-system-specific questions are > > not welcome. This tends to push questions about disks, DOS > > file structure, video, the keyboard, TSRs, etc. to > > comp.os.msdos.programmer even when those programs are > > written in C. > > So my take on it, is that the standard thumping trolls in comp.lang.c were > already a problem in the 90s. They just didn't know it, didn't care, and > nobody challenged them about it. Until now. Most of my comp.lang.c was the turn of the millennium. I don’t have the desire or spare time at the moment to read more newsgroups, and I’m happy with my command of C. > I am challenging their rule. And they can whine, and they can bluster, > but nobody cares about their mistaken sense of prestige and power. > > They claim my cross posting is annoying. As far as I'm aware, I'm > basically screaming into the void with my cross posts, because there > isn't enough traffic in the other groups to warrant complaints about it. Fight on! Alternatively put the time into XEmacs (or packages) work, which is, a better use of your time. (From my perspective, and probably in the grand scheme of things; neither of is likely to make any difference to comp.lang.c.) > > Oh well, thank you the autoconf maintainers, thank you the cmake > > maintainers, shame about the difficulty with cross-compiling. > > On that subject, I have to agree. I've largely given up on both for my own > projects. The problems with these tools isn't when they work, it's when they > don't. It can be a nightmare to get to the first build on a platform where > the build system doesn't work. Well, it’s just one more platform to learn. I would love to move XEmacs to cmake, given it would unify the POSIX and Windows build systems, but it would be a huge investment of time to port it over, because I know autoconf but I don’t know cmake. > I currently believe both tools make porting to a /different enough platform/ > basically impossible. And that's based on hard earned experience. My understanding is that cmake just requires a C compiler, no shell, no other dependencies, so it should manage a different enough platform that has a C compiler without problems. This is its attraction over autoconf, which requires /bin/sh at least, and pragmatically more of POSIX. > > > 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 > > > > I haven’t gone into the weeds of the GNU Emacs native-compiled function > > implementation, but it has to be doing something similar. The functions > > are not in the data segment, they’re not in BSS, they’re not on the > > stack; that leaves the heap. > > And not to mention the operating system interfaces. I'll name mmap(), > and Win32 has its equivalent, and while I'm not sure, OpenVMS might be > different too. > > All of them return the equivalent of void *. So what are the programmers of > the JVM, CLR, and other virtual machines to do? They'll have to rely on > this "undefined behaviour." Well, they have to port to the various platforms, that’s all. And hope the platform defines the behaviour. > > > > > * 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. > > > > Note that GCC on AMD64 produces function pointers that are one-byte > > aligned, which to me is a similar philosophy. There cannot be any > > performance advantage to that. > > Can you please expand on that? I'm not sure what you mean, and I hope > it doesn't create function pointers at strictly odd addresses, because > that's what it sounds like to me. https://lidell.nu/xemacs-buildbot/#/builders/14/builds/690 throws an assertion failure because I was storing a function pointer into a Lisp fixnum, which has 63 bits of precision. The least significant bit of the function pointer was set. -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after fourteen pints of stout’ (C. Moore)
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-07 06:45 +0800 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <888dS.56032$1xtd.3908@fx01.ams4> |
| In reply to | #61311 |
On 07/08/2026 6:01 AM, Aidan Kehoe wrote: > > Ar an cúigiú lá de mí Lúnasa, scríobh Johann Oskarsson: > > > On 04/08/2026 2:51 AM, Aidan Kehoe wrote: > > > > Hello Aidan, > > > > We haven't spoken for a long time, and I guess we're moving in different > > social circles now. > > I spent 2012-present debugging people, and until 2021ish without the time away > from that to maintain a social circle or do any XEmacs work. My social circle > just shrank! > > > You will find it amusing that my patch to the FreeBSD kernel, the one > > that kind of tunes the TCP/IP stack, is presumably used by Whatsapp as > > well. > > > > At least, that's the rumor I heard; I wouldn't know the truth as I don't > > work for Whatsapp. I thought only 5ch and Netflix had sites large > > enough to make use of it. Well, sites both large enough, and hosted on > > FreeBSD. > > > > I promised myself to look into it later, and if I'm right -- at least, > > that my patch is still there and all -- I'll let you know. > > Good. > > > It's always fun to know that whenever someone streams from Netflix, the > > TCP/IP patch I applied is being used; though I cannot say that it > > streams through my code; it wasn't that kind of patch. > > > > And I didn't, and don't work for Netflix either. > > > > I hope you're also leaving trails of patches in various operating > > systems that everyone on the planet, more or less, makes use of. > > There’s enough to do with XEmacs plus running a business plus a three year old > daughter plus a fiancée, that I don’t anticipate any OS patches from me this > decade. Still, I save lives, and more importantly, prevent large strokes. Welcome to the happy family life. I wish you all the success with it! > > > > Ar an triú lá de mí Lúnasa, scríobh Johann Oskarsson: > > > > > > > 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. > > > > > > The habit when I read comp.lang.c it was to assert that standard C was > > > all that was worth discussing (yes, yes, it’s phrased as standard C is on > > > topic, everything else isn’t; but there wasn’t the activity in the > > > architecture-specific groups for them to be helpful when I was reading > > > it). This is even more ridiculous; almost all the C infrastructure out > > > there relies on what is undefined behaviour by the letter of the > > > standard. But it’s still C, and it’s worth understanding and worth > > > writing. > > > > Yes, I remember that. I believe I came across a FAQ, probably comp.os. > > msdos.programmer, that said because comp.lang.c was full of standard > > thumping trolls, a lot of regular programming, even Win32 got discussed > > there. Yes, I'll quote. > > > > > Why does the newsgroup seem to be so C-oriented sometimes? > > > There are two reasons. First, comp.lang.c and > > > comp.lang.pascal have evolved in different > > > directions. Comp.lang.pascal has split into discussions > > > about individual Pascal compilers. comp.lang.pascal.borland > > > welcomes discussion specific to Turbo Pascal, and the other > > > new groups likewise. Turbo Pascal programmers tend to find > > > DOS questions welcomed in comp.lang.pascal.borland, so that > > > comp.os.msdos.programmer gets less of the "DOS in Turbo > > > Pascal" traffic. On the other hand, comp.lang.c has stayed > > > closer to talking only about the C language, and > > > vendor-specific or operating-system-specific questions are > > > not welcome. This tends to push questions about disks, DOS > > > file structure, video, the keyboard, TSRs, etc. to > > > comp.os.msdos.programmer even when those programs are > > > written in C. > > > > So my take on it, is that the standard thumping trolls in comp.lang.c were > > already a problem in the 90s. They just didn't know it, didn't care, and > > nobody challenged them about it. Until now. > > Most of my comp.lang.c was the turn of the millennium. I don’t have the > desire or spare time at the moment to read more newsgroups, and I’m happy with > my command of C. I've only increased my knowledge of C over the past few years. And since I also want to teach it -- and I've done a stint of both paid and unpaid tutorship of it -- I've amassed a decent library of beginners books, in addition to the more advanced topics. There are still nooks and crannies I've questioned recently, and I believe some of my experiments warrant yet another beginners book. We'll just have to see if I'll write one, as I'm also not in a hurry about that. > > > I am challenging their rule. And they can whine, and they can bluster, > > but nobody cares about their mistaken sense of prestige and power. > > > > They claim my cross posting is annoying. As far as I'm aware, I'm > > basically screaming into the void with my cross posts, because there > > isn't enough traffic in the other groups to warrant complaints about it. > > Fight on! Alternatively put the time into XEmacs (or packages) work, which is, > a better use of your time. (From my perspective, and probably in the grand > scheme of things; neither of is likely to make any difference to comp.lang.c.) XEmacs wasn't on my horizon until I started to write this reply. I'm not sure how I can be immediately useful, but I'll do my best to at least help out with the little tasks. See you on the XEmacs devel list about more of that, and you'll know when I've started to read it again. I'll reply to something. > > > > Oh well, thank you the autoconf maintainers, thank you the cmake > > > maintainers, shame about the difficulty with cross-compiling. > > > > On that subject, I have to agree. I've largely given up on both for my own > > projects. The problems with these tools isn't when they work, it's when they > > don't. It can be a nightmare to get to the first build on a platform where > > the build system doesn't work. > > Well, it’s just one more platform to learn. I would love to move XEmacs to > cmake, given it would unify the POSIX and Windows build systems, but it would > be a huge investment of time to port it over, because I know autoconf but I > don’t know cmake. Sometimes it's better to /boot strap/ the code, and just compile things by hand for the first time. I've done that for some projects, but others are harder to figure out. I'll just point to my recent effort to hand build the Korn shell in comp.unix.shell; which I'm sure you won't read, having a full life and all. > > > I currently believe both tools make porting to a /different enough platform/ > > basically impossible. And that's based on hard earned experience. > > My understanding is that cmake just requires a C compiler, no shell, no other > dependencies, so it should manage a different enough platform that has a C > compiler without problems. This is its attraction over autoconf, which > requires /bin/sh at least, and pragmatically more of POSIX. Way back when, when cmake was new, they didn't support cross compiling. And that made me write it off. Since then, it's become more complex, and I'm not sure it's well suited to my own projects. At work, I just use what they use there. > > > > > 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 > > > > > > I haven’t gone into the weeds of the GNU Emacs native-compiled function > > > implementation, but it has to be doing something similar. The functions > > > are not in the data segment, they’re not in BSS, they’re not on the > > > stack; that leaves the heap. > > > > And not to mention the operating system interfaces. I'll name mmap(), > > and Win32 has its equivalent, and while I'm not sure, OpenVMS might be > > different too. > > > > All of them return the equivalent of void *. So what are the programmers of > > the JVM, CLR, and other virtual machines to do? They'll have to rely on > > this "undefined behaviour." > > Well, they have to port to the various platforms, that’s all. And hope the > platform defines the behaviour. > > > > > > > * 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. > > > > > > Note that GCC on AMD64 produces function pointers that are one-byte > > > aligned, which to me is a similar philosophy. There cannot be any > > > performance advantage to that. > > > > Can you please expand on that? I'm not sure what you mean, and I hope > > it doesn't create function pointers at strictly odd addresses, because > > that's what it sounds like to me. > > https://lidell.nu/xemacs-buildbot/#/builders/14/builds/690 throws an assertion > failure because I was storing a function pointer into a Lisp fixnum, which has > 63 bits of precision. The least significant bit of the function pointer was > set. > I hope you figure it out. Right now, I have n+1 projects cooking, and I'm not in a hurry to help with XEmacs. Best of luck with your new life! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> |
|---|---|
| Date | 2026-08-04 18:13 +0000 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114ta3r$eljg$1@paganini.bofh.team> |
| In reply to | #61274 |
|-------------------------------------------------------------------------------| |"Ar an triú lá de mí Lúnasa, scríobh Johann Oskarsson: | |[. . .] | |The habit when I read comp.lang.c it was to assert that standard C was all that| |was worth discussing (yes, yes, it’s phrased as standard C is on topic, | |everything else isn’t; but there wasn’t the activity in the | |architecture-specific groups for them to be helpful when I was reading it). | |This is even more ridiculous; almost all the C infrastructure out there relies | |on what is undefined behaviour by the letter of the standard." | |-------------------------------------------------------------------------------| arsa Aodhán ua Ceothánaigh ar an 3ú lá de mhí Lúnasa 2026. "I finally prepared another fossil for museum exhibition: from DECtapes written in 1972-73, there are exhumed C compilers (including source) to show what the very early stages of the language were like. This was a highly transitional stage; for example, the earlier one anticipates a "long" type, but doesn't have struct; the 6-months-later compiler implements struct, but reuses long's slot in the type table. http://www.cs.bell-labs.com/~dmr/primevalC.html Dennis" arsa fear ar an 29ú lá de mhí Iúil 1999. "DECtapes are highly platform specific, and are not covered by ANSI C, which is the subject of this newsgroup (comp.lang.c). Try a DEC-related newsgroup. If you want us to comment on your source code, please post it in the body of your email. What was your C question? -- Richard Heathfield The bug stops here." arsa neach. "Usenet is a strange place." arsa fear. Scríobh mise r-phost duit faoi dheirfiúr daoibh i rith na Bliana 2001 agus scríobh tusa freagra dhom. |-------------------------------------------------------------------------------| |"But it’s still C, | |and it’s worth understanding and worth writing." | |-------------------------------------------------------------------------------| arsa Aodh Pól ua Ciothaigh. Is fiú cacanna C. Is mise le meas, Nioclás Pól Caileán de Ghloucester (S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-05 03:48 +0800 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <qmrcS.91228$4Fu9.17576@fx05.ams4> |
| In reply to | #61281 |
On 05/08/2026 2:13 AM, Niocláisín Cóilín de Ghlostéir wrote: > |-------------------------------------------------------------------------------| > |"Ar an triú lá de mí Lúnasa, scríobh Johann Oskarsson: | > |[. . .] | > |The habit when I read comp.lang.c it was to assert that standard C was all that| > |was worth discussing (yes, yes, it’s phrased as standard C is on topic, | > |everything else isn’t; but there wasn’t the activity in the | > |architecture-specific groups for them to be helpful when I was reading it). | > |This is even more ridiculous; almost all the C infrastructure out there relies | > |on what is undefined behaviour by the letter of the standard." | > |-------------------------------------------------------------------------------| > arsa Aodhán ua Ceothánaigh ar an 3ú lá de mhí Lúnasa 2026. > > "I finally prepared another fossil for museum exhibition: from DECtapes > written > in 1972-73, there are exhumed C compilers (including source) to show > what > the very early stages of the language were like. This was a highly > transitional stage; for example, the earlier one anticipates a "long" > type, but doesn't have struct; the 6-months-later compiler implements > struct, but reuses long's slot in the type table. > http://www.cs.bell-labs.com/~dmr/primevalC.html > > Dennis" > arsa fear ar an 29ú lá de mhí Iúil 1999. > > "DECtapes are highly platform specific, and are not covered by ANSI C, which > is the subject of this newsgroup (comp.lang.c). Try a DEC-related > newsgroup. > > If you want us to comment on your source code, please post it in the body > of your email. > > What was your C question? > So if I'm reading this right, you're posting exclusively to comp.lang. lisp, and comp.theory; and leaving out comp.lang.c as a sign of pro- test. I can respect that. Yes, this is exactly the kind of problematic behaviour I'm talking about. It's not just comp.lang.c. Here is a twelve minute documentary about how this problem has infected /Stack Overflow/ as well. https://www.youtube.com/watch?v=IbDAmvUwo5c Let's enjoy this moment without any standard thumping trolls! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social
[toc] | [prev] | [next] | [standalone]
| From | Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> |
|---|---|
| Date | 2026-08-04 22:01 +0000 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114tng9$fl0o$1@paganini.bofh.team> |
| In reply to | #61283 |
Johann 'Myrkraverk' Oskarsson <johann@Myrkraverk.invalid> skrev: |-----------------------------------------------------------------------| |"So if I'm reading this right, you're posting exclusively to comp.lang.| |lisp, and comp.theory; and leaving out comp.lang.c as a sign of pro- | |test. [. . .]" | |-----------------------------------------------------------------------| Det stämmer inte! I use news servers which tend to restrict a post to 2 newsgroups. Sorry! A few times I wrote explanations e.g. in January: "I am sorry that this crossposting is to only 2 groups. I am sending via a server which does not allow a crosspost to many groups. It or Tin also forbids many groups in a Followup-To: field." I stopped writing such explanations. Maybe I should not have stopped! (S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-05 06:25 +0800 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <5FtcS.81453$la89.45617@fx06.ams4> |
| In reply to | #61285 |
On 05/08/2026 6:01 AM, Niocláisín Cóilín de Ghlostéir wrote: > Johann 'Myrkraverk' Oskarsson <johann@Myrkraverk.invalid> skrev: > |-----------------------------------------------------------------------| > |"So if I'm reading this right, you're posting exclusively to comp.lang.| > |lisp, and comp.theory; and leaving out comp.lang.c as a sign of pro- | > |test. [. . .]" | > |-----------------------------------------------------------------------| > > Det stämmer inte! I use news servers which tend to restrict a post to > 2 newsgroups. Sorry! A few times I wrote explanations e.g. in January: > "I am sorry that this crossposting is to only 2 groups. I am sending > via a server which does not allow a crosspost to many groups. It or > Tin also forbids many groups in a Followup-To: field." > > I stopped writing such explanations. Maybe I should not have stopped! > (S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!) It's fine. comp.lang.c didn't need to read my reply. And you keep on crossposting as you see fit; which means just two groups. I have no problem with it, I just misunderstood your intentions. Have a nice Lispy day! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social
[toc] | [prev] | [next] | [standalone]
| From | Kragen Javier Sitaker <kragen@canonical.org> |
|---|---|
| Date | 2026-09-03 14:37 -0300 |
| Subject | GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) |
| Message-ID | <87v78mz15a.fsf_-_@debian> |
| In reply to | #61274 |
Aidan Kehoe <kehoea@parhasard.net> writes:
> I haven’t gone into the weeds of the GNU Emacs native-compiled function
> implementation, but it has to be doing something similar. The functions are not
> in the data segment, they’re not in BSS, they’re not on the stack; that leaves
> the heap.
On amd64, at least, instead of running them from a heap, it seems to be
compiling elisp into .so files which it can then dlopen(), but it names
them `*.eln` instead of `*.so`:
: ~; shuf -n 8 /proc/$(pidof emacs)/maps
7f44e7cb3000-7f44e7cb4000 r--p 00005000 fe:01 1216485 /usr/lib/x86_64-linux-gnu/libgpm.so.2
7f44e8e34000-7f44e8e47000 r--p 00000000 fe:01 1212779 /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.5000.12
7f44c4151000-7f44c4154000 rw-p 00005000 fe:05 1323730 /home/user/.emacs.d/eln-cache/28.2-66fa0d00/nxml-parse-79a53381-b87f8800.eln
7f44c74a5000-7f44c74bb000 rw-p 00006000 fe:05 1320433 /home/user/.emacs.d/eln-cache/28.2-66fa0d00/cc-vars-6cc3f0fc-a4ab31d9.eln
7f44c544e000-7f44c5458000 rw-p 0000b000 fe:05 1323563 /home/user/.emacs.d/eln-cache/28.2-66fa0d00/with-editor-ad819b7b-2e1f7b93.eln
7f44c5383000-7f44c5384000 r--p 0000d000 fe:05 1321666 /home/user/.emacs.d/eln-cache/28.2-66fa0d00/log-edit-bc58b2d4-860d5c35.eln
7f44c52f5000-7f44c52f8000 r--p 00021000 fe:05 1323613 /home/user/.emacs.d/eln-cache/28.2-66fa0d00/magit-log-ffefa368-c52fff03.eln
7f44c50a5000-7f44c50a8000 r-xp 00001000 fe:05 1321734 /home/user/.emacs.d/eln-cache/28.2-66fa0d00/xdg-9947111f-70cd76a9.eln
: ~; file /home/user/.emacs.d/eln-cache/28.2-66fa0d00/nxml-parse-79a53381-b87f8800.eln /home/user/.emacs.d/eln-cache/28.2-66fa0d00/cc-vars-6cc3f0fc-a4ab31d9.eln /home/user/.emacs.d/eln-cache/28.2-66fa0d00/with-editor-ad819b7b-2e1f7b93.eln
/home/user/.emacs.d/eln-cache/28.2-66fa0d00/nxml-parse-79a53381-b87f8800.eln: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ae37239bb67ec11b5d1eaf514df0660634fbd946, not stripped
/home/user/.emacs.d/eln-cache/28.2-66fa0d00/cc-vars-6cc3f0fc-a4ab31d9.eln: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=043e590c8a3917994270925abbfa6ec746488abb, not stripped
/home/user/.emacs.d/eln-cache/28.2-66fa0d00/with-editor-ad819b7b-2e1f7b93.eln: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2bfb93008822275a66cad1c463d286f366388725, not stripped
: ~;
When I’ve disassembled these, they seem to indirect all their function
calls through a jump table, so that you can rebind existing symbols to
new functions and affect already-compiled code. I haven’t dug into it
in much detail, though, so I might be mistaken.
Kragen
[toc] | [prev] | [next] | [standalone]
| From | Madhu <enometh@meer.net> |
|---|---|
| Date | 2026-09-04 08:36 +0530 |
| Subject | Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) |
| Message-ID | <m3h5k5n2au.fsf@pison.robolove.meer.net> |
| In reply to | #61623 |
* Kragen Javier Sitaker <87v78mz15a.fsf_-_@debian> : Wrote on Thu, 03 Sep 2026 14:37:53 -0300: > When I’ve disassembled these, they seem to indirect all their function > calls through a jump table, so that you can rebind existing symbols to > new functions and affect already-compiled code. isn't this just the behaviour of general compilation - unless the symbol function is inlines at compile time or the macroexpanded at macroexpansion time. > in much detail, though, so I might be mistaken. it's piggybacking on the gcc jit feature, (i never learnt it either)
[toc] | [prev] | [next] | [standalone]
| From | Kragen Javier Sitaker <kragen@canonical.org> |
|---|---|
| Date | 2026-09-15 12:19 -0300 |
| Subject | Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) |
| Message-ID | <87wlsmo83m.fsf@debian> |
| In reply to | #61624 |
Madhu <enometh@meer.net> writes: > * Kragen Javier Sitaker <87v78mz15a.fsf_-_@debian> : > Wrote on Thu, 03 Sep 2026 14:37:53 -0300: >> When I’ve disassembled these, they seem to indirect all their function >> calls through a jump table, so that you can rebind existing symbols to >> new functions and affect already-compiled code. > > isn't this just the behaviour of general compilation - unless the symbol > function is inlines at compile time or the macroexpanded at > macroexpansion time. [...] Oh hi enometh! It’s been a long time since UNM! I live in Argentina now, and there’s a brand of jam here called Emeth, which always reminds me of your username when I see it. It’s the usual behavior for Lisp compilation, but Emacs Lisp is sometimes a little unusual for a Lisp, and lots of other languages don’t do it this way. Kragen
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.lisp
csiph-web