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)

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
    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] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:27 +0800
            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
    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 1 of 2  [1] 2  Next page →

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

On 03/08/2026 6:28 PM, David Brown wrote:
> On 03/08/2026 11:41, Richard Harnden wrote:
>> On 03/08/2026 09:16, David Brown wrote:
> 
>>> On most targets, function pointers are the same size as void* 
>>> pointers. But there are exceptions, with some small microcontrollers 
>>> and DSPs having different kinds of pointers with different sizes, 
>>> depending on the memory space involved.  I have yet to see a 
>>> situation where there was any reason for storing a function address 
>>> in a "void*" rather than a more appropriate typedef, such as :
>>>
>>>      typedef void (*FVoid)(void);
>>
>> dlsym requires that pointer-to-function is compatible with a void*
>>
> 
> As I say, I have yet to see a situation where using void* for function 
> pointers was more appropriate than using a function pointer type.  If 
> the OS system calls or standard OS libraries makes it a requirement that 
> function pointers are converted to or from void* for some calls, then of 
> course you need to follow those requirements - it's the people who 
> designed the interfaces that made questionable design choices.
> 

Nope, you're wrong.  You're dead wrong.  The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.

Several language environments allow function generation on the fly,
these functions need to be garbage collected.  Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.

I've also added comp.theory so Mild Shock can comment.

You will have to go out of your way to make a computer architecture
incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different

*  sizeof ( void * ), and
*  sizeof ( void (*)( void ) ),

and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.


[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com

[toc] | [next] | [standalone]

#61271

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>On 03/08/2026 6:28 PM, A respected comp.lang.c poster wrote:

>Nope, you're wrong.  You're dead wrong.  The world isn't built on C,
>even though here in comp.lang.c we like to pretend it is.

Hey dipshit, you're responding to a post in comp.lang.c and
cross-posting your reply to other unrelated groups.   Please don't
do that.

[toc] | [prev] | [next] | [standalone]

#61272 — Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture)

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]

#61273 — But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...])

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]

#61323 — GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?)

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]

#61325 — What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries)

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]

#61343 — Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip])

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]

#61497 — Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group]

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]

#61498 — How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group]

Hi,

The biggest joke, is to have logic somewhere
in procedure and somewhere in declarative, and
try to see different takes on logic.

They really don't know what this mantra means:

Algorithm = Logic + Control

And cannot relate it to the ideas of declarative
reading and procedural reading. The problem is
a too lax introduction of this notions,

prematurely before the notion "logic" is
even understood. But nobody understands the
meaning of the term "logic", i.e. a set of

supposedly tautological sentences, as under-
stood by mathematical logic. There is a subtle
error again to conflate it with a "calculus",

so this website has a very misleanding title,
although they try hard to not commit the fallacy,
and have subtitles "Proof System" and "Logic Level":

Welcome to LogicProof
https://6ximik9.github.io/naturalDeduction/

Then there is this moron:

There is only one “minimal logic”. The term denotes Johansson’s 
Minimalkalkül [1937] — intuitionistic logic without ex falso quodlibet — 
and nothing else. No rival system competes for the name.
https://vidal-rosset.net/rule-correspondence-F.html

Of course there are rival "Proof Systems" aka
calculi, even when the "Logic Level" is minimal
logic. It is as if Joseph Vidal-Rosset doesn't

understand basic German. You have to look behind
"Minimalkalkül" to find "Minimallogic". Right?
To identify calculus with logic, is maybe a 1930's

fallacy, but then we had model theory besides
proof theory, and people should be more educated
now. Model theory can be also expanded to

non-classical logics and even minimal logic, to
give a purely semantic reading. Ok some modern
morons think they need to invoke the word "algebraic".

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]

#61500 — Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group]

On 18/08/2026 10:50 PM, Mild Shock wrote:
> Hi,
> 
> The biggest joke, is to have logic somewhere
> in procedure and somewhere in declarative, and
> try to see different takes on logic.
> 
> They really don't know what this mantra means:
> 
> Algorithm = Logic + Control
> 
> And cannot relate it to the ideas of declarative
> reading and procedural reading. The problem is
> a too lax introduction of this notions,
> 
> prematurely before the notion "logic" is
> even understood. But nobody understands the
> meaning of the term "logic", i.e. a set of
> 
> supposedly tautological sentences, as under-
> stood by mathematical logic. There is a subtle
> error again to conflate it with a "calculus",
> 
> so this website has a very misleanding title,
> although they try hard to not commit the fallacy,
> and have subtitles "Proof System" and "Logic Level":
> 
> Welcome to LogicProof
> https://6ximik9.github.io/naturalDeduction/
> 
> Then there is this moron:
> 
> There is only one “minimal logic”. The term denotes Johansson’s 
> Minimalkalkül [1937] — intuitionistic logic without ex falso quodlibet — 
> and nothing else. No rival system competes for the name.
> https://vidal-rosset.net/rule-correspondence-F.html
> 
> Of course there are rival "Proof Systems" aka
> calculi, even when the "Logic Level" is minimal
> logic. It is as if Joseph Vidal-Rosset doesn't
> 
> understand basic German. You have to look behind
> "Minimalkalkül" to find "Minimallogic". Right?
> To identify calculus with logic, is maybe a 1930's
> 
> fallacy, but then we had model theory besides
> proof theory, and people should be more educated
> now. Model theory can be also expanded to
> 
> non-classical logics and even minimal logic, to
> give a purely semantic reading. Ok some modern
> morons think they need to invoke the word "algebraic".
> 
All my graphic art in CorelDRAW! is done with algebraic curves.  I found
the regular Bezier curves simply boring, and /upgraded/ my curvatures to
/algebraic/.

Do you also draw with algebraic curves in your vector drawing utility of
choice?  Is it Xfig?
-- 
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]

#61499 — Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group]

On 18/08/2026 10:26 PM, Mild Shock wrote:
> 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:

Are you coding the SWI interfaces in RISC OS in Prolog?  Isn't it much
more fruitful to code it in the /Acorn RISC Machine/ assembly?

> 
> Sets of rules as conjunctions and/or disjunctions
> https://swi-prolog.discourse.group/t/sets-of-rules-as-conjunctions-and- 
> or-disjunctions/9779


So, is this set of conjunctions and disjunctions about how to create set
intersections and unions of windows on RISC OS?  Why is that important?

> 
> 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.

Corollary, since an eye patch would hide my central heterochromia, would
that not hinder my ability to reason?

> 
> 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

What is F.O.L?

> 
> lookup clark equational theory, clark completion,
> curry howard correspondence, etc.. etc..

You can always complete your journey at the Clark International Airport
in the Philippines.  Let me know when you do.


As always, you've been greatly helpful, and mildly amusing, Mild Shock!
-- 
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]

#61501 — Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group]

 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.

 > Corollary, since an eye patch would hide my central heterochromia, would
 > that not hinder my ability to reason?

No comment.

-- 
‘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]

#61502 — Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group]

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.

[toc] | [prev] | [next] | [standalone]

#61504 — Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group]

On 19/08/2026 6:49 AM, Lawrence D’Oliveiro 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.

Dear Lawrence,

Have you thought to code yourself as a logical puzzle solving character
in text adventures, with or without the help of Prolog?

Do you think you can do so without ever mentioning Python?  Or do you
love snakes so much you cannot live without it?  Are you perhaps a
graduate of the Slitherin magical university?

I have added rec.arts.int-fiction to this discussion, and alt.fantasy,
even though we don't discuss Slitherins there.


Happy coding yourself in a text adventure game!
-- 
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]

#61503 — Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group]

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]

#61377 — The Mac Neo is a Budget Monster [GPU Channels] (Re: What are Flits and Phits? [Network on a Chip])

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]

#61379 — The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels])

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]

#61274 — Re: Malicious Computer Architecture

 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]

#61279 — Re: Malicious Computer Architecture

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]

#61280 — Re: Malicious Computer Architecture

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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web