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.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 47:45:57 |
| Calls: | 1,100 |
| Files: | 1,339 |
| Messages: | 275,630 |