sortiecat has quit [Read error: Connection reset by peer]
Burgundy has quit [Ping timeout: 260 seconds]
[itchyjunk] has joined #osdev
vdamewood has joined #osdev
vinleod has joined #osdev
smach has quit []
vdamewood has quit [Ping timeout: 248 seconds]
vinleod is now known as vdamewood
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
isaacwoods has quit [Quit: WeeChat 3.7.1]
heat_ has joined #osdev
heat has quit [Ping timeout: 248 seconds]
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #osdev
FreeFull has quit []
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
smach has joined #osdev
smach is now known as sav10
[itchyjunk] has quit [Remote host closed the connection]
sav10 has quit []
smeso has quit [Quit: smeso]
smeso has joined #osdev
jafarlihi has joined #osdev
<jafarlihi>
Does booting with UEFI means you'll always be dropped into VESA mode or can it be made to boot your kernel into VGA mode?
<geist>
VGA text mode? AFAIK o
<geist>
no
<geist>
i dont think there's a way to instruct UEFI to mode switch back to vga
<jafarlihi>
So I need to create font rendering engine to print anything to screen?
smach has joined #osdev
smach has quit [Read error: Connection reset by peer]
<geist>
if in pixel based framebuffer mode yes
<geist>
it's not that hard, just take some bitmap font and write the routines to draw pixels
<geist>
wont be incredibly fast but it'll get what you want
<klange>
UEFI has no concept of text modes, despite the console presented to EFI applications emulating similar functionality. What you end up in when an EFI application starts is not defined, you need to query for video mode information.
<jafarlihi>
GOP is boot time service, does this mean you can't change resolution modes after exiting boot services?
<klange>
Not with GOP, no. You'll need an actual video driver for the hardware to change resolutions later.
<jafarlihi>
Ok, thanks
<klange>
(Changing resolutions at runtime is overrated. It was useful when we all had CRTs and games wanted to run full screen and couldn't be guaranteed to work at whatever resolution you were using. With LCDs, it's pointless - there is exactly one resolution your display should be running at, and if you want to support changing resolutions for an external display that may be hotswapped, you're gonna need drivers
<klange>
to do anything like that anyway)
<geist>
+1
<jafarlihi>
Are those first things you see printed when Linux starts actually GOP mode before it switches to drivers?
<geist>
probably so, yes
<klange>
(the one exception to this is VMs, some of which have functionality to set the display size to match the window size, but those are really easy to write drivers for - and are a good introduction to implementing a generic interface for it, should you ever support it for real hardware)
<jafarlihi>
But it looks the same with legacy BIOS boot too
<geist>
it's fairly easy to draw on a framebuffer something that looks basically identical to VGA text
<geist>
since really VGA text mode is basically just the GPU put in a default mode that's blitting stuff to its own framebuffer
<klange>
I used to use a blocky VGA-esque one, but my baked bitmap font now is Deja Vu to match my TrueType userspace.
<kazinsal>
yeah, the firmware is just emulating a chargen etc
<moon-child>
also, if I add a barrier on either x or y, it's fine
gog has joined #osdev
kof123 has quit [Ping timeout: 268 seconds]
<moon-child>
it's also fine if I fix the bug in the code
<mjg>
burp
<mjg>
so i finally got around to benching fast short rep mov
<mjg>
i don't have full results yet, but it is still slower than overlapping stores for bufs < 16 bytews
<mjg>
marked improvement from ~128 bytes with pure ERMS, but still slower enough to justify hand-rolled coding here
<mjg>
messing with ice lake Intel(R) Xeon(R) D-1736NT CPU @ 2.70GHz
<mjg>
also i have to stress "fast short rep mov" does not do fuck for rep stos, which remains pessimal as ever
<mjg>
so no memset improvement
<moon-child>
:\
<moon-child>
they'll get there some day!
<moon-child>
could be worth it for i$, still. Though what would also help is if compilers knew what registers actually get used, so they could spill less
<mjg>
i can rant about it later, but got serious real-world speed ups from NOT rolling with erms main
<mjg>
man
<moon-child>
.oO( mark leaf functions as __attribute__((ms_abi)) since that has more callee-saved registers? )
<moon-child>
kills function pointers. So you'd have to do a wrapper or a macro or sth
<mjg>
now that i mention them i can't find the results
<mjg>
but most notably bsd tar is notorious for super short copies, literally bytes
<mjg>
not suffering rep spin overhead was a dramatic win
<mjg>
for real, the sucker was not even i/o bound :S
<mjg>
anyhow, it seems everyone knows about rep problem, even linux... except they only partially patch it for copy_from/copy_to user
<mjg>
they *don't* do squat for mem* routines
<mjg>
which is bizzare
<moon-child>
about short copies: I wanna pgo or something for that, or even dynamic inline caching
<moon-child>
why call memcpy when you could call memcpy_small, memcpy_medium, memcpy_large... hint
<mjg>
you do realize that in the kernel the typically memcpy_small-suitable variant will also have to handle the corner case of not-so-small
<mjg>
as in something mostly copies, say, 8 bytes
<mjg>
but technically it has to support up to 1KB
<mjg>
so you have to branch on it anyway
<mjg>
talking about copies not known at compilation time, thus resulting in a call to begin with
<mjg>
sizes*
<mjg>
and there goes your I$, does not? "]
<mjg>
if you add a bunch of variants
<moon-child>
maybe. But maybe if you have a size hint, you can afford a smaller, less precise decision tree per variant
<moon-child>
and can still share some code
<mjg>
i concede technically you may find yourself in a position where this can optimize better for the particular codepath
<moon-child>
also memcpy_8byte -> zap half of your tree :P
<mjg>
but i highly doubt it is worth the complexity and again it bloats I$ impact
<mjg>
if one is to be concerned about enough to even suggest straight erms
<mjg>
found postgres
<mjg>
Before:
<mjg>
progress: 10.0 s, 53180.1 tps, lat 0.019 ms stddev 0.000
<mjg>
progress: 11.0 s, 52928.2 tps, lat 0.019 ms stddev 0.000
<mjg>
progress: 12.0 s, 52878.8 tps, lat 0.019 ms stddev 0.000
<mjg>
after:
<mjg>
progress: 11.0 s, 55913.0 tps, lat 0.018 ms stddev 0.000
<mjg>
progress: 10.0 s, 55943.1 tps, lat 0.018 ms stddev 0.000
<mjg>
progress: 12.0 s, 55713.9 tps, lat 0.018 ms stddev 0.000
<mjg>
that's from replacing rep movsq; rep movsb combo with overlapping stores
<mjg>
same for memset
<mjg>
i don't remembet what sizes postgres is pushing there
<mjg>
but 4% is quite a diff if you ask me
<mjg>
wut. i can confirm that fsrm *also* handles misalignment pretty well
<mjg>
of the target buffer anyway
Burgundy has joined #osdev
<mjg>
will have to check amd uarchs with the bit as well
<kazinsal>
I did some testing on early ERMS implementations when I was working on my previous project and they almost universally sucked compared to just doing unrolled SSE copies etc
<kazinsal>
eventually when I get back into it and start reimplementing my previous project from scratch with a better design and testing on more modern architectures I'm looking forward to seeing what kind of differences there are on theoretical vs. practical memory bandwidth constraints
<mjg>
right, forgot to mention: this is all for kernel
<mjg>
so no simd :]
<mjg>
i do note glibc is using erms instead of simd past 2KB or so, but it might be it only happens on some uarchs
<moon-child>
wait, fixing the _kernel_ helped postgres 4%?
<mjg>
no
<mjg>
but i see why the above would be confusing without extra context
<moon-child>
ok. But still--postgres userspace was spending >=4% of its time in memset?
<mjg>
both user and kernel had the same terrible routines, the new ones written for the kenrel were temporarily also slapped into userspace
<mjg>
and that change got the 4% bump
<mjg>
would be ven bigger if it was sse
<moon-child>
I note you still haven't stolen my simd routines :)
<mjg>
your routines suck bro
<mjg>
well i don't know if they do, but i do recall your benchmark is bogus
<mjg>
giving wildly different results for copies of literally the same code
<mjg>
i noted you can't just slap different routines into one binary and call it a day, code alignment will fuck you up
<moon-child>
yeah the benchmark sucks
<mjg>
the 16 bytes intel likes to recmomend is just a tradeoff, not the optimal way
<mjg>
routines which land 256 boundary get a free perf bump
<mjg>
at*
<mjg>
it may be bigger on some uarchs
<moon-child>
forget alignment, the problem with the benchmark was that it was just slamming the routine with the same sizes over and over again
<moon-child>
there's a thing with 4k, iirc
<mjg>
that alone is not necessraily a big deal
<moon-child>
but that may have been something else--branches with a target in the same 4k are faster
<mjg>
i mean i'm sure there are other problems as well
<mjg>
but the alignment thingy defo was standing out for me
<moon-child>
and a 32-byte thingy. (Dsb erratum?)
<mjg>
so compile set of binaries, each of which aligns the target routine in the same spot
<mjg>
but it destroys your test setup afair
GeDaMo has joined #osdev
epony has quit [Read error: Connection reset by peer]
<zid>
big floppy bsd dong
<zid>
oh heat isn't here, I shouldn't be calling his name
Burgundy has left #osdev [#osdev]
sortiecat has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
epony has joined #osdev
radens has quit [Quit: Connection closed for inactivity]
smach has quit []
fixoulab has joined #osdev
kof123 has joined #osdev
Reinhilde has quit [Quit: Bye Open Projects!]
ZipCPU has quit [Remote host closed the connection]
<mrvn>
Alignment makes more of a difference than -Os vs. -O2 vs. -O3. Which makes most benchmarks statistically meaningless.
<kaichiuchi>
hi
ZipCPU has joined #osdev
Ellenor has joined #osdev
<gog>
nmew
<Ermine>
gog: hi, may I pet you?
<kaichiuchi>
i’m so tired
Ellenor is now known as Reinhilde
<kaichiuchi>
libdivide is pretty cool
heat_ has joined #osdev
heat_ is now known as heat
<heat>
zid, why am I floppy bsd dong wtf
<heat>
BSD? really?
<kaichiuchi>
hey i like freebsd
<zid>
hey I called you a big one at least
<heat>
i also mildly enjoy freebsd
<zid>
case closed
<heat>
but if I'm a floppy dong I'm very much a floppy GNU dong
<heat>
>uname -a
<heat>
Linux PC-PEDRO-ARCH 6.0.10-arch2-1 #1 SMP PREEMPT_DYNAMIC Sat, 26 Nov 2022 16:51:18 +0000 x86_64 GNU/Linux
<heat>
case CLOSED
<kaichiuchi>
i use ubuntu
<heat>
CRINGE
<heat>
FUCKING CRINGE OMG
<kaichiuchi>
one day pacman -Syyu killed my entire system so i decided that was enough of that
<heat>
the in L in lubuntu is the L you take for using it
<heat>
you're not supposed to use Syyu though
<heat>
rather Syu
<kaichiuchi>
why?
<heat>
Syyu force syncs from the repos and re-downloads every package database forcefully
<heat>
Syu just does a normal update
<kaichiuchi>
one thing I’ll say is I miss KDE
<kaichiuchi>
i really do
<heat>
you should try arch again
<kaichiuchi>
no stop it :(
<heat>
i've never had "oops my system went bye bye" issues
<heat>
and I am on KDE right now
<heat>
GNOME? I can also have that
<kaichiuchi>
i like having the latest everything, can’t deny that
<heat>
can't wait for then linux 6.1 hits the repos
<heat>
when*
<kaichiuchi>
you’re the devil on my shoulder
<heat>
i'll be swimming in multi gen LRU and you suckers will be stuck in shitty LRU from the 90s
<heat>
might as well use a BSD if you're down to use shitty code from the 90s
<kaichiuchi>
there was a kernel regression i did have though
<demindiro>
To be fair, ext2 does not have transparent compression
<j`ey>
heat: and for ext4 in edk2
<demindiro>
And making that work in a performant way turns out to be a gigantic pain in the ass
<heat>
my whole fs/ is 11475 LoC
<heat>
which includes a whole vfs, tmpfs, ext2, block IO, page cache
<heat>
j`ey, 6962
<heat>
the edk2 coding style does pad things nicely
<j`ey>
heat: why does tmpfs_readpage memset to 0?
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<heat_>
fuck
heat_ is now known as heat
<heat>
<heat> j`ey, because vmo_inode_commit (kernel/kernel/fs/vfs.cpp:87) does "struct page *page = alloc_page(PAGE_ALLOC_NO_ZERO);"
<heat>
I assume that zeroing up front doesn't matter as filesystems will do IO on it anyway, so vmo_inode_commit only zeroes the tail of the page, if read != PAGE_SIZE
<j`ey>
im confused what readpage is meant to do then!
<heat>
I could just as easily return 0 in tmpfs_readpage and let vmo_inode_commit zero it all I guess
<heat>
readpage fills a page with data
<heat>
it's the classic linux design
<heat>
readpage and writepage
<zid>
readtopage
epony has quit [Quit: QUIT]
<zid>
stupid english not having a difference between a brush for teeth, and a brush made of teeth
<heat>
this was a staple of the linux 2.4 pagecache (and for many years after 2.6): readpage fills a given page with that (from the filesystem), writepage writes a page back (to the fs), prepare_write prepares a write (implemented by the fs, does block allocation, etc, whatever is needed)
<heat>
then you had ->readpages and ->writepages to read and write multiple pages at once
<heat>
this was heavily favoured by the page cache
<heat>
->readpages got removed this year for ->readahead
<heat>
which sounds like it only does readahead, but it does both normal reads and readahead
<heat>
there's also a read_folio rn but I don't know what that does
<j`ey>
heat: so then why is it just 0 for tmpfs?
<heat>
it = what?
<j`ey>
why does tmpfs set it to 0, if its meant to read data?
<heat>
because it's tmpfs
* kof123
gives zid some eye scream
<heat>
what else could be the data source?
<heat>
tmpfs is, in Onyx and linux, just a dummy page cache and dcache backend, the page cache and dcache do most of the work
<j`ey>
I assumed it'd.. get whatever the data was
<heat>
yes but that's already in the page cache
<heat>
->readpage and co. are only called if you don't have the contents in the page cache
<j`ey>
aha that's what I was mising then
<heat>
the linux page cache design doesn't usually enter the filesystem specific code for reads
<heat>
frequently filesystems use mm/filemap.c and fs/mpage.c utility functions
amine has joined #osdev
<heat>
all they give those utility functions is a get_blocks_t that can map offsets to filesystem blocks, and mpage does the rest
<heat>
tmpfs and ramfs are so simple they don't even need this
<heat>
s/filesystem blocks/physical blocks/g
Burgundy has joined #osdev
<heat>
it was probably my fault at the beginning, should have better explained what the design is
<heat>
this shiz is hairy yo!
<j`ey>
something I've never looked at either
<heat>
reading is basically done straight from the page cache, which is a radix tree (what they now in linux call xarray) of pages. if the entry is not there you either need to read it in or it's an OOB read (shouldve been catched earlier)
<heat>
the radix tree data structure's layout looking very similar to a page table
<j`ey>
makes sense then, that the tmpfs_readpage is 0s
<heat>
yeah, you would only need to call it atm if you ftruncate or something and read some bit of the file in
Burgundy has quit [Remote host closed the connection]
<heat>
which will be all 0s unless it has been written to, in that case, it's in the page cache
<heat>
I'm not 100% sure how linux does tmpfs swap though, although I know they do it
Burgundy has joined #osdev
<zid>
heat this cooperatative day13 list is never going to work right if you don't help
<zid>
my ] get trailing 0 and idk why
<zid>
actually if I guard the number add better I get nothing at all, neat
<zid>
some issues with empty set and making sure stuff always gets added to the parent and stuff
epony has joined #osdev
<zid>
okay looks like it fixes the parse at least, but it breaks dump_set
<zid>
it doesn't like empty set
<kaichiuchi>
i swear you two are brothers
xenos1984 has quit [Ping timeout: 256 seconds]
<zid>
Okay it seems to parse correctly at least, heat can do the comparison part
Burgundy has quit [Ping timeout: 260 seconds]
gog has quit [Read error: Connection reset by peer]
gog has joined #osdev
epony has quit [Ping timeout: 268 seconds]
<kaichiuchi>
geist: hey you were right about the IAR -> clang transition revealing headaches
xenos1984 has joined #osdev
epony has joined #osdev
corank has joined #osdev
seds_ has joined #osdev
corank_ has quit [Ping timeout: 252 seconds]
auronandace has joined #osdev
nohit_ has joined #osdev
stux has quit [Ping timeout: 252 seconds]
nohit has quit [Ping timeout: 252 seconds]
seds has quit [Ping timeout: 252 seconds]
GreaseMonkey has quit [Ping timeout: 252 seconds]
Starfoxxes has quit [Ping timeout: 252 seconds]
ThinkT510 has quit [Ping timeout: 252 seconds]
jjuran has quit [Ping timeout: 252 seconds]
mjg has quit [Ping timeout: 252 seconds]
seds_ is now known as seds
nohit_ is now known as nohit
jjuran has joined #osdev
<demindiro>
At last, I have beaten the fuzzer
<demindiro>
Now my computer is an expensive space heater
Starfoxxes has joined #osdev
auronandace is now known as ThinkT510
bauen1 has quit [Ping timeout: 246 seconds]
xenos1984 has quit [Ping timeout: 248 seconds]
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
ptrc has quit [Remote host closed the connection]
ptrc has joined #osdev
<zid>
Fuck, it compiles and runs and does reasonable things but gives the wrong answer
<heat>
run the example input sweetie
<zid>
It passed hours ago
<zid>
It covers like 2 of the 16 cases
<heat>
then stop writing code and become like a doctor or so
<heat>
be productive to human-kind
<mrvn>
.oO(watching cat videos on youtube)
MrBonkers has quit [Remote host closed the connection]
MrPortmaster has joined #osdev
vdamewood has quit [Quit: Life beckons]
mahk has quit [Ping timeout: 256 seconds]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
<heat>
turns out I've got a big reference leak somewhere in my tcp stack
<heat>
yay
<ThinkT510>
let the debugging begin
<heat>
this has shades of sortie all over
<heat>
:D
<heat>
tcp leaks? deja vu
mahk has joined #osdev
greaser|q has joined #osdev
greaser|q is now known as GreaseMonkey
<heat>
found it lmao
<heat>
wasn't unrefing in the rx path
<heat>
this is what I famously call a "performance optimization"
<mrvn>
that's why you should have RAII (in the tcp stack)
<heat>
I do have RAII, I just didn't have RAII there
<heat>
so I used my ref_guard<T> and now it's fixed
<mrvn>
I do have seat belts, I just don't use them, :)
<mrvn>
actually how do you leak in the tcp stack? isn't it zero-copy?
<mrvn>
non-allocating
<mrvn>
or did you leak the whole buffer?
<heat>
tcp stacks are definitely not zero-copy in the normal paths
<heat>
no, I was just leaking references to the socket
ThinkT510 has quit [Quit: WeeChat 3.7.1]
<mrvn>
Since I allocate pages for everything my plan is to have the 1500 bytes frame in the page leaving 2596 bytes for other stuff.
<geist>
okay.
<heat>
oh hey geist
<geist>
hi!
<heat>
sup
<geist>
oh not much computer wise. moved my home server to a rackmount case last night
<geist>
finished god of war
<geist>
been dinking with rust
<geist>
trying to tie things up at work before the end of the year
ThinkT510 has joined #osdev
<heat>
what things?
<heat>
rust?
scoobydoo has joined #osdev
<geist>
oh no just bugs, projects, CLs in progress, etc
<geist>
like trying to tie up this PCID change i've been working on for a while
<geist>
had it nearly done before thanksgiving but lost a bunch of momentum there
<geist>
talked to someone yesterday at work about adding dynamic loading to LK, might piddle with that
<geist>
one of those things that isn't super hard, and maybe kinda fun, but just never really needed it, but they had a good use case
<heat>
modules are a bit painful
<heat>
the weird linker relocs are ahhhhhhhhhhhhhhhh
<heat>
particularly in the RISC architectures it seems
<heat>
one thing that I also never got is a good way to make gdb aware of my modules
<geist>
i was thinking of just doing the usual 'link the kerne as a shared lib and resolve the loadable modules against it' sort of thing
<heat>
so I turn them off and just build everything statically, it's not worth it to have undebuggable bits of the kernel in the name of m o d u l a r i t y
<heat>
but building the kernel as a so is inefficient
<geist>
sure. definitely
<geist>
but for the use case they have its fine
<geist>
but i am curious what the linker relocs problems you found
<geist>
was it just some annoying RELs or something trickier?
<heat>
not problems in particular, they're just odd to deal with
<heat>
doesn't arm64 have a shit ton?
<kaichiuchi>
there’s something… freeing about using C after spending so much time with C++
<geist>
yup. an interesting question is how many are used
<geist>
kaichiuchi: indeed, for better or worse
<kaichiuchi>
(this is not meant to start a war) but man oh man
<kaichiuchi>
it’s like taking a shower and you’re dancing and bouncing and happy to be alive
<kaichiuchi>
until there are some actually useful things from C++ that you wish you had in C
<kaichiuchi>
compile time function evaluation, templates come to mind
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<kaichiuchi>
user defined literals so I can say 32_KB and it’s readily obvious
<heat>
use K&R C
<heat>
what are headers?
<kaichiuchi>
no
<heat>
extern printf; auto val = 0; printf("Hello %d", val);
<heat>
it's freeing
<kazinsal>
I once saw someone describe C++ as "a language made of byzantine footguns" and I've never managed to not think of that phrase whenever someone mentions C++
<kaichiuchi>
I would probably write C++ very C-like ish but then people would yell at me
<geist>
yah lightweight C++ is kinda the sweet spot lately. C with some additional C++ features to help you out where you need it
<heat>
I do that
<kazinsal>
yep
<kazinsal>
the correct way to C++
<kazinsal>
C With Function Overloading (tm)
<heat>
noooooo
<heat>
function overloading is kinda bad
<geist>
yeah that's one of the eeeeh parts of it
<heat>
I use light templates, classes, structs
<geist>
but things like stronger types and lightweight RAII, etc is nice
<heat>
mostly RAII stuff
<geist>
yah nicer templatey stuff like min() max(), etc
<acidx>
constexpr is nice too
<geist>
yah
<geist>
const globals vs #defines, etc
<heat>
booooooo
<geist>
though that one only helps if you go full C++
<heat>
you're starting to lose me geist
<geist>
since tey dont mix right
<acidx>
enum:base_type is also cool (however it's called)
<geist>
oh typed enums is nice
<geist>
lots of C++11 stuff basically really helps the language with basic stuff
<acidx>
C23 is getting it though :D
<heat>
hard disagree on that one as well
<kaichiuchi>
lambdas are nice WHEN YOU CAN USE STD::FUNCTION
<kaichiuchi>
GOD
<heat>
no
<heat>
std::function is shit
<geist>
heh
<kaichiuchi>
that still pisses me off
<geist>
yeah i do not like std::function in any low level stuff
<kaichiuchi>
yes i know
<mrvn>
kaichiuchi: or when you don't cpature
<mrvn>
a lambda without capture is compatible to a function pointer
<kaichiuchi>
right
<heat>
lambdas are very easily handleable by just passing them around and changing around your code patterns
<kaichiuchi>
but anything else is just annoying
<mrvn>
or you can use "template <fn_t>"
<kaichiuchi>
i don’t want to maintain a void* userdata god dammit
<heat>
template <typename Callable> void for_every(Callable c) { for (auto &elem : list) c(elem);}
<heat>
just works
<geist>
right
<kaichiuchi>
i swear that’s never worked for me…
<mrvn>
when do you actually need std::function?
<heat>
I use that all around my kernel
<kaichiuchi>
mrvn: if i want to do [this]() { printf(“hi”); }; or something
<kaichiuchi>
can’t
<heat>
std::function is useful if you want to pass around funcptrs, but how many times have you needed that?
<kaichiuchi>
never
<acidx>
I needed std::function when writng a Go-to-C++ compiler a while back. used it for deferred statements.
<mrvn>
heat: but that's just a 'template <typename Callable>'
<heat>
what is?
<mrvn>
when you want to pass around a funcptr
<heat>
it's not
<mrvn>
or lambda
<heat>
it's not type erased
<mrvn>
ahh, yes, good point.
<kaichiuchi>
I think what really gets to me is the language doesn’t have “built in” constants defined by the compiler, as in I have to include <stdint.h> or something; why can’t the compiler just.. expose something for me like that
<mrvn>
kaichiuchi: import stl
<kaichiuchi>
but I can’t
<heat>
that's like a very tiny pain point
<kaichiuchi>
no it isn’t
<heat>
dude
<heat>
#include <stdint.h>
<heat>
fixed
<kaichiuchi>
not when you’re caring about something that doesn’t have a stdint.h
<mrvn>
I recently learned that importing all of STL is faster than even some basic includes
<kaichiuchi>
isn’t your kernel C++?
<heat>
whose?
<kaichiuchi>
do you just have a simple stdint
xenos1984 has quit [Read error: Connection reset by peer]
<kaichiuchi>
yours
<heat>
I have a full fledged stdint, stddef, etc
<heat>
(actually stole them from musl)
<mrvn>
kaichiuchi: c++ would better use "#include <cstdint>"
<kaichiuchi>
sure
<heat>
C++ stl is also very hostile with no fpu code btw
<heat>
which means my nice includes of <type_traits> have a whole bundle of hacks behind them
<bslsk05>
github.com: Onyx/Makefile at master · heatd/Onyx · GitHub
<heat>
this + C includes are set up in a very particular way
<heat>
it's very brittle
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<kaichiuchi>
heat: that worked for me
<kaichiuchi>
i hate you and i love you
<heat>
why
<kaichiuchi>
because i didn’t think that would work and i can capture
mjg has joined #osdev
TkTech has joined #osdev
<zid>
heat: I found a test case at least, but I can't get it to work, I'm about to lose advent
xenos1984 has joined #osdev
knusbaum has quit [Ping timeout: 260 seconds]
demindiro has quit [Ping timeout: 260 seconds]
<zid>
k I retire from programming, I'm just a bum now
knusbaum has joined #osdev
* kof123
gives zid carrier pigeons so he can be tonberry bowery king
smach has quit []
terminalpusher has joined #osdev
<heat>
kaichiuchi, what would?
<heat>
you're giving me like 0 context
<heat>
geist, do you reckon fbl is portable enough that I can take pieces of it for my kernel?
<geist>
i actually already did take an earlier version of fbl into LK, it's in a branch
<heat>
yeah I know
<geist>
basically the last version just before it started to reky on std::
<heat>
I'm just wondering if it was a big struggle or nah
<geist>
well that version wasn't. newer ones are more built around std:: so it depend son how much you wanna get your hands dirty
<geist>
ie, type_traits, etc
<heat>
i have that already through hacks and depression
<geist>
so yeah probably no biggie
<geist>
at least picking up some of the container stuff should be fine
<geist>
the intrusive lists and the WAVL tree have gotten a lot of mileage now
<heat>
i'm using your C wavl tree
<heat>
from trusty
<geist>
oh yeah i still have a todo to properly get that into LK
<geist>
not my wavl tree, to be fair, it's the trusty folks
<heat>
yeah
<heat>
the real problem with all these intrusive data structures is that they don't work with RAII
Burgundy has joined #osdev
<heat>
which is my only need for fbl really
<geist>
ah. how not?
<heat>
might not be a real big problem to make this work for RAII
<heat>
well, if you consider the classic struct list_head {struct list_head *prev, *next;};
<heat>
you'll notice it can't RAII for shit
<geist>
i'm missing the connection
<heat>
since you get the pointer through container_of, you can't have something like a unique_ptr in a list
<geist>
ah ah okay. i wasnt' thinking of the container_of thing as being RAII, but i guess it is
<heat>
if you use these as-is, you get manual with all the resource management as soon as you insert
<geist>
yeah that's a big issue. the LK list is causing problems as i get more C++ in LK, for example
smach has joined #osdev
<geist>
since you technically can't container_of anything complicated in C++, but i have to squelch the warning, etc
<heat>
in any case I think I've got a solution
<heat>
my solution to that warning is that I have a struct list_head_cpp<T> : struct list_head {T *this_ptr;};
<heat>
so instead of doing container_of I just interpret the list_head as a list_head_cpp and get the this_ptr, which points directly to the object
<heat>
if I want raii, I could just replace the T* with the RAII wrapper
* geist
nods
<heat>
I think
<geist>
note the fbl::wavl tree is huge, FWIW. a todo item we've never gotten around to doing is selectively un-inlining the core bits
<geist>
so it basically fully inlines a complete wavl tree because of templates
<heat>
yuck
<geist>
has a tendency to blow up all the core around it
<geist>
and our compilers at least aren't smart enough (yet) to out-line that sort of shared code like that
sprocket is now known as sprock
<heat>
ain't that the C++ we all know and love/hate
<geist>
so even if it emits templated routines for particular Ts it doesn't know to combine em
dutch has quit [Quit: WeeChat 3.7.1]
<geist>
but probably can't anyway due to things like calling destructors and whatnot for specific Ts
<geist>
so would need to go in there and selectively move the engine of the tree into non inlied code and feed it things like the pointer offset/etc
<geist>
a bit of efficiency for space
<heat>
wait, how does your wavl tree depend on T?
spikeheron has joined #osdev
<heat>
is that like a specific goal (type-safety) or?
<geist>
just that its intrusive as well
<geist>
so the node pointers are off in some offset into the object
smach has quit [Ping timeout: 272 seconds]
<geist>
so that basically is the main variable, the offset_of
<geist>
and also type safety, etc
<heat>
right, but if you separate the data structure bits with the T *ptr; bits, it can be T-neutral
<geist>
of course. i'm saying we never have done that
<heat>
s/with the/from the/
<heat>
something I actually really like in the trusty lk wavl is that you can just pass your own compare function
<geist>
it operates just like the single and doubly linked lists in the fbl stuff. it's a trait based thing where either get one for free or you have to declare specific traits for more than one
<heat>
no T operator<=> bullshit
<geist>
yah and i'm sure you can do the same thing in the wavl tree. it's complicated (for my eyes at least) and there are lots of templaty things you can override
<heat>
that does seem a bit unfun
<heat>
templaty things you can override
<geist>
indeed. i find in general 'library class' C++ stuff to be totally unfun, though i can see why folks like the mental challenge
<geist>
that's top shelf C++ hackery, basically
<geist>
anyway, gotta meeting in a min
<heat>
i have enjoyed coding some bits, and making everything fit nicely
<heat>
and making things use expected<T, E>
<geist>
oh yeah totally. i can completely see why people like doing that, it would satisfy a few axis of enjoyment
<heat>
the interesting bit here is that since most of my C++ isn't very C++-y neither are my library class C++ stuff
<heat>
I have also noticed it depends on my mood
<heat>
i have some files on which I was like "fuck it, lets write C" and it looks very much like C
smach has joined #osdev
fixoulab has quit [Quit: Leaving]
<heat>
sometimes going all out with pretty design patterns is indeed not useful
<heat>
nothing beats functions going brrrr
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<mrvn>
I like it when sorted containers have a spaceship callback but default to <=> (or compare and <)
spikeheron has quit [Quit: WeeChat 3.7]
heat has quit [Remote host closed the connection]
heat has joined #osdev
sweetleaf has joined #osdev
fwg has quit [Quit: .oO( zzZzZzz ...]
fwg has joined #osdev
k8yun has quit [Quit: Leaving]
smach is now known as sav10
terminalpusher has quit [Remote host closed the connection]
sav10 is now known as sav10sena
sav10sena has quit []
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
Matt|home has quit [Quit: Leaving]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]