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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.
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.
I've also added comp.theory so Mild Shock can comment.
that has different
* sizeof ( void * ), and
* sizeof ( void (*)( void ) ),
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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
Hi,
I've also added comp.theory so Mild Shock can comment.
that has different
*-a sizeof ( void * ), and
*-a 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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.
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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
Hi,
How it started:
The Applied Pi Calculus: Mobile Values,
New Names, and Secure Communication
Mart|!n Abadi et al. - Google Brain
https://arxiv.org/abs/1609.03003
How its going:
Dynamic Control Flow in
Large-Scale Machine Learning
Mart|!n Abadi et al. - Google Brain https://research.google/pubs/dynamic-control-flow-in-large-scale-machine-learning/
Have Fun!
Bye
Johann 'Myrkraverk' Oskarsson schrieb:
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers with
different sizes, depending on the memory space involved.-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
Ar an tri|| l|i 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.-a 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 :
> >>>
> >>> -a-a-a-a-atypedef 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.-a 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, itrCOs phrased as standard C is on topic, everything else isnrCOt; but there wasnrCOt 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 itrCOs still C,
and itrCOs 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 havenrCOt 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, theyrCOre not in BSS, theyrCOre 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.
And not to mention the operating system interfaces.-a 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 *.-a So what are the program-
mers of the JVM, CLR, and other virtual machines to do?-a They'll have
to rely on this "undefined behaviour."
|-------------------------------------------------------------------------------|
|"Ar an tri|| l|i de m|! L||nasa, scr|!obh Johann Oskarsson: |
|[. . .] |
|The habit when I read comp.lang.c it was to assert that standard C was all that|
|was worth discussing (yes, yes, itrCOs phrased as standard C is on topic, |
|everything else isnrCOt; but there wasnrCOt the activity in the |
|architecture-specific groups for them to be helpful when I was reading it). |
|This is even more ridiculous; almost all the C infrastructure out there relies |
|on what is undefined behaviour by the letter of the standard." |
|-------------------------------------------------------------------------------|
arsa Aodh|in ua Ceoth|inaigh ar an 3|| l|i de mh|! L||nasa 2026.
"I finally prepared another fossil for museum exhibition: from DECtapes written
in 1972-73, there are exhumed C compilers (including source) to show
what
the very early stages of the language were like. This was a highly transitional stage; for example, the earlier one anticipates a "long"
type, but doesn't have struct; the 6-months-later compiler implements
struct, but reuses long's slot in the type table. http://www.cs.bell-labs.com/~dmr/primevalC.html
Dennis"
arsa fear ar an 29|| l|i de mh|! I||il 1999.
"DECtapes are highly platform specific, and are not covered by ANSI C, which is the subject of this newsgroup (comp.lang.c). Try a DEC-related
newsgroup.
If you want us to comment on your source code, please post it in the body
of your email.
What was your C question?
Johann 'Myrkraverk' Oskarsson <johann@Myrkraverk.invalid> skrev: |-----------------------------------------------------------------------| |"So if I'm reading this right, you're posting exclusively to comp.lang.| |lisp, and comp.theory; and leaving out comp.lang.c as a sign of pro- | |test. [. . .]" | |-----------------------------------------------------------------------|
Det st|nmmer inte! I use news servers which tend to restrict a post to
2 newsgroups. Sorry! A few times I wrote explanations e.g. in January:
"I am sorry that this crossposting is to only 2 groups. I am sending
via a server which does not allow a crosspost to many groups. It or
Tin also forbids many groups in a Followup-To: field."
I stopped writing such explanations. Maybe I should not have stopped!
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
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.
So my take on it, is that the standard thumping trolls in comp.lang.c
were already a problem in the 90s. They just didn't know it, didn't
care, and nobody challenged them about it. Until now.
On 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|i 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.-a 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 :
> >>>
> >>> -a-a-a-a-atypedef 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.-a 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, itrCOs phrased as standard C is on
topic, everything else isnrCOt; but there wasnrCOt 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 itrCOs still C, and itrCOs 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 havenrCOt 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, theyrCOre not in BSS, theyrCOre not on the stack; that leaves the heap.
And not to mention the operating system interfaces. I'll name mmap(),
and Win32 has its equivalent, and while I'm not sure, OpenVMS might be different too.
All of them return the equivalent of void *. So what are the programmers of the JVM, CLR, and other virtual machines to do? They'll have to rely on
this "undefined behaviour."
> * 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.
On 2026-08-04, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
So my take on it, is that the standard thumping trolls in comp.lang.c
were already a problem in the 90s. They just didn't know it, didn't
care, and nobody challenged them about it. Until now.
On the contrary, standard-thumping in comp.lang.c has been regularly challenged for decades by numerous visitors; everyone who tried it so
far bounced off, and came down with an unpleasant bump. :)
Ar an c||igi|| l|i de m|! L||nasa, scr|!obh Johann Oskarsson:
> On 04/08/2026 2:51 AM, Aidan Kehoe wrote:
>
> Hello Aidan,
>
> We haven't spoken for a long time, and I guess we're moving in different
> social circles now.
I spent 2012-present debugging people, and until 2021ish without the time away
from that to maintain a social circle or do any XEmacs work. My social circle just shrank!
> You will find it amusing that my patch to the FreeBSD kernel, the one
> that kind of tunes the TCP/IP stack, is presumably used by Whatsapp as
> well.
>
> At least, that's the rumor I heard; I wouldn't know the truth as I don't
> work for Whatsapp. I thought only 5ch and Netflix had sites large
> enough to make use of it. Well, sites both large enough, and hosted on
> FreeBSD.
>
> I promised myself to look into it later, and if I'm right -- at least,
> that my patch is still there and all -- I'll let you know.
Good.
> It's always fun to know that whenever someone streams from Netflix, the
> TCP/IP patch I applied is being used; though I cannot say that it
> streams through my code; it wasn't that kind of patch.
>
> And I didn't, and don't work for Netflix either.
>
> I hope you're also leaving trails of patches in various operating
> systems that everyone on the planet, more or less, makes use of.
ThererCOs enough to do with XEmacs plus running a business plus a three year old
daughter plus a fianc|-e, that I donrCOt anticipate any OS patches from me this
decade. Still, I save lives, and more importantly, prevent large strokes.
> > Ar an tri|| l|i 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.-a 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 :
> > > >>>
> > > >>> -a-a-a-a-atypedef 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.-a 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, itrCOs phrased as standard C is on
> > topic, everything else isnrCOt; but there wasnrCOt 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 itrCOs still C, and itrCOs worth understanding and worth
> > writing.
>
> Yes, I remember that. I believe I came across a FAQ, probably comp.os.
> msdos.programmer, that said because comp.lang.c was full of standard
> thumping trolls, a lot of regular programming, even Win32 got discussed
> there. Yes, I'll quote.
>
> > Why does the newsgroup seem to be so C-oriented sometimes?
> > There are two reasons. First, comp.lang.c and
> > comp.lang.pascal have evolved in different
> > directions. Comp.lang.pascal has split into discussions
> > about individual Pascal compilers. comp.lang.pascal.borland
> > welcomes discussion specific to Turbo Pascal, and the other
> > new groups likewise. Turbo Pascal programmers tend to find
> > DOS questions welcomed in comp.lang.pascal.borland, so that
> > comp.os.msdos.programmer gets less of the "DOS in Turbo
> > Pascal" traffic. On the other hand, comp.lang.c has stayed
> > closer to talking only about the C language, and
> > vendor-specific or operating-system-specific questions are
> > not welcome. This tends to push questions about disks, DOS
> > file structure, video, the keyboard, TSRs, etc. to
> > comp.os.msdos.programmer even when those programs are
> > written in C.
>
> So my take on it, is that the standard thumping trolls in comp.lang.c were
> already a problem in the 90s. They just didn't know it, didn't care, and
> nobody challenged them about it. Until now.
Most of my comp.lang.c was the turn of the millennium. I donrCOt have the desire or spare time at the moment to read more newsgroups, and IrCOm happy with
my command of C.
> I am challenging their rule. And they can whine, and they can bluster,
> but nobody cares about their mistaken sense of prestige and power.
>
> They claim my cross posting is annoying. As far as I'm aware, I'm
> basically screaming into the void with my cross posts, because there
> isn't enough traffic in the other groups to warrant complaints about it.
Fight on! Alternatively put the time into XEmacs (or packages) work, which is,
a better use of your time. (From my perspective, and probably in the grand scheme of things; neither of is likely to make any difference to comp.lang.c.)
> > Oh well, thank you the autoconf maintainers, thank you the cmake
> > maintainers, shame about the difficulty with cross-compiling.
>
> On that subject, I have to agree. I've largely given up on both for my own
> projects. The problems with these tools isn't when they work, it's when they
> don't. It can be a nightmare to get to the first build on a platform where
> the build system doesn't work.
Well, itrCOs just one more platform to learn. I would love to move XEmacs to cmake, given it would unify the POSIX and Windows build systems, but it would be a huge investment of time to port it over, because I know autoconf but I donrCOt know cmake.
> I currently believe both tools make porting to a /different enough platform/
> basically impossible. And that's based on hard earned experience.
My understanding is that cmake just requires a C compiler, no shell, no other dependencies, so it should manage a different enough platform that has a C compiler without problems. This is its attraction over autoconf, which requires /bin/sh at least, and pragmatically more of POSIX.
> > > Several language environments allow function generation on the fly,
> > > these functions need to be garbage collected. Common Lisp is an
> > > example, therefore comp.lang.lisp is added to this discussion.
> > >
> > > I've also added comp.theory so Mild Shock can comment.
> > >
> > > You will have to go out of your way to make a computer architecture
> > > incompatible with garbage collected and heap allocated binary code,
> > > something I've been told SBCL does internally [1] to create an archi-
> > > tecture that has different
> >
> > I havenrCOt 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, theyrCOre not in BSS, theyrCOre not on the
> > stack; that leaves the heap.
>
> And not to mention the operating system interfaces. I'll name mmap(),
> and Win32 has its equivalent, and while I'm not sure, OpenVMS might be
> different too.
>
> All of them return the equivalent of void *. So what are the programmers of
> the JVM, CLR, and other virtual machines to do? They'll have to rely on
> this "undefined behaviour."
Well, they have to port to the various platforms, thatrCOs all. And hope the platform defines the behaviour.
> >
> > > * sizeof ( void * ), and
> > > * sizeof ( void (*)( void ) ),
> > >
> > > and when you do that, I'll just claim you're making a /malicious
> > > computer architecture/ and refuse to use it.
> >
> > Note that GCC on AMD64 produces function pointers that are one-byte
> > aligned, which to me is a similar philosophy. There cannot be any
> > performance advantage to that.
>
> Can you please expand on that? I'm not sure what you mean, and I hope
> it doesn't create function pointers at strictly odd addresses, because
> that's what it sounds like to me.
https://lidell.nu/xemacs-buildbot/#/builders/14/builds/690 throws an assertion
failure because I was storing a function pointer into a Lisp fixnum, which has
63 bits of precision. The least significant bit of the function pointer was set.
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
*-a sizeof ( void * ), and
*-a 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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
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 NVLinkrao, 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
*-a sizeof ( void * ), and
*-a 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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
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:
-C-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 NVLinkrao, 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
*-a sizeof ( void * ), and
*-a 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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
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:
-C-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 NVLinkrao, 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
*-a sizeof ( void * ), and
*-a 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.-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
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:
/**
-a* flit(C):
-a* The predicate succeeds in C with a new channel. The channel
-a* can be used from within GPU backed -C-WAM logical threads.
-a*/
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-a-a-a Single-a-a-a Double
Ryzen-a-a-a 705.1-a-a-a 337.4
Neo-a-a-a 669.4-a-a-a 239.9
WebGPU performance:
AI Laptop-a-a-a Single-a-a-a Double
Ryzen-a-a-a 731.8-a-a-a 392.9
Neo-a-a-a 932.8-a-a-a 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:
-C-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 NVLinkrao, 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
*-a sizeof ( void * ), and
*-a 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 :
-a-a-a-a-atypedef 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.-a 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.-a You're dead wrong.-a 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.-a 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
*-a sizeof ( void * ), and
*-a 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.
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.
I havenrCOt 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, theyrCOre not in BSS, theyrCOre not on the stack; that leaves
the heap.
When IrCOve disassembled these, they seem to indirect all their function calls through a jump table, so that you can rebind existing symbols to
new functions and affect already-compiled code.
in much detail, though, so I might be mistaken.
* Kragen Javier Sitaker <87v78mz15a.fsf_-_@debian> :
Wrote on Thu, 03 Sep 2026 14:37:53 -0300:
When IrCOve disassembled these, they seem to indirect all their function
calls through a jump table, so that you can rebind existing symbols to
new functions and affect already-compiled code.
isn't this just the behaviour of general compilation - unless the symbol function is inlines at compile time or the macroexpanded at
macroexpansion time. [...]
Madhu <enometh@meer.net> writes:
* Kragen Javier Sitaker <87v78mz15a.fsf_-_@debian> :
Wrote on Thu, 03 Sep 2026 14:37:53 -0300:
When IrCOve disassembled these, they seem to indirect all their function >>> calls through a jump table, so that you can rebind existing symbols to
new functions and affect already-compiled code.
isn't this just the behaviour of general compilation - unless the symbol
function is inlines at compile time or the macroexpanded at
macroexpansion time. [...]
Oh hi enometh!
ItrCOs been a long time since UNM! I live in Argentina
now, and thererCOs a brand of jam here called Emeth, which always reminds
me of your username when I see it.
ItrCOs the usual behavior for Lisp compilation, but Emacs Lisp is
sometimes a little unusual for a Lisp, and lots of other languages donrCOt
do it this way.
I always thought it was essential for the "dynamic" nature [of]
lisp: change the fdefinition and the next time the function symbol
gets called from any code (compiled or otherwise) it runs the new
definition.
when emacs lisp had only dynamic binding you could exploit this
further, but with lexical binding the variables names get compiled
out. that takes out some of the fun -- "by design" of course.
when Emacs Lisp had only dynamic binding you could exploit this further,
but with lexical binding the variables names get compiled out. that
takes out some of the fun -- "by design" of course.
On Thu, 17 Sep 2026 12:17:00 +0530, Madhu wrote:
I always thought it was essential for the "dynamic" nature [of]If the value of a symbol binding can get changed, then of course any
lisp: change the fdefinition and the next time the function symbol
gets called from any code (compiled or otherwise) it runs the new
definition.
change to that value will be picked up by subsequent references to
that same binding. That would be true of whatever language with
whatever binding rules.
Lawrence DrCOOliveiro [2026-09-17 21:12:29] wrote:
If the value of a symbol binding can get changed, then of course
any change to that value will be picked up by subsequent references
to that same binding. That would be true of whatever language with
whatever binding rules.
In ELisp, that's not true for functions defined with `defsubst`, nor
is it true for some of the core functions like `car`: the compiler
routinely inlines the function's definition and doesn't bother to
make sure it's "de-inlined" (or updated) if/when that symbol gets
`fset`ed.
Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
static scoping has a kind of "sad/boring/serious" side to it,
discouraging you from "walking on the wild side".
Madhu [2026-09-17 12:17:00] wrote:
when Emacs Lisp had only dynamic binding you could exploit this further, but with lexical binding the variables names get compiled out. that
takes out some of the fun -- "by design" of course.
Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
static scoping has a kind of "sad/boring/serious" side to it,
discouraging you from "walking on the wild side".
I've used dynamic scoping a few times in such "creative" ways
(i.e. reading a binding from a caller even thought that binding was
clearly intended to be a *local* variable), but I must say I don't miss those fun days, because I find closures to be a source of a lot more pleasure. EfOe
This is in no way a strong argument for default dynamic scope in any
flavour of emacs, but one real advantage is you can put a hardware
watchpoint (e.g. from gdb or lldb) on the value field of a symbol,
making it easier to track down what Lisp code modified its value in
an undesired way.
On Sat, 19 Sep 2026 14:47:35 +0100, Aidan Kehoe wrote:
This is in no way a strong argument for default dynamic scope in any flavour of emacs, but one real advantage is you can put a hardware watchpoint (e.g. from gdb or lldb) on the value field of a symbol, making it easier to track down what Lisp code modified its value in an undesired way.
Debuggers are allowed to hook into low-level runtimes in ways not specified (or specifiable) in any language standard. They can walk stacks and heaps and access objects regardless of what language visiblity rules might say.
So whether a language does dynamic or static scoping is a design decision that is all about the kinds of programs you write in it, not how you implement a debugger.
Lexical scoping gives fewer bugs and faster execution, dynamic scope
by default was a bad decision.
Aidan Kehoe <kehoea@parhasard.net> writes:
Lexical scoping gives fewer bugs and faster execution, dynamic scopeDynamic scope implemented with a shallow-binding cell is pretty fast so
by default was a bad decision.
I don't think speed is a serious concern in a relatively inefficient interpreter like Emacs Lisp.
Aidan Kehoe <kehoea@parhasard.net> writes:
Lexical scoping gives fewer bugs and faster execution, dynamic scope
by default was a bad decision.
Dynamic scope implemented with a shallow-binding cell is pretty fast so
I don't think speed is a serious concern in a relatively inefficient interpreter like Emacs Lisp. RMS used to think Emacs benefited from
dynamic scope since you could easily temporarily bind system variables,
such as (let ((case-fold-search nil)) ... ) where the temporary binding would affect only the local scope.
IDK if he would still say that. But it was a philosophy that he applied to both ITS (TECO) Emacs and GNU Emacs.
My understanding was that he felt it [dynamic scope] was faster, but I donrCOt care to argue.
Philosophies can be wrong.
Common Lisp has dynamic binding for globals and lexical scope for
locals.
On Sun, 20 Sep 2026 22:20:38 +0100, Aidan Kehoe wrote:
Common Lisp has dynamic binding for globals and lexical scope for
locals.
How does rCLdynamic binding for globalsrCY work, exactly? A global can
only be declared once, so how can the binding ever be overridden by
another declaration?
In a sense it is nothig more than saving old value and restoring it.
But doing this correctly without proper language support may be
tricky or tedious. For example you may be forced to wrap "catch all" exception handler around call to 'bar'.
Even with byte compilation, I'd have to see benchmarks to believe that
the speed difference between dynamic and lexical binding in Emacs is significant, especially with a small amount of coding attention, such as using LET outside rather than inside a tight loop if you can.
Even with byte compilation, I'd have to see benchmarks to believe that
the speed difference between dynamic and lexical binding in Emacs is
significant, especially with a small amount of coding attention, such as
using LET outside rather than inside a tight loop if you can.
IME, as currently implemented in Emacs, speed of byte-compiled ELisp
code is indeed pretty much the same with lexical-scoping as with
dynamic scoping.
and without byte compilation?
The 80s Elisp appeal for adoption was full control of the system, in the
case of an error you could see where you stood, see what variable had
which value, there were no secrets held by the author from the user by
the system.
With edebug, native-compilation, byte compilation and lexical
binding... I get impenetrable backtraces and opaque closures
Ar an t-ocht|| l|i d|-ag de m|! M|-an F||mhair, scr|!obh Stefan Monnier:
Madhu [2026-09-17 12:17:00] wrote:
when Emacs Lisp had only dynamic binding you could exploit this further, but with lexical binding the variables names get compiled out. that
takes out some of the fun -- "by design" of course.
Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
static scoping has a kind of "sad/boring/serious" side to it,
discouraging you from "walking on the wild side".
I've used dynamic scoping a few times in such "creative" ways
(i.e. reading a binding from a caller even thought that binding was
clearly intended to be a *local* variable), but I must say I don't miss those fun days, because I find closures to be a source of a lot more pleasure. EfOe
This is in no way a strong argument for default dynamic scope in any flavour of
emacs, but one real advantage is you can put a hardware watchpoint (e.g. from gdb or lldb) on the value field of a symbol, making it easier to track down what Lisp code modified its value in an undesired way.
Madhu [2026-09-17 12:17:00] wrote:
when Emacs Lisp had only dynamic binding you could exploit this further,
but with lexical binding the variables names get compiled out. that
takes out some of the fun -- "by design" of course.
Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
static scoping has a kind of "sad/boring/serious" side to it,
discouraging you from "walking on the wild side".
I've used dynamic scoping a few times in such "creative" ways
(i.e. reading a binding from a caller even thought that binding was
clearly intended to be a *local* variable), but I must say I don't miss
those fun days, because I find closures to be a source of a lot more pleasure. EfOe
Paul Rubin [2026-09-19 17:23:00] wrote:
Aidan Kehoe <kehoea@parhasard.net> writes:
Lexical scoping gives fewer bugs and faster execution, dynamic scopeDynamic scope implemented with a shallow-binding cell is pretty fast so
by default was a bad decision.
I don't think speed is a serious concern in a relatively inefficient
interpreter like Emacs Lisp.
When running code without byte-compiling it, the statically scoped
dialect of ELisp tends to be noticeably slower, indeed.
(defvar *foo*)*foo*
(disassemble (compile-toplevel '(progn (inc *foo*) (inc *foo*) (inc *foo*))))data:
Aidan Kehoe <kehoea@parhasard.net> writes:
My understanding was that he felt it [dynamic scope] was faster, but I
donrCOt care to argue.
See here: https://www.gnu.org/software/emacs/emacs-paper.html#SEC18
Even with byte compilation, I'd have to see benchmarks to believe that
the speed difference between dynamic and lexical binding in Emacs is significant, especially with a small amount of coding attention, such as using LET outside rather than inside a tight loop if you can.
Philosophies can be wrong.
RMS is a pretty sharp Lisper and while anyone can be wrong about things,
I tend to want a pretty good reason to think I'm not the one who's
wrong. In the previous section of that paper (SEC17) though, he does
say,
It is not necessary for dynamic scope to be the only scope rule
provided, just useful for it to be available.
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On Sun, 20 Sep 2026 22:20:38 +0100, Aidan Kehoe wrote:
Common Lisp has dynamic binding for globals and lexical scope for
locals.
How does rCLdynamic binding for globalsrCY work, exactly? A global can
only be declared once, so how can the binding ever be overridden by
another declaration?
In dynamic languages it is probably better to say that variables
are created, because this is runtime action.
I never used the Lisp machine debugging environment but I know was
amazing even by today's standards. I don't know what debugging in the Maclisp era was like.
* Paul Rubin <87se31gqbw.fsf@nightsong.com> :
Wrote on Tue, 22 Sep 2026 10:15:31 -0700:
I never used the Lisp machine debugging environment but I know was
amazing even by today's standards. I don't know what debugging in the Maclisp era was like.
you may have the chance to try it out now, if you can jump through the hoops and apply for a personal license (bottom of https://www.symbolics.biz/ , the invite only period seems to be over, and can handle 75 dpi bitmap fonts on xlib under modern displays with)
Emacs Lisp (in the 1980s the contraction "Elisp" was frowned on)
https://www.symbolics.biz/ , the invite only period seems to be over,
* Paul Rubin <87se31gqbw.fsf@nightsong.com> :
Wrote on Tue, 22 Sep 2026 10:15:31 -0700:
I never used the Lisp machine debugging environment but I know was
amazing even by today's standards. I don't know what debugging in the
Maclisp era was like.
you may have the chance to try it out now, if you can jump through the
hoops and apply for a personal license (bottom of
https://www.symbolics.biz/ , the invite only period seems to be over,
and can handle 75 dpi bitmap fonts on xlib under modern displays with)
I would go as far as: annoying to painful for it not to be available.
Kaz Kylheku <046-301-5902@kylheku.com> wrote:
I would go as far as: annoying to painful for it not to be available.
I have, at least twice, had to implement dynamic variables in Python. (in memoryof Lisps I used before CL, I called these things variations on 'fluids'). Surprisingly Python does have enough to do this portably in a thread-sane way. So I agree: languages without a facility for this are broken.
On 2026-09-21, Waldek Hebisch <antispam@fricas.org> wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On Sun, 20 Sep 2026 22:20:38 +0100, Aidan Kehoe wrote:
Common Lisp has dynamic binding for globals and lexical scope for
locals.
How does rCLdynamic binding for globalsrCY work, exactly? A global can
only be declared once, so how can the binding ever be overridden by
another declaration?
In dynamic languages it is probably better to say that variables
are created, because this is runtime action.
Even if you don't declare a variable, in a purely dynamically
scoped lisp (with shallow binding), the variable is actually created at
read time when the form like (setq foo 42) is processed by the reader.
The reader notices the foo token which is converted to a symbol by
interning. The foo part of the internal form of the expression is then a direct pointer to the symbol.
When the code is executing, nothing needs to be created at /that/ run
time. The foo pointer is basically just dereferenced to get to the value
cell of the symbol.
(Of course, if we regard the reader as being "run time", then it's all
run time; but there are different stages of run time. The run time of loading the file is different form the run time of executing something
in in millions of times in a loop.)
I don't know the current state of the CADR simulation that people were working on a while back
Paul Rubin wrote:
I don't know the current state of the CADR simulation that people werePretty good.
working on a while back
I spotted this: https://tumbleweed.nu/lm-3/ from our ams (alfred m
szmidt) and (if i remember right) "tapes from moon's basement", though I didn't have luck solving the fossil captchas on the mailing list.
Madhu <enometh@meer.net> writes:
I spotted this: https://tumbleweed.nu/lm-3/ from our ams (alfred m
szmidt) and (if i remember right) "tapes from moon's basement", though I
didn't have luck solving the fossil captchas on the mailing list.
Wow nice, it looks close to usable, though no idea what it takes to
actually run it. I never used these machines to any extent in real
life, so I'm not very familiar with their operation. It's ok, the
distro wasn't intended for people like me anyway. But I might try to
play with it anyway.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 26:23:51 |
| Calls: | 1,195 |
| Files: | 1,354 |
| D/L today: |
7 files (9,491K bytes) |
| Messages: | 293,879 |