Thank you for a real OP, but you linked the wrong post.
Actual previous thread: >>108561805

>>108601694
>tranime
nope

>>108601698
You know what, fair.

>>108601674
>>108601681
>new thread >>108601674
>>new thread >>108601674
>new thread >>108601674
>>new thread >>108601674
>old one reached bump limit

>>108601674
>Reichskanzlei
What did you program in Plankalkul today, anon?

>>108602286
>Plankalkul
>Not kalkül
Uh oh. https://i.4cdn.org/wsg/1776144561846003.webm" target="_blank">https://i.4cdn.org/wsg/1776144561846003.webm

they should replace the heap with a giant program level stack

>>108602823
No they shouldn't. But they should get rid of malloc and free and implement something a lot closer to HeapCreate/HeapDestroy (and a missing HeapReset), and introduce mreserve/mcommit to separate reservation from commitment semantics.

File: 1769747592094529.png (23 KB)

23 KB PNG

master/primary/server/controller/main
slave/secondary/client/peripheral
What else do we have?

>>108602868
>*changes it back*
>NOOOO YOU CAN'T DO THAT

File: 1775955725373587.png (10.4 KB)

10.4 KB PNG

>>108602874

>AI, remove all the woke nonsense from this literature
>as you command, m'lord
simple as

>>108602868
Using Arduino was the mistake in the first place

>>108602868
>>108602998
Ok now that I thought a tiny bit more about it, client/server makes absolutely no sense.
A server is usually a single entity that serves data it gets asked for.
Clients are usually multiple entities that ask for data.
A master is usually a single entity that asks slaves for data.
Slaves are usually multiple entities that serve data to masters

what the fuck, arduino?!
I am not THAT edgy and I have no problem if they just start using main/peripheral from now on with further explanation, but client/server is absolutely ass backwards lmao

>>108603010
Wait until you hear about X servers.

>>108602998
What PLC brand do you recommend?
This whole thing seems to flipflop between terminology.

>>108603010
It's not about making sense, it's about the humiliation ritual.

>>108603047
Doesn't matter, they all have their shitty edges :^)

File: 1758530067685562.png (116.7 KB)

116.7 KB PNG

make sure you keep your documentation at the lowest common denominator so you don't offend some troon, nigger, or biological female 10 years from now

>>108603477
>imagine working on code that you don't own
Skill issue.

File: cactus.png (10.2 KB)

10.2 KB PNG

>>108603477

>>108603477
>anon, why does your program contain an unused africanamerican class derived from monkey?

File: oops.png (16.1 KB)

16.1 KB PNG

Do OOPfags really?

>>108603657
really what?
state your implication so I can more precisely laugh at you getting filtered by OOP

>>108603806
nta but do you really think that engineer is an extension of ceo?

File: findspace.png (72.5 KB)

72.5 KB PNG

I rewrote finding space for save data to get non-contiguous and non-block-aligned sectors because the way I am redoing it will be able to make use of any available free space on the memory card.
It's also worth considering that because it is similar to a FAT filesystem, deleted data can be recovered if the card is not written to (probably particularly a NEW save slot is not written) so long as you have a way to dump the entire card contents and recalculate the checksums after changes (something that wouldn't be too hard to do from the tools I am making).

>>108603829
if you think that's how you use inheritance, you're not only filtered by OOP - you're retarded

>>108603611
It's the boilerplate for the Abstract Cotton Factory design pattern, never heard of it?

File: 1771559265799203.png (12.8 KB)

12.8 KB PNG

rusttroons btfo

>>108603917
You want me to talk about Factorio? Because I will talk about Factorio if you keep talking about C++ memory management, because I have opinions, and I'm not afraid to share them.

>>108603961
idk what that is

>>108604522
Most people think Factorio is a factory management game that is well optimized, but I have seen face of its machine code and I can tell you they are wrong. Factorio is complete, 100% C++ boomer slop.

You may wonder who I am and why I say this; sit down and I will tell you a tale like none that you have ever heard!

>>108604565
idc

>>108604586
And idc about C++ propaganda.

cpp modules seem pretty cool so whats the hold up

>>108604791
You know why.

File: 1715455605887327.jpg (61.7 KB)

61.7 KB JPG

>you can't just execute the value of a register as an instruction
>the instruction has to be in memory, and you have to jump to it, and you have to jump away from it
I'm going to sleep.

>>108603917
Honestly I don't know how anyone manages to leak memory. Like, just deallocate it when your done, nigger. It's not that hard.

>>108605131
Well duh.
What are you even trying to do?

>>108605131
x86 instructions can be up to 15 bytes long. That's not gonna fit in rax.

>>108605676
Don't care.

>>108605693
>>108605666

>>108605699
Doesn't matter. You're not magically going to pull a solution out of your hat.

>>108605699
So you just want to do it for funsies?
I mean, that's as good a reason as any to do anything in assembly, but don't come bitching and moaning when it's something you can't do.

>>108605743
>putting the cart before the horse

File: ebasedi.png (171.8 KB)

171.8 KB PNG

>>108605131
Literally why

>>108605766
Reducing cache line footprint branchlessly.

>>108605787
So instead of using a bit of your 16kib of cache, you want to waste some of your precious 128 bytes of registers instead?

File: hmm.png (50.1 KB)

50.1 KB PNG

>>108605753
>>108605787
All you had to do was say that instead of dicking around.
Branches are essentially free if they are predictable, so if you want to do something like this then you should just have a spot near your code in memory that will be within the cache envelope where you can dump the instruction before jumping to it.

>>108605818
Don't even. I'm actively fighting the compiler's retardation with regards to calling conventions as is. RAX and R14 are essentially freebies at this point.

>>108605840
>Branches are essentially free if they are predictable
>if they are predictable
Considering we're talking writes anywhere between 4 to 32 bytes - no. No, I don't think they are.

>>108605131
https://www.felixcloutier.com/x86/call
> E8 cd CALL rel32 D Valid Valid Call near, relative, displacement relative to next instruction. 32-bit displacement sign extended to 64-bits in 64-bit mode.
stop chopping you're balls off wtf
https://i.4cdn.org/wsg/1776206231376814.mp4" target="_blank">https://i.4cdn.org/wsg/1776206231376814.mp4

What exactly are you trying to do?

>>108605856
The branch itself is predictable in this case, you are always jumping to where you store the instruction you want to run.
The variable length of the instruction doesn't matter. So long as you are within the cache line, the write will be cached.

>>108605870
>call/ret
Just stop posting: >>108605734

File: lua test2.png (1.3 MB)

1.3 MB PNG

New 'toss.

>>108605903
>Roberto Ierusalimschy
>Luiz Henrique de Figueiredo
>Waldemar Cele
It explains so fucking much, including why so many midwits continue to use it to this day.

>>108605903
>>>/a/

I trust you guys more than chatgpt or google, what's a good book or online course that will get me up to speed with Python and OOP principles? I want to start using Godot but so much of the language in the documentation expects an understanding of OOP terms and concepts, I just feel out of my depth. I've done some basic coding in C before so I'm good with the fundamentals, but shit like extends class or inheritance or whatever just goes over my head.

>>108605903
>not pedo bait lua tan
trash

>tfw you give her the 'ole copy-swapy

>>108606685
Don't really know, lol, but extending classes is basically making a copy of a class and then adding things to it.
It doesn't affect the objects that are cast from the parent class, but the child class objects have the extra funtions or data.
You can have private functions/data in the parent class that does not get inherited as well.

>sir, the c++ users are complaining that there's not nearly enough brackets and parentheses in the language
>ADD MORE

>>108605903
why post this in chudpt and not maidpt?

eternal linkage

File: file.png (23 KB)

23 KB PNG

Is there a quick fix profile fix I can apply to neovim on windows for this?
Every file has those letters at the top, and there's this error message at the bottom.

>>108607788
Have you tried the health check thing?

>>108607848
It's a genuine bug, I just don't know if there is a workaround I can apply. For part of the issue there seems to be, but I'm not sure if there is for the letters.
https://github.com/neovim/neovim/discussions/38648

>>108607922
Install an older version?

>>108607932
nyo... I already applied the first workaround...

>>108607031
>>108606685
I'll give Object-Oriented Python by Irv Kalb a shot, looks like it covers some game and GUI development as well so that should give me a good starting point to work with Godot later on.

>>108607788
Found a fix, for anyone wondering, the error at the bottom can be fixed by going to
:e $VIMRUNTIME/lua/vim/_core/defaults.lua and commenting out lines [972,989] in interval notation then call nvim with nvim --luamod-dev as described on the link I posted on >>108607922
The letters issue seems to be plaguing more versions but you can fix it by by editing your init.lua on :e $MYVIMRC
on 0.10 add
vim.g.clipboard = false
on 0.11+ add
local termfeatures = vim.g.termfeatures or {}
termfeatures.osc52 = false
vim.g.termfeatures = termfeatures

as described on
https://github.com/neovim/neovim/issues/28776

>>108609597
I'm happy for you, Anon.
What are you going to code now with this newfound power?

File: file.png (85.8 KB)

85.8 KB PNG

apparently this is the simple solution

File: file.png (41.4 KB)

41.4 KB PNG

>>108611075
I guess that was fairly simple in restrospect

>ADHD
>chaos in head
>write down two paragraphs in order to calm down the noise of differing ideas
>realize they all don't matter because compilers are retarded
>hold on
>are they as retarded as I think they are?
>test it
>it's even worse than I imagined
>go back to text
>too exhausted to finish the paragraph, this time with conviction
>force myself to read the last paragraph anyway
>become angry at compiler devs again
>suddenly find new energy to finish the paragraph

At this point in my life I am purely driven by ego.

>>108611883
>compilers are retarded
how would you improve them?

>>108612064
Not using SIMD registers that are non-volatile for scratch data, and not using volatile ones for data that has to survive a call would be a start. No need to do the same work as the callee.

>>108612135
who cares about function calls? SIMD's purpose is to make fast loops

>>108612484
I like fast loops too. That's why I don't want them inlined, or having to preserve and restore register state constantly.

>>108612135
What do you mean by non-volatile in regards to registers?

>>108612611
Callee-preserved. Y'know, like XMM6 and 7.

Let's say you have 8 registers, four of them read-only, and four of them only for temporary values. Obviously you want the temporary ones to be taken from the caller-preserved pool (0-5), since you know you won't need them after a call, and the callee won't preserve them. On the same note you want the read-only ones taken from the callee-preserved pool (6-15), since the callee will first take the volatile ones and only end up using the callee-preserved ones if it has to (because it also has to restore them).

Yet what ended up happening in that little test of mine was that the read-only ones ended up in XMM0-3, and the temporary ones in 4-7.

>>108612545
>I like fast loops too. That's why I don't want them inlined
lol nigger what? loops whose function calls aren't inlined are not fast

>>108612683
Also the compiler restored the _read-only_ ones with vmovdqu, when it previously used vpbroadcastq - which, even if accounting for a vzeroupper, could've restored the values in the upper YMMs without memory references. Y'all ever wondered where we'd be in terms of software quality if gross inefficiency was punishable by death?

>>108612746
Skill issue. Mine are.

File: 1775764554880263.png (333.9 KB)

333.9 KB PNG

I have gone full scizo and am building a telescoping wide-format printer with repurposed printheads and Plan 9 instead of firmware. It's pretty fucking sick - the computational guts are a pi 5, a RP2040 to run freeRTOS for all the time sensitive shit, and every single electromechanical device in the thing is scriptable as a result. It's fucking sick, I can carry this bastard anywhere and print anywhere that has up to a 24" roll of paper (or bring one myself) but it's discrete - locks at the inch, so it handles every standard sized paper from letter to Arch D. The design itself is cool because it all folds up into a 18"x5"x5" lightweight device, which is how my penis is. The software itself though is fucking cool, though, because I print large sensitive documents for large sensitive people and this gives me 100% control of a mobile shop, essentially. I'm already a mobile notary, and since this is all proprietary and I'm an SP, it's all mine to go fill a niche with.

>what is the use case
Look up the yellow dots

>>108612853
Bait used to be believable.

>>108612749
>Also the compiler restored the _read-only_ ones with vmovdqu, when it previously used vpbroadcastq - which, even if accounting for a vzeroupper, could've restored the values in the upper YMMs without memory references.
>Y'all ever wondered where we'd be in terms of software quality if gross inefficiency was punishable by death?
Post your register allocator that handles this or stfu.

>>108601674
can anyone answer >>108612803
thread got archived because OP is a faggot

>>108611560
based

File: tom-smykowski.jpg (173.4 KB)

173.4 KB JPG

>>108613056

>>108612963
one important point about TDD is that you're supposed to test functionality, not implementation
if you test functionality and the implementation changes, the test itself is still valid, and will tell you if the changes broke anything

for example: if you wanted to unit test FizzBuzz, you would need just one test: run FizzBuzz from 1 to 100 and see if the output matches the sequence: 1, 2, Fizz, 4, Buzz, Fizz, ... 98, Fizz, Buzz
with such a test it doesn't matter if you implement it as the usual loop with modulo, or do the array thing and modulo the index, or blow it up into enterprise OOP with design patterns
if you wanted to extend the FizzBuzz to include more conditions (eg. append Pop for every 7th element), you can have a FizzBuzzPop test case as a second unit test while the first one validates the standard FizzBuzz still works - most you'll have to change is maybe add some parameters to define what patterns to execute, but definitely not rewrite the whole previous test case

most people who bitch about TDD being useless, a waste of time and whatnot, miss this point entirely and instead write tests directly for implementation details, all of which is does is just runs the code with no purpose or context

>>108613056
"i'm using a hammer on screws and it sucks, but i've been doing it for 10 years now so don't tell me i'm doing it wrong"

>>108613160
>most people who bitch about TDD being useless, a waste of time and whatnot, miss this point entirely and instead write tests directly for implementation details, all of which is does is just runs the code with no purpose or context
most of those people also think encapsulation = redirection.
anyways, this is more or less what I imagined to be true, because I haven't bothered to actually read testing code in literally any software suite, because I guessed this was the case in particular. according to asking a clanker about it, the reason is for decoupling, "You literally cannot write a unit test for 'spaghetti code.' If you TDD, you are forced to use Dependency Injection or modular interfaces just to get the test to run." this sort of thing really reminds me of using assertions or >>108611560 because nobody actually defines contracts.
for most people, functionality and implementation are not at all different unless someone starts talking about reference implementations or specifications in particular. I posted >>108612818 and have wondered for years if there's actually going to be any logical conclusion to development practices that aren't subgenius "get slack LMAO" shills besides AI-driven development. do you think it's irrelevant with openrouter/gastown?

ai? more like gayi, amirite?

>>108612683
It doesn't actually matter, though.
Because if the callee will use preserved registers, it will always push them to the stack, regardless of whether you are "using" them.
It's only the non-preserved ones that matter because you have to preserve them through the call.
>since the callee will first take the volatile ones and only end up using the callee-preserved ones if it has to (because it also has to restore them).
The callee doesn't determine while it is running which registers it will use, the registers are all predetermined.
And seeing the callee may also function as a caller, it is not at all guaranteed that they will favor volatile registers. Though if the compiler is fully aware of the scope of the callee, then it can be free to use any registers it likes, even volatile ones, through the call because it knows they won't be changed.

>>108613287
nta literally the only reason you should use a compiler instead of an assembler that isn't portability

>>108613287
this
and it reminds me of this article
https://web.archive.org/web/20020815130006/http://www.bridgespublishing.com/articles/issues/0004/When_to_use___fastcall.htm

>>108613343
>fastcall
there's only been 1 calling convention since 64-bit, m8

File: hqdefault.jpg (24.7 KB)

24.7 KB JPG

>>108613369
https://wiki.osdev.org/X86-64_Instruction_Encoding

>>108612940
>Post your register allocator
Nice try to get my DNA.
But the funny thing is that you're effectively admitting that dependency specifiers in assembly blocks are bullshit because the compiler cannot track registers across function calls (despite there being no technical reason not to), so in addition:
>I accept your concession.

>>108613287
>It doesn't actually matter, though.
Are you capable of reading the English language?
>since the callee will first take the volatile ones and only end up using the callee-preserved ones if it has to

The callee will clobber your caller-preserved registers without a second thought, which is why the caller has to preserve them unless it is no longer interested in them - which is _exactly_ the problem here.

>it is not at all guaranteed that they will favor volatile registers
That's a callee-problem, not a caller-problem. Why would the caller bother itself trying to guess which registers the callee ends up using? The only thing that matters to the caller - without access to the code of the callee - is which values it has to keep track of across a function call.

No, your explanation is just nonsense. The real reason is that both gcc and clang (which exhibit both that behavior) were written for platforms that know absolutely nothing about callee-preserved SIMD registers, and so they can't actually distinguish between the two. No reason to sugarcoat that failure with your vague nonsense.

>>108613569
>the compiler cannot track registers across function calls
nta there's a reason for this (and it "does" if you use -g) but it will anyways even though doing so is just an optimization path. at least gcc pretends to. MSVC and LLVM cucks need not reply. the technical reason for this is for -Os and I don't have a single citation for why.

>>108613578
>and it "does" if you use -g
>at least gcc pretends to
Just tested, lol no. The RO data still ends up in XMM0-3, the scratch data in 4-7.
>-Os
-Os still uses 0-3 for RO data, too.

>>108613569
>>108613578
by the way I'm almost certain the linker does this.

>>108613602
that's what the manual says to do.

>>108613548
https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170
idk wtf you think instruction encoding has to do with calling conventions

>>108613622
it's not well-documented that there are "outside" callings on x64. some of those things depend on VEX. anyways, I know that using sysV there's fastcall, then there's still int 0x80, and x64 syscall for conventional calling. I don't even know if the manual specifies this outside of mentioning fastcall.

>>108613602
>>108613605
iirc the behavior is a (microcode) optimization and you might actually be able to find a reference for why this supports backwards compatibility without talking about x87 or management registers. I think the intention was for implementation simplicity.

File: IMG_20260416_180902_783.jpg (130.8 KB)

130.8 KB JPG

>>108601674
>What are you working on, /g/?
Porting HolyC Threading libraries to C for my UI Toolkit Libraries Project working on C

File: IMG_20260416_180642_699.jpg (78 KB)

78 KB JPG

HolyC CTask conversion to C almost

>>108613653
Wow. Microcode optimization. That, wow, that's so much more important than SIMD memory reads and writes.

What are you TALKING about.

>>108613569
>the compiler cannot track registers across function calls
what is that supposed to mean? that the caller knows which registers are caller-saved? it already does

>>108613673
>Are you capable of reading the English language?
>>since the callee will first take the volatile ones and only end up using the callee-preserved ones if it has to
>The callee will clobber your caller-preserved registers without a second thought, which is why the caller has to preserve them unless it is no longer interested in them - which is _exactly_ the problem here.

>>108613667
>use-case for SIMD?
this has been a meta memetic probably since before you knew what a titty was

>>108613686
so you want all registers to be callee-saved?

>>108613719
nta
Yes.

>>108613716
>use-case for SIMD?
First that comes to mind: printing values, both in hexadecimal and decimal notation. Second: dumping binary data in hex. Third: copies.
>inb4 muh ERMSB
So they finally fixed the long startup costs?

>>108613732
...no.

>>108613719
No? I want the _caller_ to use _caller-preserved registers_ for values that _don't_ have to survive a function call (saving it the effort to preserve and restore them), and to use _callee-preserved registers_ for values that _do_ (because the callee, or several layer of callees, will prefer the ones that don't require them having to preserve shit).

>>108613751
(Which, for the record, works for scalar registers. Because gcc and clang had to, for the systems they were written on. SIMD registers, not so much)

>>108613751
fucking finally

>>108613719
I'd say ideally, yes.
In the end, this whole thing about volatile and non-volatile registers is just register handling conventions.
And there is more than one of them.
The issue, of course, is interoperability of your code with other software on the system.

>>108613779
>fucking finally
Yeah. Finally. About five hours ago already.
>>108612683

>>108613751
>(because the callee, or several layer of callees, will prefer the ones that don't require them having to preserve shit)
He says, based on nothing.

>>108613751
that's unreasonable for complexity reasons. the Intel compiler might do that but it is also known to be temperamental.

>>108613796
I don't see 0-5 being preserved for my caller, I can tell you that much. Only 6 and 7.

>>108613805
>that's unreasonable for complexity reasons
>>108613569
>you're effectively admitting that dependency specifiers in assembly blocks are bullshit because the compiler cannot track registers across function calls (despite there being no technical reason not to), so in addition:
>>I accept your concession.

>>108613807
I don't see anything because you're not showing any examples.

File: hq720.jpg (55.3 KB)

55.3 KB JPG

>>108613807
right, because those are quietly marked as reserved, and I'm pretty sure that's because of x264. except you didn't want to talk about microcode.
>>108613815
I'm >>108613653 >>108613640

>>108613823
all of my this right now post a fucking godbolt link or GTFO

>>108613823
Skill issue. Everyone else here can.

>>108613825
>right, because those are quietly marked as reserved
>quietly
https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170
>The x64 ABI considers registers [...] XMM6-XMM15 nonvolatile

>>108613835
...yes.
give me like 3 hours and I might actually be able to find this in like volume 1b of intel manual

>>108613249
yeah more like gayu

>>108605131
https://youtube.com/watch?v=jrL_LzX5wv4

>>108603477
There's no eay a black guy will look at my code 10, 100, or a 1000 years in the future.

File: Screenshot From 2026-04-16 04-58-23.png (68.4 KB)

68.4 KB PNG

>>108613841
>>108613835
>Bytes 287:160 are used for the registers XMM0–XMM7.
>Bytes 415:288 are used for the registers XMM8–XMM15. These fields are used only in 64-bit mode. Executions of FXSAVE outside 64-bit mode do not write to these bytes; executions of FXRSTOR outside 64-bit mode do not read these bytes and do not update XMM8–XMM15.

>>108613883
I will repeat myself: >>108613667

>>108613901
>VEX
look here you chickenshit dogfucker you better start reading down the same instruction prefix rabbithole I spent weeks and months on or I will personally make sure you write TPU opcodes by hand with your fingers on a touchscreen for minimum wage in your country because you're pissing off the only person willing to spoonfeed you at 5 o'clock in the damn morning.
you see that mapping in the center column? ok, that's why.

>>108613919
>a bit flips if you use higher SIMD registers
>which totally justifies poor register selection
I think you just want to talk about something you sunk way too much time into, regardless if it actually adds to the topic.

>>108613945
I don't care about which bit actually flips on control registers. what you're looking at without specifying if you're using -mtune=native or -march=native without also specifying which processor and compiler version you're on is a guarantee you are generating generic machine code for one thing. for a second thing, if you aren't using asm() the compiler is just doing standard calling convention and there are sometimes ways to get it to do what you want here either through pragmas, linker scripts, etc, and this is because CISC is literal cancer where the compiler is not going to expect 1) what it generates 2) where it generates it 3) what registers are going to be manipulated. without running sandsifter and fuzzing your entire instruction set, you basically aren't going to find out, neither, whether or not there's a gotcha, and all because of virtual registers. that's why the prefixes exist. they're virtual machine instructions for processor microcode.

File: homm_help_deserted_island.jpg (135.2 KB)

135.2 KB JPG

I spent a hour brute forcing trip codes to find a specific pattern I wanted.
My cpu hit 5.3ghz, 90c and went through 195m hashes.
nothing linked.
I'm trying to find a way to limit the process so it can run in the background for however long it takes. I don't want to go full throttle again and risk damaging my cpu.
process lasso looks promising, but it's only process level/affinity, it still goes berserk and pegs my cpu.

>>108613960
>you're using -mtune=native or -march=native
Because it literally doesn't matter. None of it. Doesn't matter if I use mtune/march or mavx/mavx2, or if the processor chokes slightly on the frontend because XMM8-15 are being used, because you still end up with cacheline-evicting SIMD writes and reads. Anyone who argues otherwise would probably be taken care of in the utopia I'm proposing: >>108612749

>if you aren't using asm()
>>108613569
>dependency specifiers in assembly blocks are bullshit
I would suggest that I am using them.

>>108613990
Sleep(40)?

>>108614004
>>dependency specifiers in assembly blocks are bullshit
I'm fucking retarded
anyways, yes. you would need an AI-enabled compiler for that to work. I'm telling you I've already been down this road. the only real reason this happens is because the processor is software-defined, and the physical process that actually etches these definitions is limited by both the software and what is physically possible. it's why intel has multiple architectures per feature size and why flip-flop is mostly marketing.
I digress. it has to do that by default because register rewriting.

>>108614025
>you would need an AI-enabled compiler for that to work
We're coming full circle now: >>108611883
>realize they all don't matter because compilers are retarded
>it's even worse than I imagined

Specifically because I may have even salvaged the situation if I had been able to provide register hints in structs:

typedef struct
{
    register __m256i rw0 asm("ymm0");
    register __m256i rw1 asm("ymm1");
    register __m256i rw2 asm("ymm2");
    register __m256i rw3 asm("ymm3");
    register __m256i ro0 asm("ymm6");
    register __m256i ro1 asm("ymm7");
    register __m256i ro2 asm("ymm8");
    register __m256i ro3 asm("ymm9");
}data;

Wouldn't have been perfect (thanks vzeroupper), but at least doable.

File: file.png (3.4 MB)

3.4 MB PNG

>>108613990

File: wojak_noticer.png (388 KB)

388 KB PNG

>>108614020
It would still peg, go idle, then peg again, over and over. I don't want it to peg.

>>108614108
read bottom right

>>108614123
Then the best I can suggest are movntdq + sfence strewn throughout the code, to make the CPU wait on bullshit memory stalls.

>>108614150
I do not have the source, it's a program I found on github that's 10 years old but the trips I tested do work, so it's legit.

>>108614176
Detours/jumps? There are often crevasses between functions due to padding where one can insert code into, and then get there with a short jump.

>>108614196
I'd like to think there's some sort of process limiter app out there instead of adding crippling code all over

>>108614230
Not really how that works. Best you can do from the outside is limit the time slice the process receives, but even in that slice the code is going to run as fast as it can - i.e:
>peg, go idle, then peg again

File: 1776296997165584.gif (441.9 KB)

441.9 KB GIF

>>108614123
I'M the nooticer though.

Still think I need to see the code rather than vague, "you can just do it yourself".
Or file it as a bug report.

Wait, is this the same guy who was complaining about not being able to execute the contents of a register as an instruction?

>>108614467
https://godbolt.org/z/GErvxYrWc

>>108614620
Sounds like a good idea ngl.
Being able to execute a single instruction as a parameter or two would save me some headaches.

SDL has fallen to luddites

https://github.com/libsdl-org/SDL/commit/00c3cfcf971a8b2d06cdb59cdc31db28e2fc5539

Go back to your containment general, nocoder.

>>108614709
cry more, AI faggot

>>108614652
use case?

>>108603829
And do you really think an org chart is OOP?

>>108614776
... it's literally in the post.

File: 1771776598742701.jpg (45.4 KB)

45.4 KB JPG

>>108614709
>The SDL project does not accept contributions that are in any part created by AI agents.

>>108604565
i wonder
i am sitting down
tell me

File: main_menu.png (35.6 KB)

35.6 KB PNG

>>108614922
Know, first, that I have written a tracer, for various user and kernel functions. On my way to find out how many allocations and releases the game was doing during normal gameplay ...

Yeah, the joke breaks apart at that point. But the point is that it cannot even open a file without multiple memory allocations and copies, to say nothing of the data that the runtime *recreates* because fully qualified paths are discarded with wanton disregard (say, building an NT path to check if a file exist, only to never open the file in the first place).

Then there's the allocation placement issues ... https://factorio.com/blog/post/fff-215

>>108614801
It's not and your refused to answer shows that it's a braindead abstract idea that serves no real purpose.

File: 1749716996003581.png (301.4 KB)

301.4 KB PNG

oopfags be like

>>108615054
OK, retard.

>>108614880
Surely that will stop indians from attempting to submit AI generated PRs.

File: Tree_Of_Life_(with_horizontal_gene_transfer).png (156.3 KB)

156.3 KB PNG

>>108615157
how it's going

>>108615178
OK, retard.

>>108615225
Was going to say
>>108615157
is more like what OOPfags wished their programs looked like

>>108615157
>>108615225
so you're just going to post "OOPfags be like" with any tree-like graph that you can find?

File: oopfagsbelike.png (136.8 KB)

136.8 KB PNG

>>108615645
Yes.

slightly insulting that that's all you can come up with
well, can't expect much in-jokes from someone who got filtered by what he's trying to make jokes about

>>108615645
>triggered by a joke
>oddly silent on the constant spam of pedophilic transsexual propaganda images
your weird

>>108614094
that's not what C is for anon

File: 1774194627445468.jpg (121.6 KB)

121.6 KB JPG

>Microsoft decided it was time for me to reboot my computer
>lost dozens of tabs and open files

>>108616075
why would you torture yourself like that?
Currently I have 1 tab open and 4 applications.
I shutdown my pc every day.
Start with a fresh session every morning.
It just works. Purposely putting way too much cognitive load on yourself is so fucking stupid. I can't even

File: 1774593473310350.jpg (72.6 KB)

72.6 KB JPG

>>108616088
I'm afraid that if I turn my computer off it won't turn back on again

>>108615960
>no true scotsman

>>108614467
>post code
>no reaction
Alrigh'.

>>108616122
7:14 PMGood question — this is a common point of confusion with QSPI PSRAM.
Short answer: No, you cannot write just 4 bits (a nibble) to an address. The minimum write granularity is 1 byte (8 bits), even in Quad SPI mode.

>>108616313
>—
Come on now.

>>108616331
The datasheet really says nothing
https://www.lcsc.com/datasheet/C261882.pdf

I was suspecting that and from my implementation testing I was quite sure about it, but maybe my implementation was just wrong.
But it's the chip

File: meabsorbingthecosmicknowledgeofsepples.gif (3 MB)

3 MB GIF

You just keep watching tutorials and reading books until one day you wake up and it all just clicks.

>>108616536
Bro, we have agentic tutorials now. You don't need to watch them yourself anymore and have more free time

>>108616536
>>108616631
Also you just keep on trying until it works.

simple r/w test...
testing uint16
*data_u32: 0xbeeebeee - (expected: 0xbeeebeee)
==================================================
*data_u16+8: 0x0000fefe - (expected: 0x0000fefe) - 0x90000010
*data_u16+9: 0x00001337 - (expected: 0x00001337) - 0x90000012
==================================================
*data_loc+2: 0x00000023 - (expected: 0x23)
*data_loc+3: 0x00000045 - (expected: 0x45)
*data_loc+4: 0x000000ab - (expected: 0xab)
*data_loc+5: 0x000000cd - (expected: 0xcd)
==================================================
*data_u32+0: 0x4523beee
*data_u32+1: 0x0000cdab
*data_u32+2: 0x00000000
*data_u32+3: 0x00000000
*data_u32+4: 0x1337fefe
*data_u32+5: 0x88440000
*data_u32+6: 0x00000000
*data_u32+7: 0x00000000
*data_u32+8: 0x00000000
*data_u32+9: 0x00000000
*data_u32+10: 0x00000000
*data_u32+11: 0x00000000
*data_u32+12: 0x00000000
*data_u32+13: 0x00000000
*data_u32+14: 0x00000000
*data_u32+15: 0x00000000
*data_loc+0: 0x00000031 - (expected: 0x0031)
*data_loc+2: 0x00000077 - (expected: 0x0071)
*data_u16+0: 0x00001131 - (expected: 0x1131)
*data_u16+1: 0x00001177 - (expected: 0x1177)
*data_u32: 0x11771131 - (expected: 0x??)

Lets see if I can run programs from psram now. At least it looks based

>>108615157
Hey that's avl tree!

>>108616075
Huh, all the softwares I use save temporary files, I never lost anything during a reboot.

>>108616095
about a year ago my mobo started making angry beeping sounds whenever I reboot so I stopped rebooting

>>108616658
>I'll just copy/paste the slop from the youtube video and everything will think I wrote it myself

>>108616772
there are probably not that many yt videos that explain how to write a psram driver in vhdl.
Maybe some, but prolly mainly verilog

>>108616161
>rework code
>no longer in a struct, and instead use register variables implicitly like a retard
>callee-preserved registers are now properly reserved and preserved, like Baal intended
>but the compiler "forgets" to restore the upper YMM registers - not only because they're volatile, but also because the compiler itself generates vzeroupper

https://godbolt.org/z/4j4q7f63b
Can't make this shit up

>>108614996
game seems to run perfectly fine and even if it didn't it would have nothing to do with what you said here. extra allocations while opening a file? so what lol

>>108617155
>game seems to run perfectly fine
Show base.

>so what lol
It should boot up in less than five seconds - uncached.

File: bluray.jpg (31.4 KB)

31.4 KB JPG

>>108614996
factorio looks like the most boring game on earth.
If you want to build logic circuits just use vhdl, verilog or a fucking breadboard.
I might just be too dumb to understand why people love this shit

File: base.png (3.8 MB)

3.8 MB PNG

>>108617250
Guess what taught me that central buses and processing plants don't scale due to congestion.
>just like in real life

>>108617300
dang that's a lot of pixels.
Well, I guess tastes are just different. If it floats your boat

>>108617315
If this video doesn't sell it, then I got nothing.
https://www.youtube.com/watch?v=9JUbCNt-tog

File: PXL_20260416_195418078.jpg (2 MB)

2 MB JPG

>>108616772
WOW I LOVE YOUTUBE!!!
>>108617338
Well, I understand that it can be satisfying to just get it done. It's just not my cuppa

File: nocall.png (70 KB)

70 KB PNG

>>108614634
I went to bed.
But your calls don't go anywhere, so the volatility of the registers doesn't matter.

>>108618062
... are you autistic, or do you simply not realize that the call is just supposed to enforce ABI rules?

>>108618080
Why would it enforce the ABI rules when it doesn't go anywhere?

>>108618132
Because the compiler doesn't know that it doesn't go anywhere. From the compiler's perspective the linker is going to place a valid function address in there.

>>108618316
You'd have bigger problems then, because the last reference jumps rather than calls.
If you want to interrogate unlinked binaries it may be more worthwhile to build it locally than use godbolt. When I have some time later I'll try it myself.

>>108618518
... you have no fucking clue what you're talking about. Go away.

>>108616075
Would you suck a dick if Windows asked you to?

>>108616536
Same with making pipe bombs.

Register this, register that... boooriiing!

>>108618767
Yeah, I have noticed that both Gemini and Deepseek have no ability what I'm talking about either. Of course vibecoders would find something they neither understand nor can be explained properly boring.

>>108618767
It's not boring but that specific discussion with that specific anon is retarded.

>>108619043
Just admit you have no idea what's going on, either. Go on. Admit it.

>>108619085
You've been talking about this for months, and in months you've written exactly one sentence explaining wtf you are even talking about: >>108613751.
Everything else is incoherent babble (muh tracking) where you moan that the compiler doesn't perform some kind of context-sensitive (call graph) register allocation and ABI-violating optimized calling convention where, in your imagination, callee spills are magically better than caller spills.

>>108619285
I'm sorry, have you implemented an AVX2-accelerated multithreaded registry dumper that executes in seven seconds?
I haven't either, but someone who did and spams 4chan so much about it likely has a bunch of mental illnesses.

>>108619285
>You've been talking about this for months
You have literally lost the plot.

>>108602868
I remember I had a computer systems class in uni where you'd fail the exam if you ever said "master" or "slave"

>>108619361
Good.

>>108619295
>>108619308
non sequiturs

>>108619525
Why would I try to argue with someone insane?

>callee spills are better than caller spills. They just are OK?
>anon, this doesn't make sense
>YOU ARE INSANE !^@&
lol, ok. I accept your concession, midwit.

>>108619812
>this doesn't make sense
Yes it does. But to understand that you need an IQ over the room temperature in Celsius.

>>108619876
A spill is a spill. It doesn't cost more or less epending on where it is.

>grug has food
>don't want shit on food
>can decide where store
>place where other grug is expected to shit
>in fact expected so much
>that even if other grug doesn't shit
>grug HAS to assume other grug will shit there
>rule of elder grug
>elder grug beat grug to death if not
>so grug will have to move food later again
>and every single time other grug comes in
>and takes a shit
>because that's other grug's shitting place
>but grug insists on putting food there

>then other place
>special place made for grug
>where other grug might still shit
>or not
>don't actually know
>not grug's shit, other grug's shit
>other grug's not telling
>but grug knows one thing
>even if other grug doesn't shit in first place
>grug still has to act as if other grug shits in first place
>even if other grug doesn't
>elder grug's rule
>but
>if other grug will shit
>in other place
>will move food away first
>and clean up after
>and move food back

>grug uses other place to store food
>because grug smarter than /dpt/ autists

>calls foo
>pushes contents of xmm6 and xmm7 to stack
>pops contents of xmm6 and xmm7 off the stack before foo returns
I don't see the problem.

>pushes contents of xmm6 and xmm7 to stack

>don't actually know
>not grug's shit, other grug's shit
>other grug's not telling

File: Screenshot_20260417-122934_1.png (37.8 KB)

37.8 KB PNG

>>108620044
Pushes contents of xmm6 and xmm7 to stack.

File: no_push.png (3.6 KB)

3.6 KB PNG

>don't actually know
>not grug's shit, other grug's shit
>other grug's not telling

File: 1704122102355709.jpg (49.6 KB)

49.6 KB JPG

>>108620007
>all that text written in 45s

>>108620064
>432[rsp]
what assembly flavor is that?

>>108620109
Intel, allegedly.

>>108617123
YMM registers are never used.
Since they need to be caller preserved, it literally doesn't matter if barrier dirties them cause foo never uses them again. It also doesn't matter that foo doesn't restore them cause that's the caller's (main's) problem.

>>108620159
In intel flavor this would be [rsp-432]

>>108620189
>Since they need to be caller preserved
https://learn.microsoft.com/en-us/cpp/build/x64-software-conventions?view=msvc-170
>XMM6:XMM15: Nonvolatile (XMM), must be preserved by callee.

>>108620201
That's XMM, not YMM

>>108620271
Yes, and?

>>108620285
YMM must be preserved by the caller.

>>108620193
I said allegedly becuase godbolt is set to use Intel asm and it output that.
I frankly don't care.

>>108620293
The upper portion of YMM. Which is trivial to do in this specific case with vpbroadcastq, as long as the XMM part survives. Which means we go back to
>callee-preservation.

>>108618062
>But your calls don't go anywhere, so the volatility of the registers doesn't matter.
That's tantamount to saying "We can't discuss how this part of this function is translated to machine code without building an entire million line application around it!!!"
Take them as placeholders for something real and move on with your life.
Also bear in mind that the person you're talking to may be using a different calling convention in their code. There are several, and different platforms make different choices.

>>108620305
But the lower portion is preserved by the callee, in pushing XMMs to the stack.
Seeing it is up to the caller to preserve the upper portions, but foo never uses them, it is free to blitz them and doesn't need to restore them.

>>108601674
fucking machine learning

>>108620506
>But the lower portion is preserved by the callee
Only if it actually needs the register. How many times do you need to hear this?
>where other grug might still shit
>or not
>don't actually know
>not grug's shit, other grug's shit
>other grug's not telling

>inb4 but how would it nuke the upper portions without pushing/popping the register
vzeroupper. Because register files are a mess.

>foo never uses them
What, do you think, do "v" and "ymm0" mean?
https://godbolt.org/z/f17sMvWor

>>108620635
>What, do you think, do "v" and "ymm0" mean?
It sets the upper value in YMM with vpbroadcast, and clears it with vzeroupper, but foo never USES the contents of the upper portion, so it doesn't need to preserve them across the calls to barrier.
There doesn't seem to be anything wrong with the handling of the contents of the registers, only the choice of using MM6-9, which require the callee to preserve the contents of the XMM registers, which it does.
Same with https://godbolt.org/z/f17sMvWor
There seems to be a strong preference to use MM6-9, but there's nothing wrong with the way it is handling them. foo is preserving XMM6-9 as it should and when it does need to ( https://godbolt.org/z/GErvxYrWc ) as caller it preserves YMM.

>>108621008
>foo never USES the contents of the upper portion
Answer the fucking question: what does "v" mean?

>>108621012
vector dez nuts into your mouth

>>108621104
mmm sho hairy

>>108617250
>If you want to build logic circuits just use vhdl, verilog or a fucking breadboard.
those aren't accessible nor do they have good graphics.

>>108621337
Ok that's a fair point.
And only simulating HDLs is awful

File: entryflags.png (30.3 KB)

30.3 KB PNG

Completely unset entries (the second page of a sector added to a directory listing) remains unmodified (so 0xFFFF on 1 fill cards) which has 0x8000 set, but bit 0x4000 is never set on entries, whether they are in use or deleted.
So it seems likely that either a check for 0xFFFF is done along side a check for 0x8000 to see if an entry is in use, or a check with 0xC000 is done (AND or XOR or whatever), which is what I am going to do.

>>108621104
I accept your concession; the registers are fully used, and the reason the compiler cannot properly preserve them is because it was originally designed for a system with no differing preservation rules per split.

>>108621507
What concession? I said nothing incorrect.

>>108621507
>the compiler
>the rules
make up your mind

>>108621507
https://godbolt.org/z/M9v3ozTfx
wow, look at it preserving the values of the registers when they are actually going to be used after the calls

compilers do whatever the language specification requires them to do

>>108621525
(I will admit this is a shitty demonstration, but it does show that the behavior changes, including pushing some values to stack, when the values are needed again after the calls. In some cases it is faster to load the values from memory instead, but that's because it is a shitty demonstration.)

Make your C++ code faster by excluding the C++ runtime.

>>108621660
Solid advice.

>>108621660
until you have to homebrew your own implementation of even a 1 feature from the crt and now you burned through the microseconds you saved at startup and are probably running orders of magnitude slower

File: no_restoration.png (29.7 KB)

29.7 KB PNG

>>108621513
>What concession? I said nothing incorrect.
>foo never USES the contents of the upper portion

>>108621515
There is no contradiction.

>>108621525
>picrel
... you honestly cannot be that retarded. Please tell me you're just pretending.

>>108621743
Why would it restore them between calls when it doesn't use them between calls?

>>108621751
>when it doesn't use them
BUT IT DOES! That's what the "v" is saying. Input dependency for the *entire* register, not just the lower portion.
>b-b-but it's not *actually* used
Nigger the compiler is not gonna look at whatever nonsense is being printed with the asm statement. It has no fucking clue what's actually inserting into the instruction stream. That's WHY you jump through the hoops of declaring output and input parameters and early clobbers and what kind of operands (memory, register, immediate, etc) you're accepting, Jesus Fruitcake Christ.

"v" is enough unless you can actively prove that it isn't, period.
>good luck

>>108621764
This shit actively reminds me of >>108618062
>b-b-but you're not *actually* executing code here
Doesn't matter. What matters is that the compiler has to assume that the volatile registers are now smashed. It's just that simple.

Sand was not meant to think.

>>108621764
Oh, and also: the argument that there's no output dependency is fucking retarded. That's what the "=m" is about. Makes sure the asm block isn't removed or reordered. After all, it's not an asm volatile block.

>>108621743
>There is no contradiction.
The compiler can implement any set of rule concerning calling conventions or whatever, that it wants. If you dislike cdecl for example, it's not gcc's or llvm's fault.

>>108621778
never did and never will be
https://www.youtube.com/watch?v=1RQBPs5Dkzg

>>108621778
Computers don't think.

>>108621778
neither was coal, carbon-based shitform

>>108621884
>still doesn't understand that the problem is the compiler being unable to see YMM registers as only partially preserved by the callee as per the rules defined by the ABI
>>108613835

>>108621925
calling conventions exist so that a caller can call a function without knowing any detail of what the callee does exactly, outside of which argument it takes and values it return, you dumb motherfucker

stop conflating function calls and function call graph analysis, nigger

>>108621956
... I tried. But your low IQ cannot be worked around. Enjoy being retarded for the rest of your life.

>>108621981
Enjoyed being cucked by compilers and seething at compilers for the rest your life, nigger.

>>108621986
Oh, don't worry. I'm actively advocating to remove all useless autists from software development, and the upcoming worldwide energy crunch is going to be extremely beneficial. Autists have no place in software development. If we had killed them all thirty years ago we'd be in much, much better shape.

File: even_fucking_google_admits_that_autists_are_unsuitable_for_the_job.png (157.1 KB)

157.1 KB PNG

>>108622012
Fuck, even Google admits that autists are unsuitable for the job. And it's usually glazing your ilk, saying that you deserve human rights and employment.

File: 1694411001056574.jpg (6.5 KB)

6.5 KB JPG

>>108622012
>the function call autist is also the angst basedjack resident
oh no no no no no

>>108622101
>AI said
seriously kill yourself midwit

post the issue ticket so we can see what gcc maintainers think about this behavior

>>108622115
>dox yourself
And you thought the autism charge was just me seething.

>>108622130
no one is going to try kill you

File: doubt.jpg (18.4 KB)

18.4 KB JPG

>no one is going to try kill you