<heat>
mjg, hello mr pessimal, thank you for popping up, quick question: in a slow path should I hint towards "unlikely" (as in unlikely to succeed and break out the loop)?
<heat>
i would assume either "yes" or "doesn't matter" because you're expecting contention anyway
<mjg>
that one is funky
<mjg>
the way you are doing shit right now is you are training the predictor to take the branch
<mjg>
and you are going to suffer a misprediction once the lock is free
tepperson has quit [Quit: Client closed]
<mjg>
unfortunately there is no "this is the shit to expect" clause
<mjg>
tl;dr don't hint
<heat>
ok sgtm
<heat>
thanks
<mjg>
nothing can be done there afaics
<moon-child>
when does reset not work?
<moon-child>
o.o
<mjg>
i'll note your debug unlock should validate cpu number
<mjg>
moon-child: i don't remember specific cases but i got some over the years
<mjg>
moon-child: the only tried and true method was to kill the terminal
<moon-child>
sure not term bug?
<mjg>
no
<mjg>
but whoever is at fault, see above
zxrom has joined #osdev
warlock has joined #osdev
<heat>
mjg, im kinda wondering now, shouldn't pause serve as a "next branch is mispredicting" hint?
<heat>
this sounds like a legit idea
<moon-child>
doesn't communication cost dominate mispredict?
<moon-child>
btw I realised transactions can be (ab)used to implement mwait
Matt|home has quit [Quit: Leaving]
<moon-child>
start transaction; read check lock is still held. Then spin forever. Once the other guy releases it, he has to write it, which will kick you out of the transaction since it was in your read set
<moon-child>
can wait on as much stuff at a time as you want in this way
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 248 seconds]
airplanemodes has quit [Quit: WeeChat 3.8]
_xor has quit [Quit: exit]
pog has quit [Quit: byee]
dude12312414 has joined #osdev
nyah has quit [Quit: leaving]
dude12312414 has quit [Remote host closed the connection]
thinkpol has quit [Remote host closed the connection]
thinkpol has joined #osdev
epony has quit [Remote host closed the connection]
<heat>
apprently linux inlines all spinlock code by default
<heat>
at least on the ticket spinlock side, have not looked at the mcs spinlock
SpikeHeron has quit [Quit: WeeChat 3.8]
SpikeHeron has joined #osdev
elderK has joined #osdev
slidercrank has quit [Ping timeout: 260 seconds]
<Jari-->
hi all
* knusbaum
waves
<Jari-->
knusbaum: howdy
<Jari-->
have to reboot this server soon, to get new Ubuntu revesion up and running
<Jari-->
revision
Jari-- has quit [Remote host closed the connection]
<knusbaum>
fun
<knusbaum>
I don't know why, but upgrading a linux always makes me happy.
<bslsk05>
github.com: Onyx/spinlock.c at 89e4d0e81e543cbd6c9a3978f546feddf8840e7f · heatd/Onyx · GitHub
<heat>
spinniest of the locks
<heat>
there is absolutely NOTHING wrong with them
<heat>
i think old onyx really has an old UNIX vibe of "really half assed, fuck this shit, spaces please?"
<heat>
also has the right dose of tutorial copy-paste
<heat>
(I still remember where I took those bits from)
vai has joined #osdev
vai is now known as Jari--
<geist>
heat: that checks out. with armv8.1 theres' even a cas instruction
<heat>
geist, what does?
<heat>
funnily enough I was just now looking at lr/sc
<heat>
on riscv
heat has quit [Ping timeout: 248 seconds]
Vercas4 has joined #osdev
<geist>
armv8.1, the new atomic instructions
<geist>
has a straight CAS instruction
<geist>
FEAT_LSE i think
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas4 is now known as Vercas
bradd has joined #osdev
slidercrank has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<kazinsal>
gods help me, I'm considering learning rust
<kazinsal>
entirely amazed the osdev branch of the RESF hasn't appeared en masse yet like a gaggle of mormons I accidentally invited into my house
<zid>
have you heard the word of our lord, graydon hoare/
<kazinsal>
I was looking at that dude's "writing an OS in rust" blog thing thinking "maybe I can just bogart this dude's early bringup shit and rewrite it in C because I'm too lazy to do it myself", then it eventually turned into "huh rust is kinda elegant lookin"
<kazinsal>
now I'm looking at the whole async/await thing and thinking, dang this would make some shit easier
elastic_dog has quit [Ping timeout: 252 seconds]
<Mutabah>
kazinsal: Joooiiiin ussss
elastic_dog has joined #osdev
<geist>
kazinsal: it happens. i have to agree
<geist>
it's a bit of symbol soup the first while, but then the compiler has *fantastic* error codes
eroux has quit [Ping timeout: 255 seconds]
eroux has joined #osdev
smach has joined #osdev
bgs has joined #osdev
smach has quit [Read error: Connection reset by peer]
epony has joined #osdev
smach has joined #osdev
vdamewood has joined #osdev
gabi-250_ has quit [Ping timeout: 255 seconds]
gxt__ has quit [Ping timeout: 255 seconds]
gxt__ has joined #osdev
gabi-250_ has joined #osdev
slidercrank has quit [Ping timeout: 268 seconds]
ptrc has quit [Remote host closed the connection]
ThinkT510 has quit [Quit: WeeChat 3.8]
ptrc has joined #osdev
ThinkT510 has joined #osdev
smach has quit [Remote host closed the connection]
gabi-250_ has quit [Remote host closed the connection]
gabi-250_ has joined #osdev
gorgonical has quit [Remote host closed the connection]
danilogondolfo has joined #osdev
kof123 has quit [Ping timeout: 268 seconds]
kof123 has joined #osdev
wootehfoot has joined #osdev
vdamewood has quit [Quit: Life beckons]
GeDaMo has joined #osdev
davros1 has quit [Read error: Connection reset by peer]
<mrvn>
kazinsal: don't you want the async/await to put threads to sleep in the kernel?
gildasio1 has quit [Ping timeout: 255 seconds]
gildasio1 has joined #osdev
<immibis>
async/await doesn't put threads to sleep at all
<immibis>
it remembers what operation was on-going and then goes away and does something else in the meantime. You might notice the relationship between async operations and threads is very similar to the relationship between threads and processors and then wonder what the difference is.
<immibis>
turns out that async/await is just cooperative multitasking with short-lived threads and small stacks
<immibis>
if I had time to redesign computing from the ground up I might try making threads into what async/await is, instead
<immibis>
another thing about async/await is that you have linked list stacks that can branch
gog has joined #osdev
dh` has quit [Read error: Connection reset by peer]
dormito has quit [Quit: WeeChat 3.6]
<zid>
good news, think I have sorted out a new PC
<kazinsal>
:toot:
<zid>
going to need a cooler and some other small bits, but a friend has a modern mobo + cpu going spare after upgrading
<zid>
I have ram spare and so does he
* mjg
snorts coke
<moon-child>
zid: nice
<moon-child>
mjg: not very nice
<kazinsal>
who doesn't love staring at their ceiling at 4am counting their own heartbeats
<mjg>
you a fentanyl kind of guy?
<gog>
i'm just a rock n roll clown i do a lot of cocaine
<lav>
cat sound
<kazinsal>
phenazepam or gtfo
<lav>
cat emoticon
<zid>
You guys are fucking weird.
dennis95 has joined #osdev
<mrvn>
immibis: async/await is just coroutines
<mrvn>
except sometimes you can send them between threads and sometimes you can't.
<mrvn>
and no recursion
<qookie>
worth noting is that in some cases (e.g. C++20 coroutine) you have stackless coroutines, which don't have their own stack and instead store their locals (ones that must live across suspensions anyway) in a separate coroutine frame object
dormito has joined #osdev
<sham1>
Poor man's objects or poor man's closures. Take your pick
<mrvn>
One big problem there is that that is compiler magic. It sometimes can optimize away the allocation or stack. But you never know if that will keep happening in the future or not.
<sham1>
That's why you compile to continuations and don't worry about the stack, because the stack doesn't exist
<mrvn>
what's a stack?
<mrvn>
waste of a good register if you ask me.
<sham1>
What's a computer - Apple
<sham1>
Still one of the most infuriating ads of all time for me. Although it means that it was successful
danilogondolfo has quit [Remote host closed the connection]
<bslsk05>
www.youtube.com: İpad pro— What's a computer– Apple - YouTube
<gog>
what is computer
<gog>
hvað er tölvu
<Ermine>
Good question
<lav>
how is coputer
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
<kazinsal>
*why* is computer
<gog>
when is compter
<Ermine>
where is comper
<zid>
everybody asks how is computer, but never how computer is
bgs has quit [Remote host closed the connection]
gxt__ has quit [Ping timeout: 255 seconds]
gxt__ has joined #osdev
<immibis>
mrvn: and coroutines are just threads
<mrvn>
immibis: no, they never run in parallel
elastic_dog has quit [Quit: elastic_dog]
<mrvn>
Computer - one of the first jobs obsoleted by, aehm, computers.
elderK has quit [Quit: Connection closed for inactivity]
<nikolar>
Poor computers
bradd has quit [Ping timeout: 248 seconds]
<mrvn>
They can get a job solving captchas now.
<kof123>
i just imagine "i'm a pc" "i'm a mac" (i forget to mention these are star wars ghosts) ....and then shows up <cow tools guy removes his mask, revealing seymour cray> "use the plow, luke"
* kof123
shows himself out
Left_Turn has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
Turn_Left has quit [Ping timeout: 256 seconds]
<immibis>
mrvn: threads never run in parallel... for most of the history of computing
<bslsk05>
www.youtube.com: CppCon 2015: Andrei Alexandrescu “Declarative Control Flow" - YouTube
<ALowther>
mrvn: Woah! I opened it on Youtube and apparently I'm already an hour in(7 minutes from the end). I'll have to give it another watch. Thank you :)
<zid>
That's a lot of video just to say return -E
anbdummy has joined #osdev
<mrvn>
zid: that's not about saying "return -E". That's about e.g. closing a file automatically when you say "return -E"
<mrvn>
much nicer imho than "goto fail1; ... goto fail2; ... goto fail3;"
<lav>
if(thing()==-E)close(file); QED
<mrvn>
ALowther: there are also some talks about using std::expected instead of exception and about turning/implementing exceptions via std::expected / std::variant
<mrvn>
lav: but then you have to remember to "close(file)" at every point you catch an error.
Left_Turn has quit [Ping timeout: 246 seconds]
<mrvn>
and if anything throws an exception you don't handle the file still doesn't get closed.
<mrvn>
He also has some examples that aren't better solved with RAII
<immibis>
pros of RAII: EVERYTHING is closed automatically. Cons of RAII: everything is closed AUTOMATICALLY
<immibis>
if you want to carefully order your closing for some reason, RAII is not an ideal fit
<ALowther>
mvrn: As I am watching this video and affirming to myself that I've never seen this before, I realized that the link you shared is timestamped. :)
wootehfoot has joined #osdev
<mrvn>
immibis: huh? RAII closes in the exact reverse order of opening.
<mrvn>
ALowther: ups. I just searched on youtube. must have remembered where I was last.
<mrvn>
immibis: also, if you need you can always call raii.close() prematurely, assuming you implement that method.
heat has joined #osdev
<heat>
henlo
<lav>
hewwo
<heat>
uwu cowon thwee
<lav>
mew
<zid>
I need a 240mm aio
<zid>
do you have one in your back pocket heat
<heat>
no
<heat>
my ass is not that thicc
Brnocrist has quit [Ping timeout: 252 seconds]
ALowther has quit [Remote host closed the connection]
<zid>
what's the big lump thn
Brnocrist has joined #osdev
nyah has joined #osdev
Brnocrist has quit [Ping timeout: 268 seconds]
[itchyjunk] has joined #osdev
nur has quit [Quit: Leaving]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
<zid>
Why are aios so expensive, I can build one for way less than they're charging
<zid>
Radiator from a ford focus is £32, fish pond pump is £4
<zid>
corsair want £180
dennis95 has quit [Quit: Leaving]
<epony>
imagine what the corsair penis pump costs
<immibis>
because it'll cost you more than £144 to make those work together. But you can use them if you want. Nobody's forcing you to buy the corsair one.
<immibis>
free market economics says: if you are choosing to buy the corsair one, obviously you find corsair's work more useful than £144
<epony>
it's a cheap part with a paintjob
<epony>
there are so many naive people out there
<zid>
It bloody won't
<epony>
don't cut yourself where someone with a disease has cut their hand already
<zid>
My guess is just that they're changing the models around so frequently they're doing tiny runs
<zid>
and it's all CNC'd on-site in their offices or whatever
<epony>
it's a logo paintjob
<moon-child>
£4 for a pump? Idk, your mom will provide a lot of suction for just half that
robem has joined #osdev
<zid>
rather than using the same radiator body for a couple of years and buying a machine to spit them out or such
gildasio1 has quit [Remote host closed the connection]
wootehfoot has quit [Ping timeout: 252 seconds]
heat_ is now known as heat
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dh` has joined #osdev
wand has quit [Ping timeout: 255 seconds]
<mjg>
check out galaxy brain on gcc
<immibis>
zid: they are going after the Gamely Gamers with unlimited money to spend on their Gaming Rig?
<Ermine>
If you remove memset declaration gcc still compiles that
<mjg>
i'm aware
<mjg>
only added because clang comlpained
<Ermine>
I was not aware
<heat>
mjg, seems to really prefer rep stos for zeroing
<mjg>
yes, it is part of my complaint
<mjg>
this shows up somewhere past 32 bytes
<mjg>
and it is *CRAP*
<heat>
does stosq have a perf penalty like stosb does (or I assume it does, like movsb)?
<mjg>
even ignoring the massacre above
<mjg>
yes
<mjg>
it is all from the rep prefix
<mjg>
anyhowy ourl inxu kernel is full of it
<heat>
fyi the codegen varies wildly per march=
<mjg>
i intentionally did not use one to match closer what ends up being used when compiling the kernel
* Ermine
wants clang compiled kerne
<Ermine>
kernel
<mjg>
the above massacre lines up with what lands in vmlinux
<heat>
Ermine, LLVM=1
<mjg>
Ermine: clang has its own woes
<heat>
LLVM=1 make x86_64_defconfig
<heat>
then LLVM=1 make bzImage modules and yer done
<heat>
it replaces the CC with clang and all the normal tools with llvm tools
<zid>
heat this is boring, fix my guaruaruard shading
<heat>
this is kewl
<Ermine>
heat: thank you
<mjg>
Ermine: he is bullshitting
<mjg>
Ermine: if you want a clang-compiled kernel run openbsd
<Ermine>
Nah
<heat>
doesn't free also use clang?
<heat>
yeah it does
<heat>
i think out of those 3 only netbsd still uses gcc for some stuff
<Ermine>
Fwiw, Minix uses gcc for arm build because there are bugs in clang build
<heat>
i'm honestly a bit sad that people are starting to forget gcc
<heat>
it's a venerable toolchain
<zid>
can I use clang with msvcrt
<heat>
yes
<nikolar>
that's true, i don't think they are forgetting it
<nikolar>
just avoiding gnu i guess
<zid>
can it deal with gcc static libraries
<zid>
that'd be super rad
<heat>
I don't know
<zid>
I had a bunch of random .a files for sdl and stuff
<Ermine>
libgcc?
<heat>
clang has a cl.exe emulation mode, clang-cl
<zid>
fuck cl I want clang-gcc.exe
<heat>
that would be clang
<zid>
-l:SDL.a
<heat>
mjg, how stupidly unfair is my spinlock on NUMA systems?
<heat>
I would expect "very"
<Ermine>
You mean SDL.a built with gcc? And you want to have it to be linked with clang-built code
<Ermine>
?
<mjg>
heat: that depends on the cpu
<mjg>
heat: what it is first and foremost is pessimal af
<heat>
dude what
<heat>
it's pretty optimal?
<mjg>
for a numa setting
<heat>
you're not getting anything better out of a test-and-set spinlock
<mjg>
i remind you that with correct lock you either get high lock/unlock rate *or* low tail latency
<mjg>
your lock provides neither
<mjg>
s/correct/optimal depending on usecase/
<mjg>
once more i refer you to the mcs paper
<heat>
what's incorrect about my lock?
<heat>
it's a fucking test-and-test-and-set lock
<heat>
plain and simple
<heat>
it's not optimal but it's a thing
<mjg>
19:06 < mjg> s/correct/optimal depending on usecase/
foudfou has quit [Ping timeout: 255 seconds]
<mjg>
you specifically askd for numa
<mjg>
it is shit on numa
<heat>
yes, I'm just asking how unfair it is on numa
<mjg>
19:04 < mjg> heat: that depends on the cpu
<heat>
since farther cores will just always be late to cmpxchg right (when under heavy load)?
wand has quit [Ping timeout: 255 seconds]
<mjg>
what will endu p happening once more depends on how cpus decide to deal with it
foudfou has joined #osdev
<mjg>
normally the line will roam a little on one socket, get out to another one and roam there
<mjg>
and that will keep happening back and forth
<mjg>
consider the following:
<mjg>
you grabbed the lock
<mjg>
everyone else keeps polling on it
<mjg>
once you release it, for all you know all the cpus will spot it at the same time
<heat>
"Test-and-set suffices when using a backoff scheme; test-and-test-and-set is not necessary. " <-- why?
<mjg>
that *mass* fucking armageddon is what makes the lock suck
<heat>
right
<heat>
and in the exponential backoff case since you're unlikely to have all CPUs spot it at the same time you can just test-and-set
<heat>
ok
<dh`>
but while you're holding it, test-test-and-set reduces bus traffic
<dh`>
so it probably doesn't matter if it's a lock where you grab it and do three or four things, but if you need it for a bit longer it might help
wand has joined #osdev
<dh`>
I suppose that's balanced against: when you do get the lock you incur two cycles of bus traffic instead of one (first to get a readonly copy, and then to claim it exclusively)
heat_ has joined #osdev
heat has quit [Ping timeout: 260 seconds]
epony has quit [Remote host closed the connection]
epony has joined #osdev
heat_ is now known as heat
<mrvn>
What do you mean by test-and-test-and-set? test, atomic test-and-set?
Arthuria has joined #osdev
<mrvn>
.oO(Can't we just have a wait queue for cores in hardware?)
<mrvn>
dh`: On a system where exclusive access locks down (the bus for) all CPUs you wants to first test without exclusive.
<heat>
mjg, i've read the relevant mcs paper bits
<heat>
what now
<heat>
1) this was written in 1991 and I don't know if this holds up 2) apparently getting a good mcs lock for weakly ordered systems is a PITA 3) as far as I've heard, mcs is still slower than something like ticket, etc for lower CPU counts
<mjg>
welcome to the suck
<mjg>
there is *NO* such thing invented as an optimal spinlock
<mjg>
see my previous remark about throughput vs latency
<mjg>
the pragmatic thing todo by default isto be fair, thus mcs, clh or whatever else with fariness
<mjg>
with understanding it does sacrafice performance for most cases
<moon-child>
mrvn: maybe, but are you prepared for your snoop traffic to go up an order of magnitude? Now you have to discover not only who owns a cache line but also who else wants it too
<moon-child>
mrvn: this is something I've been thinking about lately, because if you could solve that problem, you could solve a much more interesting problem with wait-free algorithms
<moon-child>
say n different cores figure out they all want to fetch-and-add to the same location, and they somehow manage to get themselves into some order. Then they can compute a prefix sum of the value they want to faa, and then just the last guy in line grabs the location, does an add, and also broadcasts the value there to all the other cores in line
<moon-child>
this would allow you to have n cores swarm a single location with faa, and have it complete in only log~ish time
<heat>
mjg, something cool is that linux qspinlock acts more or less like a test-and-set in uncontended cases
<mjg>
burp maybe i shoud also add there is other concerns, like lock size
<mjg>
it's all tradeoffs
<heat>
they also somehow compressed the whole mcs thing in 4 bytes
<mjg>
i don't know what they did, but there is not much 'somehow' to it probably
<heat>
i've read some comments on the thing and understood very little
<mjg>
the stock standard idea is to compress kernel pointers by cutting of half
<mjg>
and filling the rest
<mjg>
which is whati m guessing they did
<heat>
nope, no pointers
<mjg>
alternatively they guarantee all threads come from a specific va range
<mjg>
so you don't need 8 bytes for it either
<heat>
you can just use cpu numbers
<heat>
part of it I think is that they use cpu numbers-ish (not exactly I think??)
<heat>
plus the qnodes get suck in percpu space
<heat>
stuck*
<heat>
it's confusing honestly
<mjg>
again tradeoffs
<mjg>
there is funzies in there
<mjg>
for examle how do you know you got the right thread address should you want to inspect the state
<bslsk05>
lore.kernel.org: Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible - Mateusz Guzik
<mjg>
thanks gcc
<mrvn>
moon-child: The point of the non-atomic first test is to not own the cache line.
<mrvn>
moon-child: This assumes that the test in an atomic test-and-set takes longer or blocks other uninvolved cores from progressing.
<moon-child>
I was responding to 'Can't we just have a wait queue for cores in hardware?'
<mrvn>
moon-child: oh, right. But that would mean all fetch-and-add pause the cores and then as each core releases the cache line the next core wakes up and continues.
<bnchs>
hi osdev
<lav>
hi bnchs
<bnchs>
mew
<lav>
mew
* bnchs
pets lav
<moon-child>
mrvn: my point is: for a lock, the best we can do is to have each core sequentially acquire it; a hardware wait queue might help with this. But if we had the machinery to implement a hardware wait queue, we could use it to implement fetch-and-add which is _faster_ than having every core acquire the location and add to it sequentially
<mjg>
whoa -mstringop-strategy=alg
<mrvn>
moon-child: not really. Unless you have a special queue for just fetch-and-add
<mjg>
Override the internal decision heuristic for the particular algorithm to use for inlining string
<mjg>
operations. The allowed values for alg are:
<mjg>
reps, byte loops, unrolled...
* mjg
likes gcc ngl
<moon-child>
'special queue for just fetch-and-add' is exactly what I mean to have
<moon-child>
that's easy. The hard part is building up any type of queue at all
<mrvn>
moon-child: and how should that become better than linear?
<moon-child>
like I said, you can compute a prefix sum in log time
<heat>
mjg, why are you doing linux dev?
<moon-child>
and you had to do linear work anyway
<mrvn>
not with fetch-and-add returning the value of the operation
<moon-child>
yes, with fetch-and-add returning the value of the operation
<mjg>
heat: lulz
<moon-child>
mrvn: c0 through c3 want to faa v0 through v3 to l. They work this out and arrange themselves into a queue. c0 computes v0; c1 compute v0+v1; c2 computes v0+v1+v2; c3 computes v0+v1+v2+v3. Then c3 acquires l, adds v0+v1+v2+v3 to it, and broadcasts the previous value at l to c0 through c2
<mjg>
heat: i did something faster than linux in freebsd, so fixed that in linux
<mjg>
heat: gonna fix up some other shit so i can go back to claiming linux being faster
<moon-child>
c0 through c2 then add the intermediate sum they computed to the value c3 broadcasted to them
<heat>
mjg, btw what do you think of linux being inline happy?
<mjg>
is it
<mjg>
lemme disasm
<mrvn>
moon-child: and that's wrong. You need to broadcast l, l+v0, l+v0+v1, l+v0+v1+v2
<heat>
i noticed yesterday that the whole test-and-set and ticket spinlock stuff is fully inlined
<heat>
and so is the kzalloc stuff you were looking at
<heat>
qspinlock ofc isn't due to non-trivial amounts of code
<moon-child>
mrvn: depends on whether it's a post-increment or a pre-increment. But that's an irrelevant detail; you get the idea, right?
<mrvn>
moon-child: and v0+v1+v2+v3 takes linear time
<mrvn>
moon-child: my values where pre-increment
<mrvn>
aeh, post-increment I mean. sorry
<mrvn>
pre-increment would be l+v0, l+v0+v1, l+v0+v1+v2, l+v0+v1+v2+v3
<moon-child>
mrvn: v0+v1+v2+v3 takes logarithmic time
<mrvn>
You don't get around computing all 4 additions.
<moon-child>
remember we have n cores to work with here
<heat>
mjg, fyi i think you and linus are soulmates
<heat>
GOOGLE ENGINEER BRUTALLY SLAMS INTEL AND AMD ENGINEERS by calling THEIR architecture STUPID
<mrvn>
What's the solution for a 'volatile std::bitset<16u>'?
<geist>
yah this one is on AMD
<mjg>
:]
<mjg>
AMD ENGINEERS DESTROYED BY FACTS AND LOGIC
<geist>
there's a new fun one i've been dealing with on riscv: using registrs when writing asm that let it use the compressed forms
<moon-child>
sometimes I wonder how far you could get if you just cleaned up the x86 encoding moderately and did a thing to translate binaries in place
<heat>
i'm ready for thesun.co.uk
<geist>
it's difficult, and the assembler is free to replace instructions as it sees fit
<mrvn>
heat: Single Transation UPdate Instruction Descriptor?
<moon-child>
maybe wider decode, smaller insns
<CompanionCube>
heat: The Register, surely?
<moon-child>
compressed insns are interesting. One thing I kinda wonder though is to what extent you have to trade off scheduling to get the pairable insns next to each other
<mrvn>
moon-child: it would fail the first time you have self modifying code or code and data mixed together.
<sham1>
Here comes TheSun
<geist>
yah duno. and how much does the compressed isns matter on current riscv hardware vs futire tuff
<heat>
CompanionCube, i'm more versatile than that
<geist>
it would only reallym atter because it'd increase icache hits presumably, but that may not be the bottleneck
<sham1>
Uuugh, I have to do machine learning model performance estimation
<heat>
i can BRUTALLY SLAM keir starmer as well
<moon-child>
mrvn: yes, but can be worked around. Trampoline to os to re-translate or w/e
wand has quit [Remote host closed the connection]
<mrvn>
geist: how much icache do modern cores have?
<geist>
in general, usually 32 or 64k
<mrvn>
moon-child: somehow you can. Don't ask me how but that x86 emulator for AArch64 seems to handle it really well.
<geist>
the apple silicon is the outlier that i know abut with 192k
<heat>
geist, i think they're refraining from doing too much optimization work on linux riscv because of exactly that problem
<heat>
Who Knows how things will look like in real good riscv implementations
<geist>
heat: yeah i ca see that. the curret cores are mostly in order implementations that you can't do much with
<zid>
quick, lock the hardware into exactly the optimizations linux happens to support for it
<moon-child>
geist: oh interesting have a ref for that?
<moon-child>
wiki only has the d$
<geist>
moon-child: hmm, yeah i've seen it referred a few times in some deep dives
<geist>
and folks have probed it pretty easily
<geist>
but now i say that i dunno if they changed aythig on M2
<geist>
this was for M1
<mrvn>
geist: must be a reason why icaches haven't grown much. *hint* *hint*
<moon-child>
didn't see any cache info in dougallj's docs. Might be in maynard handley's manual; haven't looked too closely in a bit
<heat>
a good one is qspinlock (mcs locks). no one knows how atomics will actually work in real hardware
<heat>
they (the riscv people) say that the current SMP implementations are stupidly bad
<bslsk05>
arxiv.org: [2302.01107] A Survey on Efficient Training of Transformers
<moon-child>
current as in current riscv, or current everything?
<sham1>
GeDaMo: Too bad Python is terrible
<sham1>
And not sure sklearn has or even will adopt any stuff like that
<geist>
heat: yeah i think that may be true. i've been wathcing the visionfive 2 do some stuff and it seems to spend an inordinate amount of sys% time doing what seems liek regular stuff
<bslsk05>
wiki.osdev.org: File Systems - OSDev Wiki
<sham1>
For better or worse, a FAT-like file system is probably the most "obvious" type of FS, which is why that page even exists
<sham1>
To warn exactly about that
<Cos-Dever>
sham1: FAT is not obvious
<Cos-Dever>
I try to understand that shit last week and it make no sense at all
<zid>
sham1: I AM DOING THE DISAGREE
<immibis>
inventing your own fliesystem is not obvious, either
<immibis>
once you make inventing your own filesystem make sense, it will be like FAT
<mrvn>
Cos-Dever: have you implemented FAT or ext4 or something else?
<sham1>
Not obvious? It's a linked list of clusters for files. That's like the most obvious you can do
<sham1>
While having it be a meaningful file system
<Cos-Dever>
Mrvn: I have not implement the FAT and I think I will never because it is crazy FS. No one would ponder up that design on their own. I did do Ext2 driver.
<mrvn>
Cos-Dever: when you do your own it will be like FAT, crazy.
<Cos-Dever>
sham1: Linked list in a file system!!! It is crazy... Any Liceum student will find a linked list, not the proper datastructure for file system
<zid>
sham1: please be doings the improving of your brain
<Cos-Dever>
mrvn: I already do my own, I have it reading and not yet writing. It is mostlike UFS, except I substitute the pre-allocated inodes for a special Inode 3, which contents of that file are inodes
<sham1>
Right, a linked list isn't the best thing one can use for it, but it is very simple which is why Bill Gates (allegedly) created it in the first place like this
<Cos-Dever>
The files are boringly made the traditional way of direct blocks, indirect blocks, doubly indirect blocks, triply indirect blocks... Now this is one thing the OS Dev Wiki should complain about that, your file system will probably be block based instead of utilising some kind of extent B-Tree like the clever filesystem is using
<geist>
keep in mind that this channel has really nothing to do with the wiki
<geist>
except we link to it as a source of info (or misinfo)
<sham1>
Misinfo
<geist>
that being said i think the FAT part of the FAT file system is kinda reasonable, just not ideal. it's thel ayout of the rest of the structures that are very 70s and could be done much cleaner
<geist>
possibly as exfat has done, though i haven't looked too closely into exfat yet
<Cos-Dever>
Yes, I see no one want to take responsibility for that wiki. I complain to OS Dev Discord Server also. They dismissed the wiki, they say it is too x86 and they laugh about its wrongs. I only read File System article so far
<geist>
ie you could build something with proper dirs and inodes and a FAT for the chaining of blocks and that'd work alright
<geist>
that's the point of a wiki, it's maintained by volunteers
<geist>
we dont 'own' it at all
<heat>
hello its me the owner of the wiki
<geist>
no one does, except the guy that actually runs it, but i think he's mostly AWOL
<heat>
my property
<sham1>
> it is too x86
<Cos-Dever>
Then which keeps the institution of the wiki? I thought, it would be here or OSDev DIscord, since they share the brandname
<sham1>
Well, the Discordians here aren't exactly wrong
<geist>
nope. the wiki simply exists because someone made it and folks added to it over time
<geist>
same with the osdev.org forums and whatnot
<geist>
the irc channel predated all of those by some number of years
<geist>
sham1: agreed
<moon-child>
♥ fragmented ecosystems
<geist>
i've found the wiki is reasonably good at dissiminating stuff you could look up but is nice to put in one spot (x86 bits, some info about legacy PC peripherals, etc)
<heat>
moon-child, cringe ASCII heart
<moon-child>
fuck x86, but also I'm gonna be sa dwhen it dies
<zid>
I like the pci parts of the osdev wiki
<Cos-Dever>
Why will there not be new wiki which is more corrected? I think you gentlemen sound honorable and knowledged, and not proudy and wrong as the Wiki
<geist>
but it's bad at opinions and whatnot, which is what Cos-Dever seems to have found
<zid>
it's hard to find the real specs
<heat>
❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️ chad unicode heart emoji
<sham1>
It'd be nice to have someone clean up the wiki and clearly separate the x86-specifics from the general concepts. But ain't nobody got time for that
<geist>
Cos-Dever: it's a public wiki, you can edit it yourself
<Cos-Dever>
It is true of OSDev Discord also, even if the language they use - foul
<FireFly>
well, as geist mentioned a wiki is a product of its editors, so why start a new wiki instead of improving the existing one?
<geist>
Cos-Dever: yes, that's generally why i dont hang out there
<FireFly>
but yeah, I guess feel free to edit it
<geist>
but yeah i think things like 'design your own fs' shouldn't have a bunch of opinions in it and be more of a facts based page
<geist>
ie, here are some things to consider
<heat>
moon-child, some of them are easy to get to fall off a truck
<Cos-Dever>
But in either community I see that the people, they have knowledge, they are not proudy in wrong opinions
<sham1>
I like this IRC channel/Matrix room more than the Discord channel. Of course a big factor is that the latter is absolutely proprietary
<heat>
other, niche ones? impossible
<geist>
sham1: aww thanks. yeah i've been trying to maintain some level of decorum here so that we're at least 'better' than the discord in one way
<geist>
it's probably inevitable that discord or whatever replaces it will eventually 'win' but <shrug>
<Cos-Dever>
And I read this wonderful free book which help me to design the filesystem. It is called Giampaolo's Practical Filesystem Design. But on OSDev Wiki? Not mention this wonderful book
<moon-child>
heat: ?
<geist>
yah dbg's book is great
<moon-child>
FireFly: wait you're here too o.o
<geist>
i worked for dbg at Be back in the day
<geist>
he actually ran the draft by me at some point before publishing it
<FireFly>
moon-child: y-yes? I've been here for ages :p
<heat>
moon-child, ?
<geist>
hi FireFly
<Cos-Dever>
Indeed you are honourable gentleman, BeOS is called excellent
<FireFly>
hiya geist
<sham1>
I do sometimes like to read the OSDev forums, but especially the general OS development subforum is a bunch of people being like "why this no work". And the OSDev Reddit is… well, it's Reddit
<geist>
yah the trick is to teach folks how to find the information they need, and get them on a good path to learn
<geist>
since you can't just fix everyones problems all the time
<heat>
but getting newbs to make their own filesystem is silly
<sham1>
The screenshot thread is fun, though
<heat>
so saying "probably a bad idea" is a good idea
<geist>
yeah, i didn't look at the page they linked but it's probably worth at least mentioning that it may not be a good use of time
<Cos-Dever>
I do not like the Reddit. They argue, saying, Microkernel is bad, and the others they argue, saying Microkernel is good, and both of the side, they argue like two men who claim support of rival cricket clubs, but their behaviour isnot worthy of the game, and their argument is not about the technical skill of the cricketer
<geist>
and they dont even take tea time like in cricket!
<sham1>
smh the wiki doesn't even mention btrfs
<Cos-Dever>
But then I go here, I find BeOS person, on OSDev Discord is VMware person. It is good, that there is some communitys where you can speak to someone who can say: I am speaking from my experience
<Cos-Dever>
And this is what is good in Giampaolo's Practical Filesystem Design. He is not the lecturer who talk about conceptual design of an OS like two blind man arguing what the beautiful painting is. No, that is indeed the way of one who cannot help you
<geist>
the only real downside of his book is it's written in 1999 and is tech of the era. nowadays more modern designs tend to be much more snapshotting/tree based
<geist>
even his next fs (APFS) is a completey different design
<heat>
microkernels suck
<sham1>
heat: how dare you
<moon-child>
ukernels are gonna kick your ass
<moon-child>
ukernels are totally gonna win the championships this year
<Cos-Dever>
geist: Yes, I see that now under the sun there is mostly B-Tree filesystems where the write is always a copy
<heat>
lets have a usenet argument over this
<geist>
now now heat
<moon-child>
let's not let things get heated
<sham1>
hah
<Cos-Dever>
I do not think there is a book like Giampaolo's Practical Filessytem Design about this modern kind of filesystem, but if anyone will write it, I will buy it gladly
<heat>
geist, fwiw extent-based filesystems are still the best ones IMO, particularly when it comes to stability and perf
<heat>
no one beats trusty ext4
<sham1>
But btrfs is better. It's in the name
<heat>
no, it's butter fs
<moon-child>
butterface
<Cos-Dever>
I look at btrfs, they are the radicalest filesystem of the everything as B-Tree persuasion
<geist>
heat: yeah mostly agree
Ermine has quit [Remote host closed the connection]
<geist>
even old designs ie NTFS are still forward extensible, because they're solid extent based designs
<Cos-Dever>
But the ZFS, they have a design unlike it, very radical unique. I see they refuse the extents, it seem they use the traditional blocks, but the blocks, the size varies between files
Ermine has joined #osdev
troseman has quit [Read error: Connection reset by peer]
mctpyt has joined #osdev
Cos-Dever has quit [Quit: CGI:IRC (EOF)]
<mrvn>
Is there any new FS (post ext3) that doesn't use B-trees?
* mrvn
would say that zfs uses extends. The size is just limited to 128k per default.
mctpyt has quit [Ping timeout: 252 seconds]
vdamewood has joined #osdev
<gog>
hi
<lav>
hii
<gog>
:3
<dh`>
if you're going to have key lookup, btrees are generally the best way to do it
<vdamewood>
Hi
<dh`>
and there are usually things with key lookup in a fs somewhere
<dh`>
the alternative is going back to e.g. linear search of directories and nobody thinks that's a good idea
* vdamewood
gives gog a fishy
<heat>
dh`, linear search on dirs is not a bad idea for small ones
<gog>
:o
* gog
chomp fishy
<dh`>
eh
<Ermine>
gog: may I pet you
<gog>
yes
* Ermine
pets gog
* vdamewood
loves to see people ask for consent
<heat>
i think linux itself only creates the htree on a dir once it goes past a block in size
* lav
is fishy
<heat>
(on ext4)
<dh`>
for ordinary small dirs that are frequently accessed it wastes noticeable amounts of cpu because the block's in memory
<vdamewood>
ha ha ha, gog go prrr
<heat>
if they're frequently accessed, you're not hitting the fs
<dh`>
and for large dirs linear search is terrible
<dh`>
that depends on how your namecache works
<vdamewood>
Is a checking account L2 cash?
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat>
i wish i went to clown college
<vdamewood>
heat: You didn't? You seem so good at it.
* vdamewood
runs.
<heat>
heheheheheh ehe he he he he
* heat
cries
<vdamewood>
PikachuAndCaterpie.jpg
<gog>
sorry
<gog>
i'm sorry
<Ermine>
vdamewood: professionals have STANDARDS.
<vdamewood>
Ermine: Andf I thought my joke was cruel
<dh`>
e.g. with a more or less conventional namecache if you open a directory and stat every file in it, you do N lookups in the fs and cache all the results (then probably never use them again)
<heat>
yes
<heat>
and I would guess that going through a linear search on a single block (4KB tops) is better than doing a fancy data structure for such a small dir
<dh`>
apart from it's not unusual to use larger blocks, especially on SSDs, probably not
<heat>
well im talking from a Linux POV, no such thing as a block size > PAGESIZE
<dh`>
if there's 100 entries, that's 10000 strcmps
<dh`>
well, that's an architectural bug in linux, hadn't realized it was still true
Arthuria has quit [Ping timeout: 260 seconds]
gxt__ has quit [Ping timeout: 255 seconds]
gxt__ has joined #osdev
<mrvn>
dh`: directories you can easily use a hashtbl.
<mrvn>
They really are way too small for a B-tree except the one that isn't.
<mrvn>
Also the way you handle dentries in memory and directories on disk doesn't have to be the same.
xenos1984 has joined #osdev
<mrvn>
dh`: Note: 100 entries is ~5000 strcmps. N * (N - 1). Or just one readdir2 call for all 100 entries in one go.
<heat>
dh`, i don't think its an architectural bug honestly
<heat>
unless you completely switch up the way struct page -> struct buffer_head works
<mrvn>
heat: I think that block size > PAGESIZE only holds for the block cache. And ext2/3/4 has no support for blocks > PAGESIZE because it maps file data directly to the block cache. Although with extends that's different.
<heat>
tbf I have no idea how any of the BSDs approach this problem
<mrvn>
heat: I think that problem is an artifical design shortcut Linux did. Nothing more.
troseman has joined #osdev
* mrvn
hands out burgers and fries.
<bnchs>
is it okay to be obsessed with something?
<mrvn>
breathing?
<heat>
yes and no
<bnchs>
mrvn: yes breathing is important
<gog>
hi
<bnchs>
hi gog
* bnchs
patpatpat gog
* gog
prr
<Ermine>
Our cat likes being patted with a fist. This is strange
<netbsduser>
it was once reported to me that some people like to use their filesystem in a role where people would typically prefer a relational database
<netbsduser>
this includes filling folders with millions of entries (each representing one record)
<zid>
that's called "phone users"
<zid>
they have no idea what a filing system is
<zid>
they just search by metadata
<bnchs>
zid: sus
<bnchs>
and it has a red tint
<bnchs>
is that a hint?
<netbsduser>
phones do make an interesting argument for going beyond the traditional hierarchical filesystem
<netbsduser>
and at least they now exist so we are getting valuable lessons that will hopefully stop the ambitious from rushing into throwing away the good-old-way without considering what they're losing in doing so
<sham1>
Database filesystems are not exactly a new idea
<netbsduser>
bnchs: i assume it's about the Sus Law
<bnchs>
didn't the wikipedia article about the Sus Law get edit-locked?
<bnchs>
or something
<lav>
It's got pending changes enabled currently
<bnchs>
yeah
<netbsduser>
probably, i suspect it's a hot button issue now that there are people who probably want it to return
<bnchs>
i like looking at the vandalism revisions
<heat>
it's edit locked because amogus sus
<bnchs>
>In England and Wales, the sus law (from "suspected crewmate"[1]) was a stop and search law that permitted a police officer to stop, search and potentially eject people on suspicion of them being impostors. Preventing impostors from venting had a marginal impact on crime in the UK.[2]
<heat>
hahahahaha
wootehfoot has joined #osdev
<bnchs>
you want it? it's yours my friend
<heat>
mjg: ^^ this is genz humor
<mrvn>
netbsduser: Bioinformatic users split DNA sequences into 3 letters + metachar per file.
terminalpusher has joined #osdev
<netbsduser>
mrvn: this is exactly the use case i heard about, geneticists love this approach for some reason
<mrvn>
netbsduser: it's the most stupid approach possible.
<bnchs>
heat: gen z humor is still humor
<heat>
absolutely
<netbsduser>
mrvn: probably a fair judgment
<netbsduser>
i understand some genes got renamed because Excel enthusiastically parses them into dates
<mrvn>
netbsduser: they still do that on a network filesystem with 1MB block size.
<mrvn>
netbsduser: hehe, heard about that problem too
<zid>
I believe the glass is second of january full.
<mrvn>
but it's the 4th of march
<bnchs>
the joke is that the glass is 2/365 full...... it doesn't make any sense
<heat>
which, funnily enough, is completely ignored by gcc and clang for backwards compat reasons
Amorphia is now known as theWeaver
<zid>
where
<zid>
a struct declaration is ot UB
<mrvn>
heat: where is the UB?
<netbsduser>
have you ever read the c spec? even the way you close a door is technically undefined behaviour
<zid>
Relatively little is UB
<zid>
just some surprising things if you've never considered how you'd design a language like C
<heat>
zid: 93 /* Variable size, according to # colors. */
<zid>
a lot is IDB though
<heat>
but then } color[1];
<zid>
heat: You mean that later they do color[>0] somewhere else?
<heat>
yep
<mrvn>
heat: I would say lines 131, 177, 216, 253, ... are UB
<zid>
yea that's just old, and was defined by the compiler they used
<mrvn>
heat: comments are always wrong, they aren't UB
<heat>
no, it's recent
<heat>
but still defined by the compiler they use
<heat>
because people write bad code like this
<zid>
they did this *recently*? dumb
<mrvn>
heat: make a patch to "color[]"
<heat>
"Copyright (c) 2019 The NetBSD Foundation"
<zid>
although if they've gone -fno-vla or whatever
<zid>
but the pre-vla way to do that was [0] which is less ambiguous
<mrvn>
heat: and then deal with the fun of calculating the size of that struct for alloc.
<heat>
structs have no vlas I think?
<zid>
They're called FAMs
<zid>
flexible array members
<mrvn>
heat: sure they do. It's C
<zid>
I'm not sure if disabling VLAs also disables FAMs in gcc
<zid>
But both were added in C99
<heat>
no
<heat>
and yes the standardized version is [];
<zid>
I've had to deal with the [] vs [0] vs [1] crap before
<heat>
[0] is a GNU extension
<zid>
it breaks my HID code sometimes
<mrvn>
zid: Are you thinking of void foo() { int x; ... char bla[x]; }?
<zid>
that's what I said
<netbsduser>
the standard is just a bizarre compromise designed to allow C as it traditionally was to fall within (but frequently in the boxes of 'UB') a category that could also fit C for IBM AS/400 with its strange notions
<zid>
It's defined by their compiler, but before C99 it was defined via [0]
<zid>
it's now defined by the standard as []
<netbsduser>
and a lot of GNU extensions appear to be in traditional C compilers (as in Unix ones)
<zid>
C hasn't been updated since C89 as far as I am concerned, they just backported crap from C++ and never fixed anything
wand has quit [Ping timeout: 255 seconds]
<zid>
still no way to get the length of an array, to test for endian, or thousands of things that actual C programs do, but now we have.. nullptr? thanks.
<zid>
C23 really saved C
<mrvn>
zid: there is no array. It decays. :)
wand has joined #osdev
<heat>
you do have a way to get the length of an array?
<zid>
no you do not
<heat>
sizeof(arr)/sizeof(arr[0])
<zid>
exactly
<zid>
you have a macro you write into every fucking project
<heat>
what's your proposal?
<heat>
_Length(arr)?
<zid>
it's been 30 years and compilers still aren't allowed to just provide it under a standard name
<mrvn>
zid: how is that going to work with arrays passed to functions?
<zid>
I don't care what it's called as long as it's standard, I can learn it a priori
<zid>
and not have to learn the specific name used in every single codebase
<netbsduser>
i forgot what C++23 is
<zid>
Yea that's called braindamage, it's what happens after you read C++ specs
<netbsduser>
is that the one with anonymous functions?
<zid>
The memory loss is permanent, sorry
<mrvn>
netbsduser: it's the one with nullptr
<netbsduser>
C23 rather not C++23
<heat>
netbsduser, no, lambdas have been present since C++11
<heat>
and C has no lambdas
<netbsduser>
i'm sure i heard somewhere they wanted to put them in C23 but maybe it got rejected
<zid>
C23 does have some good in it, but it was trivial things that should have happened in 991
<zid>
1991*
<zid>
removing K&R decs
<heat>
C23 is full of good value adds
<mrvn>
are trigraphs still a thing?
<zid>
then adds some silly C++aboo crap
sebonirc has quit [Remote host closed the connection]
* Ermine
wonders what trivial things should have happened in 991 but haven't
sebonirc has joined #osdev
<Ermine>
zid: like which
<zid>
Ermine: After pope john XV ratified the truce of god he should have sent a thank you note
<heat>
nullptr is an obvious one
<zid>
oh I meant 1991 right, trivial C shit should have been removing 0 being legal for NULL
<zid>
K&R decs, implicit int return values
<mrvn>
remove implicit declaration, type defaults to int
<zid>
enum storage size
<zid>
make enum types incompatible
<heat>
you can't remove 0 being legal for NULL, hence nullptr
<zid>
You totally can.
<mrvn>
enum storage size?
<heat>
and you break half of software
<zid>
If you can remove K&R decs, you can remove 0 being legal for NUL.
<zid>
You do not break half of software
<mrvn>
zid: a lot of software does ptr = 0;. But you can start with requiring NULL as ((void*)0)
<zid>
*no* fucking implementation do it that way, all it does is cause you to code around potential bugs if they *happened* to have done it that way, because the implementation is allowed to do it
<zid>
but they don't
<zid>
and if they do, they're shit and dumb, because it causes bugs
<Ermine>
So I have to use NULL instead of 0?
<heat>
the point of C is to support shit and dumb because C is shit and dumb
<mrvn>
Ermine: or cast
<zid>
no, the problem is using NULL for invalid pointers in varargs
<zid>
The C spec allows either 0, or (void *)0 as the value for #define NULL
<zid>
and varargs can't tell if you mean pointer or integer unless you tell it, so printf("%p", NULL); is just an outright bug
<mrvn>
^^ and that part they could have easily fixe3d
<zid>
if #define NULL 0, then varargs sees an *integer* zero there
<zid>
happily pushes a 32bit int to your stack or whatever, then %p pops a 64bit pointer
<zid>
so you have to do printf("%p", (void *)0); for literally no reason other than to prevent that bug, which won't even happen, because anybody who writes stdlib.h is *aware* of that issue
<zid>
because the spec is being stupid there
<mrvn>
zid: Most of the time though that works because archs where int != ptr tend to pass args in regs.
<\Test_User>
printf takes unlimited args, which comes out to be more than the number of registers
<mrvn>
\Test_User: and how often do you actually have that and pass NULL?
<zid>
\Test_User: You don't know my life! Maybe I have infinite registers! :(
<\Test_User>
could also come up with a function you'd be more likely to pass NULL to that does the same
<mrvn>
\Test_User: only happens with varargs though
<\Test_User>
mrvn: was saying printf bc that was the example there
<mrvn>
(or implicit prototypes)
<zid>
main reason you end up passing NULL to varargs is via macro expansion
bradd has joined #osdev
<zid>
and it's handy to not have to special case it for printing out a linked list or whatever
<mrvn>
The sad part is that gcc / glibc even now still has a "#define NULL 0"
<zid>
where not every member might be filled out
<zid>
or just any random struct I guess
<mrvn>
Check the headers, it has some #ifdef picking one of 3 defines and one is 0
<\Test_User>
structs have a type attached, so no problem there?
<\Test_User>
or passing null as the "ptr to struct"
<zid>
like how writing to an int via a char * then actually using the int might cause a trap, as long as you *know* the representation of int, it's fine
<netbsduser>
if GCC changed this they would basically be declaring open war on C as in the language that linux, freebsd, windows, etc are implemented in
<sham1>
Look ma, no undefined behaviour
<zid>
sham1: just assign it if you have compound literals
<zid>
rather than memcpying
<mrvn>
sham1: the compiler converting a = {0} to memset relies on the implementation knowledge of what a NULL is
<zid>
like I said, it's shorter anyway
<sham1>
With an allocated instance? Eh, could also do that I suppose
<zid>
I do it when I remember to care
<sham1>
mrvn: but the implementation does know what it is, because the implementation imposes it
<\Test_User>
how do you #if with bit representation
<sham1>
You don't
<\Test_User>
sad
<zid>
there's an annoying macro you can write
<zid>
it ends up looking like #define ICE_P(x) _Generic((1? (void *) ((x)*0) : (int *) 0), int*: 1, void*: 0)
<mrvn>
What really screws you is the compiler chaning: void * memcpy(void *dst, void *src, size_t len) { char *d = dst, *s = src; for (size_t i = 0; i < len; ++i) { d[i] = s[i]; } return d; } into a memcpy call.
<zid>
you need to rely on 0 being an integer constant, and (void *)0 not being one somehow, and cause a bifurcation in the behaviour because of it, have fun
<sham1>
Ah yes, that is a funny thing. At least it can be suppressed, but it only needs to be done in one translation unit anyway
<zid>
Another thing C could just add in 1991, an endian / integer representation etc macro set
<mrvn>
zid: endian.h?
<zid>
I've written *so* many probably incorrect ifdefs to try to detect endian at compile time
<heat>
geist, I did briefly think about that but I don't know how much leeway you really have there
<mrvn>
/* Copyright (C) 1992-2022 Free Software Foundation, Inc.
<mrvn>
missed it by a year
<heat>
I know musl doesn't have an optimized string impl for riscv
<geist>
heat: yeah i guess the real question is if there's value in having a version that assumes unaligned vs aligned
<geist>
since it's defined by the arch as supporting unaligned accesses, but firmware may trap and emulate
<geist>
and thus you probably want an aligned version
<mrvn>
heat: why do you care about endianess?
<sham1>
Do I have to link Rob Pike's essay here again
<mrvn>
Write your code in such a way that the endianness is not a factor and let the compiler optimize the NOP cases.
<zid>
Is it that comments are bad
<heat>
comments are bad mkay
<mrvn>
no, no, no. Comments are always right, the code is bad. We have to remove that.
<zid>
comments are bad
<zid>
They're a code smell for poorly named variables and lack of static functions
<mrvn>
Lets make source files just comments that gets passed to chatgpt | gcc
<heat>
no
<zid>
If it needs an explanation regardless, Documentation/design_goals_of_banana_layer.txt
<heat>
comments are useful in moderation
<sham1>
Oh I was thinking about the byte order fallacy one
<sham1>
I don't think Mr. Pike has any special thoughts about comments
levitating has quit [Ping timeout: 248 seconds]
<sham1>
But yeah, comments are more often than not bad. Even if it's not just repeating what the code is saying, a problem is keeping the comments from drifting away from relevance
<mrvn>
The worst is when comments describe the contract instead of the code doing it.
<geist>
yeah this nonsens about comments are bad is silly
<zid>
What the issue is is that we use text files for source code, without things like references and links to diagrams and shit, if needed
<geist>
obviously bad comments are bad, but helpful comments are a godsend
<zid>
geist: missing the point slightly there though
<geist>
probably
<zid>
the point is that the helpful comments aren't *needed* in good code
<sham1>
Emacs can do hyperlinks from comments. Just saying
<geist>
yeah disagree
<heat>
that's not true
<zid>
if it has comments, it's teaching you how bad code operates because it isn't clear from the code
<zid>
Not saying it's always possible
<mrvn>
sham1: or embed source sniplets in org more.
<mrvn>
mode
<zid>
but what you said wasn't what I was talking about
<geist>
good comments help bootstrap whomever is reading the code to avoid having to process it in their head
<geist>
even if it's 'good code'
<heat>
imagine i write a spinlock impl and don't comment it. now you want to figure out why things are done in the way they are
<geist>
still a lot easier to read a few sentences over overview to avoid you having to deal with parsing some code in your head, even if it's good
<sham1>
This is a topic which is very opinionated. However, comments have and will always have and get bugs
<sham1>
Problem is that comments aren't checked for semantic correctness
<heat>
1) git blame 2) comments 3) ask me 4) read a bunch of pages of spinlock theory
<zid>
geist: yea ideally that wouldn't be a comment, but definitely available somewhere, like Documentation/
<zid>
but easier to actually reference
<mrvn>
There is always as case why you should comment why, what or how your code does. Just hardly ever all at the same time.
<zid>
Like git blame yea
<geist>
maybe? Documentation/ is even easier to get out of sync since it's not right next to the code. but of course depends on the context here
<heat>
Documentation/ is harder to cross reference
<geist>
but at *least* put it in the same repo
<heat>
I would only consider that for external interfaces (i.e I'm documenting a new system call)
<zid>
'1000ft view' stuff in git blame, 20ft view is 'function names'
<zid>
1ft view is 'variable names'
<geist>
yah, or some overall thing, like memory layout of the kernel, etc
<zid>
inch view is comments
<geist>
also re: the 'good code' argument. you're not always i the position of writing good code, or working with good code that self documents
<zid>
If you can't figure out at least enough about a piece of code to successfully ignore if it isn't what you were looking for from the function names, or at worst the variable names, the code is doing something overly complicated in a single function most likely
<mrvn>
geist: I'm annoyed by the .c/.h split already. Makes important stuff be far to far away.
<geist>
so in that case helping out with soe comments is a godsend
<geist>
mrvn: 100%. also one of those RUUUUUUUUST things
levitating has joined #osdev
<zid>
geist: nod, but, <zid> Not saying it's always possible
<sham1>
Of course, there's a difference between having a documentation comment like for doxygen, and your in-code //
<geist>
mrvn: it's much worse in C++ when half the class is declared in the header
<mrvn>
.h files should be compiler output from the .c
<zid>
*ideally* we'd live in an ideal world
<geist>
but rarely do we
<mrvn>
geist: do c++ modules fix that?
<geist>
problem is some of us know this, but not everyone does. so you end up with folks dogmatically applying rules
<zid>
But like, the platonic ideal version of a piece of code probably has fewer comments rather than more comments
<mrvn>
Can you put templates in the .cc file and build a module for it?
<geist>
and you end up with stuff like 'no comments in any code' as a literal rule
<geist>
i know of actual companies that do that. literally.
<geist>
because someone dogmatically applied the logic that 'comments are bad' and thus you end up with a fucking disaster
<zid>
yea that needs to stay in sync with heavy code review, mandatory git blame split-views, or whatever
<zid>
not just be an arbitrary rule with no support
<mrvn>
sham1: +1 for doxygen style commenting
<geist>
mrvn: good question, i honestly dont know how the C++ modukle stuff works
wootehfoot has quit [Read error: Connection reset by peer]
<geist>
i know theres some talk about using it at work, but have to pull everything up to c++20 before you can start to use it, i think
<geist>
though i dont know precisely why
<mrvn>
sham1: -1 for for doxygen style commenting as well, because just listing the function prototype with one sentence does not make documentation
troseman has quit [Quit: troseman]
<geist>
but i tell ya i really hate it when i open some file i didn't write, and you just get pages of code, no comments
<geist>
even if it's great stuff, it puts the onus on *you* to interpret it
<mrvn>
geist: You do "import stl;" and it's faster than "#include <iostream>". That's about my experience level.
<geist>
doesn't mean i can't figure it out in 5-10 minutes or whatnot, but a simple paragraph at the start would really really help
<zid>
yea it's a problem if you don't know *where* to look for the missing comments
<zid>
like, if it doesn't have comments because internally it's all tracked in dot files or git or whatever
<zid>
and you don't have that setup
<geist>
most of the time it's simply because the author understood it, so they didn't comment it
<mrvn>
geist: the module shouldn't be able to say what was in the header or the .cc file. You could compile it with an external cpp. So header should be optional.
<geist>
which makes sense. if you wrote it, it's in your mind, you understand it, so comments dont help you
<mrvn>
geist: have someone else write the comments and then sign off on them.
<zid>
I comment assembly a lot, because I am too lazy to make enums :P
<geist>
but usually for code reviews if i'm reviewing it and something isn't intrinsically obvious i'll ask the author to leave a sentence or two at the point where it's tricky
<mrvn>
only way to make code review
<zid>
lots of magic numbers (stack offsets etc) with magic comments to explain them
<geist>
and i dont see that as a failure to the author at all, sometimes things are just tricky for efficiency purposes, or the alternative is worse, et
<geist>
oh 100% re: assembly. i comment the shit out of that, since it's almost never intriniscally obvoius what's happening
<zid>
It'd be nice if "named block" idioms weren't just so unused in C as to look wrong
<mrvn>
zid: named block?
<zid>
Sometimes I just wanna start a fucking naked block with a comment at the top of it, but it looks sooo unnatural
<zid>
even though it'd be a great tool
<geist>
i have had the curse of using a lot of my code i wrote 10-15-20 years ago on a daily basis, and all the places where i left myself a breadcrumb is nice
<mrvn>
{ // set font to bold, 10pt and Times New Roman .... }
<mrvn>
zid: ^^ like that?
<mrvn>
zid: I think naked blocks are something people that use IDEs that can fold sources use.
<sham1>
mrvn: doxygen does indeed have that problem where people don't always write all the docs and just regurgitate the prototype. Same thing with a lot of javadocs I've seen at work and elsewhere
<geist>
rust has some sort of notion of named blocks, but that's so you can do an inner exit sort of thing
<zid>
Named blocks ^
<geist>
basically 'break out of the named block'
<mrvn>
sham1: what pisses me off is when they do that across the whole project and call that documentation. Even have a separate foo-doc debian package.
<zid>
like, the 'proper' way to do it is to make a static function, but then you lose access to your locals that you might want, so now you're passing in a fuck load of args
<dh`>
<zid> comments are bad
<dh`>
are you mad?
<zid>
that way is tidier, but nobody does it
<zid>
dh`: at what?
<sham1>
It's basically the same as bad comments except it's even worse because comments are supposed to be something I shouldn't need to look at as a user. Docs on the other hand… trrrible
<mrvn>
zid: waste of a good line to have the { on it's own. :)
<zid>
and because nobody does it, you look like a lunatic if you do it
<heat>
what's that zid.godbolt.org stuff
<geist>
well, you can also use whitespace to make a pseudo block. i do that in all of my code
<zid>
godbolt saves the current layout to a cookie
<mrvn>
zid: another reason for naked blocks is to have local variables with RAII
<zid>
domains all get different cookies
<mrvn>
and call the destructor in a timely manner
<zid>
so your layout doesn't get fucked up when someone links you some code if you use a random subdomain
<zid>
unless they link you code from *your* made up subdomain, but with a fucked up layout
robem has quit [Ping timeout: 252 seconds]
<heat>
ah cool
<mrvn>
.oO(Who would be that evil?)
<sham1>
But yeah, comments can be helpful, but most of the time the code should have the clarity to stand without them. I won't claim that they're not useful for some things, but yeah. When you get something silly like /* add 5 to a */ a += 6; that's just life
<sham1>
Life with commentary
<zid>
more often than not it's like, /* Furble the janket */ furble(janket); though
<heat>
but /* add 6 to a */ a+=6; is just a bad comment
<zid>
which seems like less of a bad comment
<zid>
but is still basically just /* x++ */ x++
troseman has joined #osdev
troseman has quit [Client Quit]
<gog>
furble the janket
<geist>
more like // jankets need to be furbled to ensure ...
<bslsk05>
github.com: wiredtiger/session_dhandle.c at develop · wiredtiger/wiredtiger · GitHub
<geist>
also sometimes comments are useful for someone in the future that might want to refactor things
<geist>
so something like
<geist>
// this is done before X below beacuse ...
<heat>
i think im going to write an ebpf interpreter
<heat>
and then jit it
<mrvn>
sham1: I've done this for ocaml C code: a += 6; // add 3 to a
<mrvn>
sham1: I've done this for ocaml C code: a += 6; // add 3 to a, it's already tagged
<heat>
the only bit im scared of in ebpf is that I may need fancier verification
<heat>
cuz its a good bit more powerful
<mrvn>
sham1: ocaml integers are shifted by 1 and have a 1 tag added. So adding a constant to a value isn't that obvious.
<gog>
what's ebpf again
<gog>
oh right
<gog>
berkely packet
<dh`>
hmm I guess the conversation couldn't stand an injection of reality
<zid>
ebpf gets used for other thingsI found out
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<heat>
bpf or cbpf are mostly for packet filtering and seccomp
<heat>
ebpf does fucking everything because ofc
<mjg>
burp
<theWeaver>
blorp
<heat>
mjg, is that a rick and morty reference
<heat>
are you transforming yourself into a pickle
<mjg>
no
<mjg>
i'm too old to watch that
<theWeaver>
pickle mjg :o
<mjg>
i am however relieving high school years
<heat>
pickle rick and pessimal mjg
* theWeaver
pickles heat
<heat>
sounds dirty
<mjg>
i ran into seriously weird videos on youtube
<mjg>
to the point where i wont tell you what it is
<gog>
i have stress dreams that i'm in high school
<zid>
Time to watch a man solve a puzzle while I fall asleep
<gog>
and i'm always late for class
<moon-child>
mjg: well that's no fun
<gog>
there was even one dream i had where i was like "wtf am i even doing here i went to university"
<mjg>
gog: i recnetly had a dream i was at my old job
<geist>
gog: yep i get those still
<mjg>
gog: and my boss was giving me shit for not staying past 7 pm
<gog>
ooof
<geist>
usually in the form of 'oh shit i forgot i signed up for a class and now it's finals'
<mjg>
really
<geist>
or, job related ones i get a stress dream, i think not 2 nights ago, that i somehow accidentally accepted two jobs at the same time, and am trying to juggle one while the other one doesn't know
<mjg>
i had one dream i was in college, twards the end of the semester, and i realized i studied nothing
<mjg>
:s
<mjg>
geist: lol
<heat>
typical tech worker during the pandemic
<geist>
basically
<mjg>
tech asshole!!
<geist>
another college stress dream i get sometimes is 'i need to go back to school because i missed a class'
<geist>
and then it's like 'how the fuck am i gonna do that?'
<heat>
sometimes i have dreams that im in college, then wake up, and im still in college
<theWeaver>
gog: my stress dreams are usually that i'm back in the UK for some reason (visiting family, whatever) and have no plane ticket back to Germany, have work next week, and no money to buy a flight