channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=3&d=10
00:26:00 <brunothedev> why dont i use "multiboot_tag_vbe" ?
00:47:00 <klange> That tag is for locating the VESA BIOS extensions, with which you could theroetically perform modesetting operations, except VBE 2 only has a BIOS interface to do that, and VBE 3 doesn't actually exist.
00:48:00 <klange> Sorry, misspoke. VBE 2 has a protected mode interface nothing implements, and VBE 3 data is not provided by GRUB through that interface (and doesn't really exist anyway)
00:54:00 <klange> If you were thinking of using the mode information to understand your framebuffer, note that this information is only provided if VBE was used to perform modesetting by GRUB which may not necessarily be the case. GRUB actually has a handful of other modesetting drivers, or may be running through EFI and using GOP rather than VBE.
01:35:00 <heat> again, what a great nap
01:35:00 <heat> this is neat
01:36:00 <zid> heat what do I do now I am an amd fanboi
01:38:00 <heat> OH
01:38:00 <heat> I have a benchmark for you to run zid
01:38:00 <zid> kk
01:39:00 <heat> 1) install google benchmark (probably just "benchmark on your gentoo thingy)
01:39:00 <zid> I've not got vmware installed yet
01:39:00 <zid> but now I can do vmware 17!
01:40:00 <heat> ok do that then
01:40:00 <heat> i wanna test how rep movsb works in your new shiny thing
01:40:00 <heat> 5800x right?
01:40:00 <zid> *exctracts some zips to rar parts* *extracts some rars*
01:43:00 <heat> zid, https://dubz.co/video/cbe927
01:43:00 <bslsk05> dubz.co: Dubz
01:43:00 <heat> me and the lads 'avin some fun down at the footie
01:45:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/1083566200480612372/image.png :(
01:46:00 <heat> turn it on
01:46:00 <zid> I have to reboot just for heat smh
01:50:00 <bnchs> hi
01:50:00 <bnchs> i misread amd fanboi as amd femboi
01:58:00 <zid> Gigabyte is dumb, option is called "SVM" no wonder I missed it the first time.
02:00:00 <heat> yeah cuz svm is the real name
02:00:00 <heat> amd-v is marketing bs
02:00:00 <zid> It should be called intel vt-d emulation
02:03:00 <zid> makes me reboot then just quits on me smh
02:03:00 <heat> 8gb of ram moment
02:03:00 <zid> That's a good point, how many cpus did I boot this with, 12 I assume
02:04:00 <heat> btw no, svm is different from intel vmx afaik
02:04:00 <zid> instead of 16
02:04:00 <heat> why?
02:04:00 <zid> cus that's what it was set to before
02:04:00 <zid> 1650 was 12
02:08:00 <heat> ok i have the stuff
02:08:00 <zid> when do I get ~the stuff~
02:09:00 <heat> https://gist.github.com/heatd/28714dccadfff5469a3647f364a93ce6
02:09:00 <bslsk05> gist.github.com: bench.cpp · GitHub
02:09:00 <heat> download both of those files and do "g++ memcpy_ours.S bench.cpp -lbenchmark -O2"
02:09:00 <heat> then run it
02:09:00 <zid> how do I get this into vm with a name like that
02:09:00 <heat> fuck
02:09:00 <heat> don't you have the shared clipboard thing
02:10:00 <zid> oh yea I should do now
02:11:00 <zid> doesn't work
02:11:00 <zid> keyboard encoding issues and it stops half way through, sick
02:12:00 <zid> Time to set a share back up maybe
02:12:00 <heat> https://tinyurl.com/mrxwxux4
02:12:00 <bslsk05> redirect -> gist.github.com: bench.cpp · GitHub
02:13:00 <heat> i dont know if this shortener is any good
02:13:00 <heat> rip goo.gl
02:14:00 <zid> k I have them
02:17:00 <heat> u run it or wat
02:17:00 <zid> yea I was trying to remember github password
02:17:00 <zid> https://gist.github.com/zid/4d8d9cc8673f9d1a3ba1652fd4fc19b9
02:17:00 <bslsk05> gist.github.com: out.txt · GitHub
02:18:00 <zid> did I win
02:19:00 <heat> 5800x right?
02:19:00 <zid> yea but with a couple cores missing
02:19:00 <zid> 1800MHz ram
02:19:00 <zid> aida gives it ~50GB/s read speeds
02:20:00 <zid> (less than my 1650)
02:20:00 <moon-child> 1800mhz? Isn't everything at least 2666mhz for a long time now?
02:20:00 <zid> that's probably 1333Mhz
02:20:00 <heat> aha this is very funny
02:20:00 <zid> they love to pretend DDR means you can double the clock speed a couple of times eery time you chinese whisper it
02:21:00 <zid> any standout results heat?
02:21:00 <heat> 1) borislav was fucking lying and rep movsb still sucks on amd
02:21:00 <heat> 2) seems that rep movsb speed goes off the cliff after ~8K
02:22:00 <heat> I assume glibc avoids that by doing nt stores
02:22:00 <zid> BM_string_erms/1024 14.6 ns 14.6 ns 41961244 bytes_per_second=65.2261G/s
02:22:00 <zid> BM_string_erms/8192 1837 ns 1837 ns 380748 bytes_per_second=4.15265G/s
02:22:00 <zid> after 1k
02:22:00 <zid> I assume maybe after 4096
02:22:00 <moon-child> heat: you aren't aligning your movsb dst
02:23:00 <heat> zid, add ->Arg(4 * KB) \ to the AT_COMMON_SIZES thing
02:23:00 <zid> I'll wait until you argue with moon about whether your dest is aligned or not
02:23:00 <zid> and whether I need to change something
02:24:00 <heat> i am not aligning the movsb dst, its a fact
02:24:00 <heat> doesn't really matter here
02:24:00 <heat> everything is good and aligned anyway
02:24:00 <moon-child> pretty sure it does
02:24:00 <moon-child> should just replace new with aligned_alloc or w/e
02:25:00 <heat> malloc gives ya 16-byte aligned
02:25:00 <moon-child> but not 64-byte aligned
02:25:00 <heat> why do I want that?
02:26:00 <heat> zid, in any case do what I told ya, the results should be consistent with what I've measured here
02:26:00 <moon-child> because erms apparently wants it
02:26:00 <zid> I was right
02:26:00 <heat> wth
02:27:00 <heat> this is wiiiiiiiiiiiild
02:27:00 <zid> https://gist.github.com/zid/34bfbe000db79dbb4bc33db81152ae82
02:27:00 <bslsk05> gist.github.com: out2.txt · GitHub
02:28:00 <zid> 4k is fastest
02:29:00 <heat> this is fucking wild
02:29:00 <heat> your rep movsb is ASS
02:31:00 <heat> can you grep for erms and fsrm in /proc/cpuinfo?
02:32:00 <moon-child> oh btw I found that rep stosq could be decent at some sizes
02:32:00 <moon-child> on zen 2
02:35:00 <zid> just for fun: https://gist.github.com/zid/f9bfe0a39015a26fda627427aea8e1c7
02:35:00 <bslsk05> gist.github.com: out3.txt · GitHub
02:36:00 <zid> https://gist.github.com/zid/92f088b4451132105521f169b527452b
02:36:00 <bslsk05> gist.github.com: gist:92f088b4451132105521f169b527452b · GitHub
02:37:00 <zid> erms yes, frrmsr no
02:39:00 <heat> i'm wondering if any of this can be getting influenced by the vm
02:41:00 <zid> It's mainly influenced by amd's crappy memory controller and dual channel being shit
02:42:00 <zid> it's highter latency and lower bw
02:53:00 <heat> zid, https://tinyurl.com/567ajjry new bench.cpp
02:53:00 <bslsk05> redirect -> gist.github.com: newbench.cpp · GitHub
02:54:00 <heat> this time with aligned allocs
02:54:00 <geist> general observation: if you're benchmarking your routines you *really* want to also benchmarks unaligned bits
02:55:00 <geist> doubleplus so on memcpy. it's easy to build super fast ass routines that work great when everything is aligned and collapse to nothing otherwise
02:55:00 <heat> yeah
02:56:00 <heat> but I think that in this case you just want to do unaligned stores
02:56:00 <geist> what i have done for my test hardness is allocate a large buffer by some overshoot and then run with varying stc and dst offsets
02:56:00 <heat> per mjg
02:56:00 <geist> well, sure, but that's the point. if you're making a fast implementation you have to be able to deal with all of them
02:56:00 <heat> btw could you run this too geist? on your zen
02:57:00 <geist> what kinda zen are you interested in? i dont have a 4, only up through a 3
02:57:00 <heat> yeah 3 works, just want to make sure zid's vm isn't influencing the results
02:57:00 <geist> ah
02:58:00 <heat> not that it *should*
02:58:00 <geist> yah can't quite this minute but might in a little bit
02:59:00 <heat> i'm fairly sure the benching hot loop doesn't do rdtsc, etc. but it's really weird that speed just falls off a cliff in 4096 -> 8192
02:59:00 <heat> yeah thats fine
03:01:00 <heat> surely this cant be a cache thing, 32KiB L1 per core
03:02:00 <geist> i need benchmark.h
03:03:00 <geist> and probably whatever that came with
03:03:00 <heat> google benchmark
03:03:00 <heat> probably just sudo apt install benchmark? or similar, usually named "benchmark"
03:05:00 <geist> need implementation of our_memcpy
03:06:00 <heat> https://gist.github.com/heatd/28714dccadfff5469a3647f364a93ce6
03:08:00 <geist> https://www.irccloud.com/pastebin/fk3luVYg/
03:08:00 <bslsk05> IRCCloud pastebin | Raw link: https://irccloud.com/pastebin/raw/fk3luVYg
03:08:00 <geist> that is a 3950x, which is a zen 2
03:10:00 <heat> alright thanks
03:10:00 <ghostbuster> dumb question but what does it mean to say the stack is aligned, eg. on a 16-byte boundary. is it that ESP must be evenly divisible by 16? or EBP-ESP? or both?
03:10:00 <heat> yeah those results seem to match up
03:10:00 <heat> with, erm, logic
03:10:00 <Mutabah> ghostbuster: ESP must be evenly divisible
03:10:00 <ghostbuster> ty
03:10:00 <Mutabah> and EBP will most likely also be... if frame pointers are in use
03:11:00 <heat> no, ebp will most likely be misaligned
03:11:00 <heat> wait, actually
03:11:00 <heat> per x86_64 sysv, push %rbp should re-align the stack
03:11:00 <Mutabah> yep.
03:12:00 <heat> but ebp should still be misaligned i think
03:12:00 <geist> not so sure. or, it may be that there is no such requireent to ebp
03:12:00 <geist> but rsp being aligned is
03:12:00 <Mutabah> The prelude is usually `push %rbp; mov %rbp, %rsp`
09:55:00 <zid> heat's not gu nna believe what the new bench.cpp does lol
09:55:00 <zid> it now drops off a cliff still, but at 16k instead of 4k
12:38:00 <brunothedev> i think i am gonna make a virtual 8086 mode to write my vesa driver
12:38:00 <brunothedev> multiboot framebuffer is too much of a hastle
12:39:00 <gog> i guarantee you v86 mode is going to be more of a hassle
12:40:00 <brunothedev> gog: then pure real-mode
12:40:00 <gog> more hassle
12:40:00 <gog> and neither technique is forward-compatible
12:41:00 <brunothedev> ok, so can you reference me some os who uses multiboot_tag_framebuffer, the example code by grub is very weird, and dont draw actual things
12:42:00 <gog> i don't have a reference
12:42:00 <gog> personally i use EFI GOP to get the framebuffer properties
12:42:00 <gog> the principle is the same though
12:43:00 <brunothedev> gog: so, no simple os that uses multiboot_tag_framebuffer
12:43:00 <gog> idk maybe
12:43:00 <gog> https://github.com/adachristine/sophia/blob/main/kc/core/video.c
12:43:00 <bslsk05> github.com: sophia/video.c at main · adachristine/sophia · GitHub
12:43:00 <gog> this is the code that actually does the drawing
12:44:00 <gog> if you can get the framebuffer properties it's all the same after that
12:45:00 <brunothedev> gog: i already got the struct, which means i have most things
12:45:00 <gog> ok then you can use this code to see how to actually do the thing
12:46:00 <gog> it'll be exactly the same if you have 32bpp
12:46:00 <gog> idk about the order of the fields tho
12:46:00 <gog> i don't support any other mode than bgra32bpp rn because i don't have to
12:47:00 <brunothedev> according to the multiboot2 specification, the bpp dont change many things: https://github.com/cludblaze/multiboot2
12:47:00 <brunothedev> * https://github.com/cloudblaze/multiboot2
12:47:00 <bslsk05> cloudblaze/multiboot2 - multiboot2规范的示例代码 (0 forks/1 stargazers/GPL-3.0)
12:52:00 <gog> well, anyway, int10h v86 or real mode is going to be more difficult and slower than than a planar bitmap
12:58:00 <brunothedev> oh well, still, i am gonna try vesa, think i am gonna write assembly code who sets the thing in real mode and then provide as args on a c function
12:58:00 <gog> that's what grub is doing for you but ok
12:59:00 <brunothedev> i've also seen multiboot_tag_vbe too
12:59:00 <brunothedev> vbe has more docs, but there is no docs on ^
13:00:00 <gog> ok
13:00:00 <gog> i'm not gonna tell you not to do something but the framebuffer tag is way easier if all you want to do is draw some stuff on screen
13:01:00 <gog> the vbe tag is lower-level and i guarantee you're going to have a worse time with that than you will understanding what you're doing wrong with the framebuffer tag
13:22:00 <brunothedev> what is the best resolution for a 80x24 terminal?
13:22:00 <brunothedev> so that i can write a good "findmode" function
13:23:00 <gog> depends on the font size
13:23:00 <brunothedev> 8x8 asounds good
13:23:00 <gog> 80x24 iirc was the 640x400 CGA
13:24:00 <gog> that would be 8x12 for 640x400
13:24:00 <gog> 8x13 for 640x480
13:24:00 <gog> but these are legacy modes
13:24:00 <gog> my code just uses 8x13 font on whatever size it gets because i just used a font i found
13:41:00 <funno> checking for bison 3.0.4 or newer... 3.8.2, bad
13:41:00 <funno> configure: error: Building gprofng requires bison 3.0.4 or later.
13:41:00 <funno> Hello, I'm trying to build binutils on Ubuntu as described here https://wiki.osdev.org/Building_GCC but my bison version seems too new? I get this error ^
13:41:00 <bslsk05> wiki.osdev.org: Building GCC - OSDev Wiki
13:41:00 <gog> which version of binutils?
13:42:00 <funno> 2.40
13:42:00 <gog> https://www.mail-archive.com/bug-binutils@gnu.org/msg40891.html known bug
13:42:00 <bslsk05> www.mail-archive.com: [Bug gprofng/29148] New: bison version too new??
13:43:00 <funno> wow a year old
13:44:00 <funno> can i downgrade bison on ubuntu?
13:44:00 <funno> or should i build an older bison from source and put it in my path?.
14:09:00 <Ermine> gog: may I pet you
14:10:00 <gog> ye
14:10:00 * Ermine pets gog
14:12:00 * gog prr
14:12:00 <sham1> Hell
14:12:00 <sham1> Helo
14:13:00 <Ermine> ehlo
14:17:00 <nikolar> Aloha
14:20:00 <sham1> Do you mean "hello" or "goodbye"
14:20:00 <sham1> We need statically typed language
14:24:00 <gog> hellogoodbye
14:27:00 <mrvn> Who writes a "findmode" function anymore? It's not like TFTs have more than one resolution and CRTs are hopefully truely dead.
14:28:00 <gog> idk this kid doesn't really seem to understand that the thing they want to do is actually very easy
14:28:00 <gog> and that the things they think will be easiser are actually worse
14:29:00 <zid> hi gog
14:29:00 <gog> hi zid
14:29:00 <zid> when do we eat the moss?
14:29:00 <gog> we don't
14:30:00 <gog> the moss is protected by law
14:30:00 <zid> Come on, just a little bit
14:30:00 <gog> we eat fish
14:30:00 <zid> a part nobody will notice is missing
14:30:00 * gog chomp fishy
14:30:00 <sham1> I hope that fishy isn't fermented
14:30:00 <mrvn> don't we need the moss to grow shrooms?
14:32:00 <gog> haha that's right it's almost the time of year to go collect psilocybin
14:33:00 <zid> hello mr. heaterson
14:33:00 <heat> hello zed
14:34:00 <zid> I ran your new bench.cpp
14:34:00 <zid> You're not going to like it.
14:34:00 <heat> i've heard
14:34:00 <heat> send out.txt pls
14:34:00 <zid> how did you hear
14:34:00 <zid> are you log watching, that's gross af
14:35:00 <heat> yes
14:35:00 <zid> https://gist.github.com/zid/4e444b66dd9dea03081fed2283c9e5c7
14:35:00 <bslsk05> gist.github.com: gist:4e444b66dd9dea03081fed2283c9e5c7 · GitHub
14:35:00 <heat> ok
14:35:00 <heat> these results make more sense
14:35:00 <zid> why would 16k being the limit make more sense
14:36:00 <zid> than 4k
14:36:00 <heat> I guess amd rep movsb REALLY wants 64-aligned rep movsb
14:36:00 <heat> zid, because your L1 is 32KiB
14:36:00 <zid> oh is it
14:36:00 <zid> who knew
14:39:00 <zid> emerge -e @world, 587 packages remain
14:39:00 <zid> dawn of the first day
14:39:00 <gog> why
14:39:00 <zid> -march=native
14:40:00 <zid> is no longer native
14:40:00 <sham1> Why would the name lie like that
14:40:00 <zid> sham1: I'm now an amd fanboi so I need to expunge all this intel nonsense
14:41:00 <sham1> Well march=native is still your (now) superior chipset (AMD all the way). But okay yeah, I see why you'd have to recompile everything
14:42:00 <sham1> AMD ruuls, Intel druuls
14:42:00 <zid> Xeon was great, so was coal
14:42:00 <zid> time to move on
14:43:00 <heat> sheesh
14:43:00 <heat> never thought zid would ever say this
14:43:00 <zid> I'll say anything you want if you give me a couple of hunred of quid worth of processor to say it about
14:43:00 <heat> "zid: ooga booga xeon good tdp large"
14:45:00 <heat> mjg, amd cpus are wild with ERMS
14:45:00 <gog> ryzen ryzen ryzen
14:45:00 <heat> definitely deserves extra care
14:45:00 <gog> zid is ryzen gang with me now
14:45:00 <heat> gog are you in a gang
14:45:00 <zid> gog: what's your passmarks
14:45:00 <heat> gong
14:45:00 <gog> zid: idk
14:45:00 <zid> https://cdn.discordapp.com/attachments/272621603836133378/1083549490641907772/image.png
14:45:00 <zid> I'm allowed to run it now
14:47:00 <zid> ryzen too fast, even with -march=sandy gcc, we're up to package 90
14:48:00 <heat> zid is everyone in the UK on cocaine
14:48:00 <IdentityInFlux> heat: yes
14:49:00 <heat> thank you zid
14:49:00 <zid> more or les
14:49:00 <IdentityInFlux> you're welcome zid
14:49:00 <zid> who are you
14:49:00 <heat> np gog
14:49:00 <zid> oh
14:50:00 <zid> The person from before
14:53:00 <sham1> gog: Ryzen Gang!
14:56:00 <gog> zid: 15606 lol
14:56:00 <zid> That's surprisingly high
14:56:00 <zid> what's the single?
14:56:00 <gog> 2517
14:56:00 <zid> My xeon just cracked like 2100 with overclock
14:56:00 <gog> and keep in mind this is a mobile cpu that's actually a zen2
14:57:00 <zid> yea
14:57:00 <zid> that's why I didn't try hard to end up with a 1950x or whatever
14:57:00 <heat> because your xeon sucked man
14:57:00 <zid> that xeon was incredibly dumbly good
14:57:00 <zid> for what it cost to put it together
14:57:00 <zid> compared to ryzen2
14:58:00 <gog> i have no complaints about my computer's performance after almost a year with it so
14:58:00 <zid> 2500 is more than fine
14:59:00 <gog> i'm curious what my boss' new computer does
15:00:00 <gog> he's gone at a trade show rn and it's sitting here in a box
15:00:00 <gog> i should open it
15:00:00 <zid> You should swap it for a different one, in a pink theme case
15:00:00 <gog> yes
15:01:00 <zid> https://cdn.discordapp.com/attachments/272621603836133378/1083130750691463278/image.png
15:01:00 <gog> hahaha cute
15:01:00 <zid> I saw some disgusting NSFL shit on reddit the other day
15:01:00 <zid> someone destroying an Evangelion edition gpu in order to put a water block on it instead
15:02:00 <gog> noooo
15:02:00 <zid> I almost shit his pants
15:02:00 <zid> and his shoes
15:03:00 <heat> his?
15:03:00 <heat> that's some dedication
15:03:00 <zid> I will walk to his house, and poop in his presumably, ugly sandals
15:04:00 <zid> cus nobody with sane footwear would do that
15:07:00 <bnchs> hi sid
15:08:00 <zid> sidden infant death?
15:12:00 <sham1> Either that or the unstable branch of Debian
15:14:00 <bnchs> i hate retroarch's cheats feature
15:14:00 <zid> retroarch is gross
15:14:00 <bnchs> set something to 0x25970F40
15:14:00 <bnchs> guess what
15:14:00 <bnchs> it ends up being 0x0F402597
15:15:00 <bnchs> they fucked up the byte swapping
15:15:00 <zid> retroarch is a frontend for stolen emulator cores btw
15:15:00 <bnchs> yes
15:15:00 <zid> so it's up to the emulator to do that bit, so no wonder it doesn't match retroarch's ui
15:15:00 <bnchs> i barely use it, than to see how shit it is
15:16:00 <bnchs> incluing the times it crashed my DE
15:16:00 <bnchs> general protection fault
15:23:00 <bnchs> https://github.com/libretro/RetroArch/blob/7e74d830ca97ccfdf18395e95bd9130b8046ff5f/managers/cheat_manager.c#L1040
15:23:00 <bslsk05> github.com: RetroArch/cheat_manager.c at 7e74d830ca97ccfdf18395e95bd9130b8046ff5f · libretro/RetroArch · GitHub
15:23:00 <bnchs> holy shit, they don't use shifts, they use MULTIPLY
15:23:00 <bnchs> like * 256 * 256 * 256 * 256
15:25:00 <sham1> That's horrible, although it does work obviously
15:26:00 <bnchs> yeah, it does work, but that sounds horribly inefficient than shifting
15:26:00 <bnchs> lest the compiler doesn't optimize it
15:27:00 <sham1> How would it be inefficient? The compiler would optimise that. It knows that that's 2^8 * 2^8 * 2^8 * 2^8 = 2^32
15:28:00 <bnchs> i mean if the compiler doesn't optimize it
15:30:00 <nortti> I think that's pretty unlikely. it can be implemented as two peephole passes (constant folding, conversion of multiplies to shifts), and I'd expect any compiler able to build retroarch to implement peephole optimization
15:30:00 <bnchs> true
15:45:00 <heat> i'm a HACKER
15:45:00 <heat> I use shifts
15:45:00 <bnchs> heat: i shift my ass in chairs, is that how it works?
15:47:00 <heat> yes
17:36:00 <bnchs> hi friends
17:36:00 <bnchs> and people who are not friends
17:36:00 <zid> heat: I need more benchmarks
17:50:00 <mjg> did osmeone say benchmark?
17:51:00 <mjg> > Benchmarking; by which I mean any computer system that is driven by a controlled workload, is the ultimate in performance testing and simulation. Aside from being a form of institutionalized cheating, it also offer countless opportunities for systematic mistakes in the way the workloads are applied and the resulting measurements interpreted.
17:51:00 <mjg> :S
18:05:00 <heat> mjg, did you see the weird unaligned ERMS results on ryzen?
18:05:00 <heat> its bizarre
18:05:00 <heat> i guess i'll need to find a way to align it here
18:15:00 <mjg> now
18:15:00 <mjg> no
18:15:00 <mjg> where
18:15:00 <demindiro> heat: which ryzen CPU?
18:15:00 <mjg> did not i mention rep likes aligned bufs?
18:15:00 <mjg> ignoring fsrm
18:15:00 <mjg> 16 bytes minimum
18:16:00 <demindiro> With ermsb it should matter less / not at all though
18:16:00 <mjg> erms does not help with aignment issues
18:17:00 <heat> https://gist.github.com/zid/34bfbe000db79dbb4bc33db81152ae82
18:17:00 <bslsk05> gist.github.com: out2.txt · GitHub
18:17:00 <heat> 64-byte aligned: https://gist.github.com/zid/4e444b66dd9dea03081fed2283c9e5c7
18:17:00 <bslsk05> gist.github.com: gist:4e444b66dd9dea03081fed2283c9e5c7 · GitHub
18:18:00 <heat> mjg, erms is blind rep movsb, memcpy is glibc memcpy, our_memcpy = my GPR-only+erms memcpy
18:18:00 <mjg> so what's the alignment of the target buf
18:18:00 <heat> whatever new[] was giving me
18:19:00 <mjg> 's not the way to bench dawg
18:19:00 <heat> it's very interesting how ERMS starts sucking after 4K
18:19:00 <mjg> you aligned_alloc to control it
18:19:00 <heat> like look at that shit, why
18:20:00 <mjg> this format is shit to read mate
18:20:00 <heat> why
18:20:00 <mjg> also does not help mb vs gb
18:20:00 <mjg> woudl be best to graph it
18:20:00 <heat> lmao
18:20:00 <heat> do you want a powerpoint too?
18:21:00 <mjg> dude get some basic gnuplot fu
18:21:00 <mjg> it really is not difficult
18:22:00 <heat> anyway i probably want to align erms
18:22:00 <heat> but to what? I see you align to 16
18:22:00 <heat> it doesn't help that the amd opt manual is completely silent about any of this
18:24:00 <sham1> Why do a PowerPoint when Jupyter do the job
18:24:00 <mjg> i found haswell is affected by anything < 32
18:24:00 <mjg> newer archs are fine with just 16
18:24:00 <mjg> no clue about amd
18:24:00 <mjg> i picked 16 as a tradeoff
18:25:00 <mjg> it already helps evne on haswell
18:25:00 <mjg> and i could not be fucked o timplement more and runtime switch on it
18:25:00 <mjg> on that note, i gave slight thought to that comparison of addresses target vs source upfront
18:26:00 <mjg> even if direction of copying affects stuff, i'm 99% confident the very fact there is a branch and a possible mispredict on it
18:26:00 <mjg> maeks the check pessimal
18:26:00 <mjg> it possibly makes sense if you are resorting to rep
18:26:00 <mjg> that will is ot verified, along with the abve claim
18:27:00 <mjg> that is to be verified*
18:27:00 <mjg> wtf
18:28:00 <mjg> i'm trying to declutter my backlog here though
18:28:00 <mjg> and the fact that automemcpy machinery des not work ootb is not helping
18:28:00 <mjg> re gnuplot, split this one func per file
18:29:00 <heat> i'm not plotting for you, sorry
18:29:00 <heat> i can read this just fine
18:29:00 <mjg> lol
18:29:00 <mjg> i'm sayin give yourself a shot at plottin, you will see it is EZAF
18:29:00 <mjg> and if you don';t like it anyway, so be it
18:30:00 <heat> i use google benchmark because it's the easiest and highest quality framework for me to use
18:30:00 <heat> i'm not going to handroll some shitty code for gnuplot
18:31:00 <heat> in fact this thing can spit out json and csv so if you really want to, glhf
18:31:00 <heat> you can literally use this in ppt :))
18:34:00 <mjg> i would think that's boomer
18:34:00 <mjg> grew up without a graphical interface and now does not want graphs
18:34:00 <mjg> btw gnuplot can do ascii :p
18:34:00 <mjg> and here you are, genz. is that neoboomer?
18:35:00 <mjg> anyhow a benchmark were yu did not control aigment for the target buffer is totally geezered
18:36:00 <mjg> also you probably want falign-loops=32
18:36:00 <heat> you're so fucking annoying it's not even funny
18:37:00 <mjg> see the above quote
18:37:00 <heat> you are the real unix geezer
18:37:00 <mjg> > Benchmarking; by which I mean any computer system that is driven by a controlled workload, is the ultimate in performance testing and simulation. Aside from being a form of institutionalized cheating, it also offer countless opportunities for systematic mistakes in the way the workloads are applied and the resulting measurements interpreted.
18:37:00 <mjg> it is hard to do a sensible test for things like this. by not controlling for the stuff like i mentioned above you are not even trying
18:39:00 <bnchs> did retroarch just suddenly become worse?
18:41:00 <bnchs> >trying to modify the memory value for current level to 5
18:41:00 <bnchs> >get taken to the 8th circle of hell, because retroarch makes it 327680
18:53:00 <zid> I use gnuplot as a debugger occasionally
18:55:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/774148853745057792/unknown.png
18:56:00 <zid> debugging my normal calculations, just dumped the results to a file instead of writing code to try view them somehow :P
19:00:00 <heat> zid, https://gist.github.com/heatd/165b70a4e0b75e815b82d723c01637dc new bench
19:00:00 <bslsk05> gist.github.com: bench3.cpp · GitHub
19:01:00 <heat> this one will take a good bit longer to run
19:02:00 <zid> I'm EMERGING
19:02:00 <zid> not sure how well it'll react to ctrl-z
19:02:00 <mjg> what does this do? benchmark::ClobberMemory();
19:02:00 <mjg> just clflushes?
19:03:00 <heat> no
19:03:00 <heat> just a compiler barrier
19:03:00 <heat> asm volatile("":::"memory")
19:03:00 <zid> "memory" in le clobbers
19:03:00 <zid> this gigabyte mobo doesn't know what 100MHz is
19:03:00 <zid> it's at 99.98MHz and makes all my speeds look super ugly
19:04:00 <heat> mjg, fyi locally it seems that 32 alignment is ideal
19:04:00 <heat> doubles speed for erms pretty much
19:04:00 <mjg> how does it differ vs 16
19:04:00 <mjg> that's on your kaby?
19:04:00 <heat> yes
19:05:00 <mjg> i'm gonna revisit this bit as well
19:05:00 <mjg> note all the stringop work i did was almost 5 years ago
19:05:00 <mjg> i'm gettin fuzzy on details
19:06:00 <mjg> the code to perform alignment is kind of crap afair
19:06:00 <mjg> im gonna hack it up in c and check what clang comes up with
19:07:00 <mjg> target bufs like to be misaligned big time, but i don't rmeember how often that happens of the range which falls under rep usage
19:07:00 <mjg> s/of/for
19:17:00 <mjg> heat: dtrace -n 'fbt::memcpy:entry,fbt::memset:entry,fbt::memmove:entry /arg2 > 256/ { @alignment[arg0 & 0x1f] = count(); }' for buildkernel
19:18:00 <mjg> https://dpaste.com/DWUWKGPW9
19:18:00 <bslsk05> dpaste.com <no title>
19:18:00 <zid> heat always tracing the d
19:18:00 <mjg> so for these routines vast majority is already aligned
19:19:00 <heat> i don't use dtrace, im not cringe
19:19:00 <mjg> heat gets his data the old fashion way: just assume whatever you take out of your ass is correct and roll with it
19:19:00 <mjg> if someone questions it later "you had reasons"
19:21:00 <heat> no, i just don't have dtrace
19:23:00 <mjg> for copyin/copyout
19:23:00 <mjg> 24 32636
19:23:00 <mjg> 16 521734
19:23:00 <mjg> 8 33705
19:23:00 <mjg> 0 2168248
19:23:00 <mjg> the rest is very little
19:24:00 <mjg> but it does happen
19:24:00 <mjg> https://dpaste.com/8DWAG9CLE
19:24:00 <bslsk05> dpaste.com <no title>
19:32:00 <heat> I have realised my rename is not implemented correctly and is not atomic
19:32:00 <heat> yay?
19:33:00 <mjg> ok mjg@
19:34:00 <heat> i'm fairly scared of touching any of my dcache code
19:34:00 <heat> basically so full of fucking locks, most of which I don't even remember what they cover
19:36:00 <mjg> they cover pragmatically picked vars
19:44:00 <zid> mjg is broken
19:44:00 <zid> he didn't say pessimal in that sentence
19:49:00 <heat> mjg is pessimal
19:57:00 <zid> my audio is dropping out, look at my VM to see what it's doing
19:57:00 <zid> "emerge: (433 of 589) dev-lang/rust-1.68.1 Compile"
20:04:00 <geist> rUUUUST
20:21:00 <zid> I ran out of thermal paste at last, got some mx-4 for my Q6600
20:22:00 <zid> I quickly googled for a graph in case any of the modern brands are any better than 20 year old stuff
20:22:00 <zid> nope, mayonnaise beats noctua.
20:22:00 <geist> huh really? was gonna say noctua is okay
20:22:00 <zid> It's basically "Is it wet? Yes? Then within a tenth of a degree"
20:23:00 <geist> well, sure. but there is also whether or not it'll remain that way in a week or a year
20:23:00 <geist> obbiously mayonaise will work, but it'll dry out, etc
20:23:00 <zid> yea that's why they exist
20:23:00 <zid> but it's funny still
20:23:00 <geist> yah
20:24:00 <geist> my guess is the way you apply it is probably generally more important
20:24:00 <geist> and i honestly dunno if i ever do the right thing nowadays. too much? not enough? beats me!
20:24:00 <geist> also i wonder if i should every year or so reapply the stuff
20:24:00 <zid> I think it's basically self correcting
20:25:00 <zid> as long as you have enough mounting pressure you're good to go
20:25:00 <zid> as theoretically it only exists to fill voids
20:25:00 <geist> yah, unless you put way too little i guess
20:25:00 <geist> but i usually do the fairly decent sized blob in the middle and it seems to spread out properly, so i think i'm basically doing the right thing
20:25:00 <geist> doesn't seem that smearing it out ahead of time or whatnot really makes a difference
20:26:00 <zid> yea it's funny to watch people fight over the best 'technique'
20:26:00 <zid> I've always done 'just squirt it around a bit until it looks like the last frame of a porno'
20:26:00 <zid> works great
20:26:00 <geist> it's possible there's a teeensy bit of difference if you're extreme overclocking
20:27:00 <geist> like too much may actually not like it touch as efficiency as it could, etc etc. but yeah, i think for the vast majority of cases you're within a C or two of ideal if you just get some of it basically on there
20:27:00 <zid> Butter the toats.
20:28:00 <zid> I think the weird pattern people might actually end up having air bubbles sometimes
20:28:00 <geist> but annoyingly i think it might matter a teensy bit for Zen 4 vs other cores at the moment, since zen 4 will run right up to the thermal limit and then throttle itself, and it's designed to do that
20:28:00 <zid> yea all modern cpus are
20:28:00 <geist> not entirely, actually. zen 4 takes it to the next level
20:28:00 <zid> derbaur dropped a chat with an intel engineer.. today
20:29:00 <zid> saying they do exactly the same thing too
20:29:00 <zid> and any wasted heat below the limit is unused potential
20:29:00 <geist> zen 4 *wants* you to go right to the limit, and that's part of the design, whereas a lot of the other fairly modern stuff is more like they'll throttle to avoid damange
20:29:00 <geist> possible the 13th gen intel stuff is more okay with it
20:29:00 <geist> and laptops yeah have been doing that sort of thing for a while
20:30:00 <zid> That they used to design for 100C once you saturated the part entirely in heat over 20 minutes, but now the power density is so high and the heat governer exists etc so they just turbo up to 'hot' then stay there by modulating freq
20:30:00 <geist> but in that particular situation, the cooler and effiiency of it actually does equate to more 'speed' out of your core
20:30:00 <zid> I have package temp 60C but 30C core temps cus.. power density hotspots
20:31:00 <geist> yah when i unlock PBO on my 5950x it'll eventually get up to 80C or so after a bit of running, but i'm okay with that
20:31:00 <geist> normally it runs a nice 60-70C when under load
20:31:00 <zid> I'm up to 75C, building llvm
20:31:00 <zid> but the L3 is only at 40C, millimeters away
20:32:00 <zid> power density ho
20:32:00 <geist> yah
20:33:00 <zid> I think I'm good to ignore my thermal paste situation until I can be bothered to play around with overclocking
20:33:00 <zid> 70C on a chip that's actively trying to be hot is great
20:33:00 <geist> yah agreed
20:34:00 <zid> I was going to get a 'new' cooler for it but prices were absolutely nuts
20:34:00 <zid> £150 for an aio, I can get the full radiator from a ford focus for £25
20:34:00 <zid> So I ended up finding a £6 bracket adapter for my 212
20:35:00 <zid> (and it was delivered within 12 hours, heh)
21:05:00 <mjg> zid: can you strace -fo /tmp/crap emerge media-sound/rexima
21:05:00 <mjg> zid: it is an almost hello-world port
21:12:00 <zid> (562 of 589)
21:12:00 <zid> maybe soon
21:27:00 <heat> zid: can you send me one of your kidneys
21:27:00 <heat> i need it for a benchmark
21:41:00 <brunothedev> to write my vbe driver, i am going to real mode, make a call, store the info, go into protected mode, make a call to my c function and provide the info as args, does this works?
21:41:00 <heat> 🚨🚨🚨 bad idea alert 🚨🚨🚨
21:42:00 <brunothedev> heat: i love bad ideas, i am one myself, tho, does it compile and works?
21:43:00 <nortti> if you want to make your life worse for zero benefit, I think so, though you need to maintain real mode environment intact into your kernek
21:43:00 <heat> fuck do i know
21:43:00 <heat> please stop
21:43:00 <nortti> *kernel
21:43:00 <nortti> which might necesitate writing your own bootloader since I don't know if grub might have already trampled over that by the time you hit your kernel entry point
21:43:00 <heat> do understand that you're very much alone if everyone tells you "its a bad idea" and you go ahead and do it
21:43:00 <brunothedev> heat: is that i have no other options
21:44:00 <heat> yes you fucking do
21:44:00 <brunothedev> heat: what?
21:44:00 <heat> klange has been through it with you like 4 times
21:44:00 <heat> multiboot 1 and 2 give you a framebuffer
21:44:00 <heat> please use it
21:45:00 <brunothedev> ok so what simple os uses it? The grub example is not a good reference
21:46:00 <heat> yes it is
21:46:00 <nortti> what have you gotten working thus far? I've not fully followed all this conversation but you are able to get the framebuffer address and its parameters, right? have you been able to blast some garbage onto the screen yet?
21:47:00 <nortti> (not a value judgement on what your OS is going to do, literally just "can you write random bytes and have that cause an effect on-screen?")
21:48:00 <brunothedev> nortti: the grub example at best nearly hides the software to write a pixel, and at worst dont have a implementaion for it
21:48:00 <brunothedev> the maximum it does is to tell the address to write the pixel on: https://github.com/cloudblaze/multiboot2/blob/master/kernel.c#L163
21:49:00 <bslsk05> github.com: multiboot2/kernel.c at master · cloudblaze/multiboot2 · GitHub
21:49:00 <heat> you do realize you just need to write bytes to it
21:49:00 <heat> *framebuffer = 0xRGBA;
21:49:00 <brunothedev> heat: ok, lemme try a rando value
21:54:00 <heat> mjg, genius unix professional code: https://elixir.bootlin.com/linux/v2.6.16/source/fs/dcache.c#L1309
21:54:00 <bslsk05> elixir.bootlin.com: dcache.c - fs/dcache.c - Linux source code (v2.6.16) - Bootlin
21:55:00 <heat> goto considered harmless
21:55:00 <Ermine> heat: why are you lurking in 2.6 kernel?
21:56:00 <heat> i'm trying to see a simpler example of a rename operation
21:57:00 <heat> this fucking sucks
21:57:00 <heat> you need to grab like 400 locks for it
22:12:00 <heat> random prefetches in the middle of vfs code are simply brilliant
22:18:00 <mjg> rename is notorioushily shit to implement
22:18:00 <mjg> i also refer you to the netbsd ufs code
22:18:00 <mjg> with all the comments inside
22:21:00 <heat> /* XXX FUCK THIS SHIT FUCK SHIT MAN WTF BULLSHIT */ goto bullcrap_fuckyou;
22:23:00 <heat> mjg, found the best intel feature ever
22:23:00 <heat> Fast Zero Length REP MOVSB
22:23:00 <heat> The latency of a zero length REP MOVSB is now the same as the latency of lengths 1 to 128 bytes.
22:24:00 <mjg> ulala
22:24:00 <mjg> +#define X86_FEATURE_FSRS (12*32+11) /* Fast short REP STOSB */
22:24:00 <mjg> +#define X86_FEATURE_FZRM (12*32+10) /* Fast zero-length REP MOVSB */
22:24:00 <mjg> +#define X86_FEATURE_FSRC (12*32+12) /* Fast short REP {CMPSB,SCASB} */
22:24:00 <mjg> the q is how fast is the sort thing tho
22:25:00 <heat> sort?
22:25:00 <mjg> short
22:25:00 <mjg> as noted preiouvsly it was still slower than the overlapping stores
22:25:00 <heat> ah yes
22:25:00 <mjg> for up to 64 afair on ice lake
22:25:00 <heat> welp on zen3 it's still slow
22:25:00 <sham1> "12 * 32 + 11"
22:25:00 <mjg> i would totes welcome rep which is just doing it right kthx
22:25:00 <sham1> But why is it spelt like that
22:25:00 <sham1> Why use a multiplication
22:26:00 <heat> cuz they're doing it based on CPUID words
22:26:00 <heat> so leaf 0 gets word 0 1 2, leaf 1 gets 3 4 5, etc
22:26:00 <sham1> Even then, wouldn't it be more fluent to use hexadecimals and shifts?
22:26:00 <mjg> you know what would be funny
22:26:00 <heat> sham1, why?
22:26:00 <mjg> if Fast zero-length REP MOVSB was sitll so expesnive you should branch on it
22:27:00 <sham1> heat: no real reason other than aesthetics
22:27:00 <heat> hex doesn't work here
22:27:00 <heat> nor shifts nor anything else
22:27:00 <heat> it's just a "bit number" that you then go and index into a bitmap
22:27:00 <mjg> where are these ops tho
22:27:00 <mjg> i don't see intel saying anything
22:28:00 <heat> feature_map[feature / 32] & (1UL << (feature % 32))
22:28:00 <sham1> C23 can't come fast enough to grant us binary literals
22:28:00 <heat> mjg, what ops?
22:28:00 <mjg> aand there it is
22:28:00 <zid> I mean, every C compiler has supported it since the 90s anyway sham
22:28:00 <sham1> But it's not standard!
22:28:00 <zid> waiting for C23 doesn't really gain you anything
22:28:00 <mjg> new version of optimization manual states it
22:28:00 <zid> 90s compilers won't support C23
22:28:00 <zid> there's 0 downside to just using 0b now
22:29:00 <heat> mjg, yes honey that's what I'm looking at
22:29:00 <bnchs> heat: i like leaving comments like that
22:29:00 <sham1> And I don't support 90s compilers. What's the point?
22:29:00 <zid> You can just go "Yea well this is C23 code"
22:29:00 <mjg> REP MOVSB performance of zero length operations is enhanced. The latency of a zero length REP MOVSB
22:29:00 <mjg> is now the same as the latency of lengths 1 to 128 bytes. When both Fast Short REP MOVSB and Fast Zero
22:29:00 <mjg> Length REP MOVSB features are enabled, REP MOVSB performance is flat 9 cycles per operation, for all
22:29:00 <zid> if anyone says "omg that's a compiler extension!!"
22:29:00 <mjg> strings 0-128 byte long whose source and destination operands reside in the processor first level cache.
22:29:00 <heat> oh yeah wanna copy? i'll copy
22:29:00 <mjg> Lol
22:29:00 <mjg> so it still makes sense to branch on it
22:29:00 <heat> REP CMPSB and SCASB performance is enhanced. The enhancement applies to string lengths between 1
22:29:00 <heat> Support for fast short REP CMPSB and SCASB is enumerated by the CPUID feature flag:
22:29:00 <heat> ands reside in the processor first level cache.
22:29:00 <heat> and 128 bytes long. When the Fast Short REP CMPSB and SCASB feature is enabled, REP CMPSB and REP
22:29:00 <heat> SCASB performance is flat 15 cycles per operation, for all strings 1-128 byte long whose two source oper-
22:30:00 <mjg> is flat 12 cycles per operation, for all strings 0-128 byte long whose destination operand resides in the
22:30:00 <mjg> When Fast Short REP STOSB feature is enabled, REP STOSB performance
22:30:00 <sham1> I mean, C23 also added typeof to the standard, which is nice
22:30:00 <mjg> processor first level cache.
22:30:00 <mjg> that's still unusable
22:30:00 <heat> mjg, have you seen the """new""" recommendation
22:30:00 <heat> well, one of
22:30:00 <mjg> which page
22:30:00 <heat> just a sec
22:30:00 <heat> A two-socket Sapphire Rapids system can have up to 224 (2 sockets x 56 cores/socket x 2
22:30:00 <heat> threads/core) hardware threads. Scalability and performance bottlenecks may happen when all of these
22:30:00 <heat> hardware threads compete for the same addr
22:30:00 <heat> WHAT
22:31:00 <sham1> Also, #embed is nice in general to have, because unlike doing weird linker hacks, there's less chance of accidental UB
22:31:00 <sham1> It's also more portable
22:32:00 <heat> mjg, the "how to fix it" is even more hilarious
22:32:00 <brunothedev> error: invalid use of void expression: "*fb = *where;"
22:32:00 <heat> learn C please
22:32:00 <bnchs> brunothedev: wtf are you doing?
22:32:00 <nortti> brunothedev: what are the types of "fb" and "where" and why?
22:33:00 <brunothedev> heat: learning it
22:33:00 <heat> wrong channel, see ##c
22:33:00 <bnchs> hi Amorphia
22:33:00 <heat> how tf do you pronounce your name?
22:33:00 <heat> benches? bancs?
22:34:00 <brunothedev> nortti: fb is "void *", where is "uint32_t *"
22:34:00 <bnchs> heat: bunches
22:34:00 <heat> oooooooooooooohhh
22:34:00 <bnchs> brunothedev: you don't dereference a void *
22:34:00 <zid> quick, write his code for him one line at a time
22:34:00 <heat> yep, pretty much
22:34:00 <heat> explain him the whole of C
22:35:00 <bnchs> yes, i'll explain to him the C lore
22:35:00 <brunothedev> lmao
22:35:00 <heat> please go through the k&r book and if needed go to ##c
22:35:00 <nortti> modern c is also pretty good
22:35:00 <heat> i'm a rust purist so I struggle every time someone talks about this
22:36:00 <brunothedev> heat: r*st(vomit emoji)
22:36:00 <nortti> brunothedev: https://gustedt.gitlabpages.inria.fr/modern-c/
22:36:00 <bslsk05> gustedt.gitlabpages.inria.fr: Modern C
22:37:00 <heat> >int printf ( char const format [ static 1] , ...) ;
22:37:00 <heat> NOPE
22:37:00 <bnchs> heat: so what if you listen to the alphabet
22:38:00 <bnchs> A, B, C.....
22:38:00 <heat> D
22:38:00 <heat> heheheheehehehehehe
22:39:00 <sham1> heat: tbf, that signature for printf is semantically valid, you do want at least to have a '\
22:39:00 <sham1> A \0 there
22:39:00 <nortti> yeah, the coding style advocated by modern c makes sense, even if it is unconventional
22:40:00 <brunothedev> most learning c resources should be called: Learning libc (and a little bit of c)
22:41:00 <heat> it's a travesty
22:41:00 <heat> it is barely C
22:42:00 <nortti> in the sense that C sucks majorly and that sucks marginally less, yes
22:43:00 <heat> how does it suck less?
22:43:00 <heat> please parse the syntax "char const format[static 1]"
22:43:00 <nortti> it makes a part of the interface that would traditionally be left implicit part of the type system
22:44:00 <heat> wth is the static and the 1?
22:44:00 <heat> why are keywords inside []
22:44:00 <nortti> "at least one char"
22:44:00 <nortti> it's part of c99 iirc
22:44:00 <heat> how is it at least? this is not consistent with any other bit of the language
22:45:00 <nortti> yeah, it's a messy syntax due to backcompat (can't have new resrved words unless they're _Reserved, aiui ppl were already putting shit in there and expecting it to do nothing)
22:46:00 <nortti> so why not repurpose the one that already has two different meanings
22:46:00 <heat> because it looks horrible and makes no sense
22:47:00 <brunothedev> it is funny how a recommendation to i read an old c book sparked a c specifications argument
22:48:00 <heat> file scope static makes sense, block scope static isn't too great but still makes some sense, static to denote "at least N elements" does not make sense
22:48:00 <nortti> do you have a better suggestion for how to mark it, given the constraints?
22:49:00 <heat> define a new keyword and stop being stupidly backwards compat
22:49:00 <heat> or new syntax
22:49:00 <mjg> heat: so according to agner that up/down thing is about bypassing false memory dependency problems
22:50:00 <mjg> i can slap together a bench which intentinally runs into them
22:50:00 <sham1> heat: static there is yet another way that keyword is being overloaded. But yeah, it means that the pointer points to a thing that has at least one element. I.e. it's not a NULL
22:50:00 <mjg> we will see what happens
22:50:00 <heat> mjg, what up/down thing?
22:50:00 <sham1> Also IIRC the correct one would be "int printf(char format[const 1], ...);"
22:51:00 <nortti> wait, printf is not defined to not mutate the format string?
22:51:00 <sham1> Because if printf modifies the format string, that'd be just some veritable BS
22:51:00 <heat> it cant mutate the format string
22:52:00 <nortti> yeah, posix uses const char *restrict format, even
22:52:00 <sham1> That's some veritable BS on the standard's part
22:52:00 <mjg> heat: if (dst < src)
22:52:00 <mjg> in memcpy
22:52:00 <nortti> sham1: hm?
22:52:00 <brunothedev> is there any os that use multiboot_tag_framebuffer? Literally anyone simple enough to understand the code
22:52:00 <mjg> totally gonna check for it now
22:53:00 <heat> learn C
22:53:00 <sham1> nortti: it's absolutely disgusting and it shouldn't be like that.
22:53:00 <heat> mjg, wdym false memory dependency problems?
22:54:00 <heat> i am very confused
22:54:00 <brunothedev> heat: i asked for a os that uses the thing, this is not a c problem
22:54:00 <heat> yes it's a C problem because you clearly don't understand pointers
22:54:00 <nortti> sham1: wait, I just read you wrote `[const 1]` and not `[static 1]`, are you saying the standard should express a const char* with const inside the brackets instead of outside them?
22:54:00 <brunothedev> heat: pointers are a reference to a memory address
22:55:00 <bnchs> brunothedev: the hint is, you cast the void pointer to a pointer of your type, aka uint32_t
22:55:00 <sham1> nortti: yes.
22:56:00 <heat> i'm fairly sure char str[const 10] is correct
22:57:00 <heat> no idea if char const str[10] is semantically the same thing
22:57:00 <brunothedev> bnchs: oh ok, i thought pointers in this context is just a pointer to a certainmemory address that i can write literally anything
22:57:00 <nortti> heat: I think char const str[10] is semantically same as char const *str, that is, without static it's just ignored
22:57:00 <sham1> In a parameter listing like this one, char format[const 1] is basically just const char *format, except that the compiler is allowed to assume that there is at least one element there
22:58:00 <sham1> And yeah, const str[10] is just a lie in a parameter context
22:58:00 <heat> mjg, anyway erm, isn't all that stuff supposed to be memmove?
22:59:00 <sham1> Or was it equivalent to char *const format. I don't remember, I'll admit
23:01:00 <sham1> But yeah, projects like LLVM treat foo bar[static 1] as basically saying "this cannot be NULL" and for example clang will give you a warning if it can prove that you're maybe possibly passing one in
23:02:00 <sham1> You can even put "restrict" within the square brackets there and suddenly it's restrict-qualified
23:03:00 <nortti> sham1: afaict, looking at C17, `char foo[const 10]` is equivalent to `char * const foo`
23:04:00 <nortti> that is, the function body is allowed to do *foo = 0, but not foo = 0
23:04:00 <sham1> Yeah okay, so for printf the actual thing to do would be "int printf(const char format[static 1], ...)"
23:04:00 <nortti> yeah
23:05:00 <sham1> Or at least that's my opinionated take on it, because to me modifying the format string is heresy
23:05:00 <heat> we should make rodata writeable
23:06:00 <nortti> read-ourite data
23:13:00 <sham1> On a related note, I need to figure out how to have ld separate .rodata from .text, just so I can make .rodata not executable
23:13:00 <sham1> So it'd be its very own program segment
23:17:00 <heat> doesn't yours do it by default?
23:17:00 <sham1> Nah, it just shoves it into the R-X segment alongside .text. Not to mention that also happening outside of OSDev as well like with Linux binaries
23:18:00 <heat> -z separate-code
23:19:00 <sham1> Ah. Good to know
23:19:00 <heat> i think that should work, but please try
23:33:00 <moon-child> 'Obvious oversights. Textbook mistakes. Surely not in the OpenBSD console code?'
23:42:00 <heat> moon-child, is that a quote from the bible
23:42:00 <kazinsal> The Gospel According to tedu
23:45:00 <moon-child> https://research.exoticsilicon.com/articles/unbreaking_utf8_on_the_console I got bored and skipped to the end when they started explaining what utf8 is, but apparently they had a turbo fucked utf8 decoder
23:45:00 <bslsk05> research.exoticsilicon.com: ExoticSilicon.com - fixing cringeworthy bugs in the OpenBSD console code
23:46:00 <kazinsal> christ on a bike that CSS
23:46:00 <moon-child> come on kazinsal it's cute
23:47:00 <kazinsal> it's like a da share z0ne meme explaining a bug in an esoteric unix clone
23:47:00 <kazinsal> da mothafuckin /usr/share z0ne
23:49:00 <heat> what is that
23:50:00 <sham1> That background is cringe