Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.lisp > #61270 > unrolled thread

Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness)

Started byJohann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
First post2026-08-03 19:23 +0800
Last post2026-08-04 15:10 +0200
Articles 2 on this page of 102 — 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.

Contents

  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 (was Re: Malicious Computer Architecture) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-06 23:31 +0000
                      Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-06 08:34 -0400
                        Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 20:51 +0000
                          Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:48 +0000
                          Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-07 07:56 +0000
                          Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-10 19:14 -0400
                            Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 00:39 +0000
                              Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-11 22:20 -0400
                                Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-12 05:37 +0000
                                Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-12 05:55 +0000
                                  Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-12 17:06 -0400
                                    Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-13 08:14 +0000
                      Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) steve g <Sgonedes1977@gmail.com> - 2026-10-10 19:07 -0400
                    Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-10-06 08:30 +0100
                      Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-06 17:39 +0000
                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 Anton Antimo <anton@safunu.org> - 2026-10-06 15:14 -0300
                                Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-10 19:17 -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 6 of 6 — ← Prev page 1 2 3 4 5 [6]

#61277 — A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture)

FromMild Shock <janburse@fastmail.fm>
Date2026-08-04 14:58 +0200
SubjectA Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture)
Message-ID<114snlo$uj7n$2@solani.org>
In reply to#61270
Hi,

How it started:

The Applied Pi Calculus: Mobile Values,
New Names, and Secure Communication
Martín Abadi et al. - Google Brain
https://arxiv.org/abs/1609.03003

How its going:

Dynamic Control Flow in
Large-Scale Machine Learning
Martín Abadi et al. - Google Brain
https://research.google/pubs/dynamic-control-flow-in-large-scale-machine-learning/

Have Fun!

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]

#61278 — The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus)

FromMild Shock <janburse@fastmail.fm>
Date2026-08-04 15:10 +0200
SubjectThe Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus)
Message-ID<114sod0$ujln$3@solani.org>
In reply to#61277
Hi,

While Paul Taraus Interactors were somewhere
between stackfull and stackless coroutines,
they were still a castle built on sand.

What was the comms? An interactor was a child
of a parent, and had only two comms, input "next"
and output "the". And there was not much

asynchronizity. But look at the new
library(misc/intercom) that provides ADA
Rendez Vous in Dogelog Player for Java:

:- ensure_loaded(library(misc/intercom)).

producer(C) :-
    between(1,10,X),
    Y is X*X,
    send(C,[Y]),
    fail.
producer(_).

consumer(C) :-
    between(1,10,_),
    recv(C,[Y]),
    write(Y), nl,
    fail.
consumer(_).

As the show case shows, it even works with
cooperating coroutines. I have looked at it
for 5 hours straight, its beautiful:

?- cpu_chan_new(C), create_task(producer(C)),
    create_task(consumer(C)), sleep(1000).
1
4
9
16
25
36
49
64
81
100
C = 0rReference.

Bye

Mild Shock schrieb:
> Hi,
> 
> How it started:
> 
> The Applied Pi Calculus: Mobile Values,
> New Names, and Secure Communication
> Martín Abadi et al. - Google Brain
> https://arxiv.org/abs/1609.03003
> 
> How its going:
> 
> Dynamic Control Flow in
> Large-Scale Machine Learning
> Martín Abadi et al. - Google Brain
> https://research.google/pubs/dynamic-control-flow-in-large-scale-machine-learning/ 
> 
> 
> Have Fun!
> 
> 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] | [standalone]

Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]

Back to top | Article view | comp.lang.lisp

csiph-web