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=21&m=10&d=7
00:01:00 <geist> probably not
00:02:00 <geist> you could run a yield instruction while you poll at least to make it easier on the cpu if it's hyperthreaded
02:31:00 <klange> I also need to make some considerable changes to my ATA driver... I swear it was more stable in toaru32, but then I did make some changes for a qemu upstream change that broke a bad assumption in my code, and also I just haven't been using it for several years...
02:32:00 <klange> One of the last few hard requirements for ToaruOS 2, I think.
03:35:00 <geist> possibly SMP too? SMP now adds the possibility that your IRQ handler and other code in the driver are running at the same time
03:39:00 <klange> Possibly, though for things that have thus far been being wonky I don't think that's relevant, but the thought is pushing me towards actually doing a classic textbook "disk scheduler" so I can keep things synchronized.
03:40:00 <klange> Like, in vbox I've got a CD drive that my driver thinks is a hard drive, and that's all stuff that should be before any IRQ handlers and be fully sequential as it's at module load time...
03:41:00 <geist> yah always seemed like a fun thing to implement
03:41:00 <geist> something about driving real physical disks so you can actually hear it seeking (or not) because you improved your code
03:41:00 <geist> SSDs take away all the fun
17:08:00 <ZetItUp> erm does this scroll slow with mouse scroll wheel for anyone else? https://qemu-project.gitlab.io/qemu/system/images.html
17:08:00 <ZetItUp> only page which does it, kinda weird
17:09:00 <zid> no but I also basically disable all javascript
17:09:00 <ZetItUp> hehe
17:09:00 <moon-child> i have js on, scrolling is fine
17:11:00 <ZetItUp> hmm
17:11:00 <zid> Time to profile your browser
17:11:00 <zid> chrome has a profiler built in at least
17:14:00 <junon> ZetItUp it also feels weird to me
17:15:00 <junon> not just you
17:15:00 <zid> maybe it's the css sidepanel stuff
17:15:00 <zid> messing with ya
17:15:00 <junon> No it's jquery which always attaches listeners to pass them to its own listener set.
17:16:00 <junon> That's why we don't notice it much these days given that jquery has mostly died off. But it was renown for its scroll "jank" back in the day.
17:16:00 <junon> ZetItUp if you go to the <body> tag in inspector and in the CSS panel click event listeners and look at `scroll`'s you can set a breakpoint in the callback function and see that it's fired whenever you scroll.
17:17:00 <moon-child> man
17:17:00 <moon-child> web is a fucking mess
17:17:00 <junon> Yes. I hope it dies some day.
17:17:00 <ZetItUp> junon will try that :D
17:18:00 <junon> And in chrome at least you can click "remove" and see if it makes any difference.
17:18:00 <moon-child> in a 'real' environment, if you need a scroll bar, the event triggered by the scroll wheel would _cause the scroll to happen_. EZ. And if you want to add something else to do there too, you can. But the web is weirdly stratified
17:18:00 <ZetItUp> yeah removing it solved it hehe
17:20:00 <Oli> You have made me ponder about whether a responsive web site or operative system development are harder to pull in general.
17:24:00 <zid> don't worry, web devs have almost finished reimplementing winapi
17:24:00 <zid> so they're the same thing
17:24:00 <junon> Operating system development is much larger but my experience thus far has been that I'm rarely blocked trying to fix trivial small things all the damn time.
17:24:00 <zid> except the winapi is hosted on 14 other computers
17:25:00 <moon-child> junon: yes, os development is pretty much the epitome of 'fuck it, I'll fix it myself'
17:29:00 <zid> You don't want me to fix it, trust me
17:29:00 <zid> "Why would anybody ever use this api anyway? *delete*"
17:29:00 <moon-child> well, you get to fix your own shit
17:29:00 <moon-child> I fix mine
17:29:00 <moon-child> :)
17:29:00 <zid> "Why would I have written this api? *delete*"
17:34:00 <junon> ZetItUp: curious, does running this in the console also fix it (after a refresh)?: void(window.addEventListener('scroll',e=>e.stopImmediatePropagation(),true))
17:34:00 <moon-child> junon: why void()
17:35:00 <junon> If so, add it to a userscript. There is no possible way to remove event listeners you don't have handler function references to from `window`, which is where jquery attaches its scroll handler.
17:35:00 <junon> moon-child: it's a habit of mine I use when doing hacks/javascript injections, left over from the old days of `javascript:` uri scheme javascript injections
17:36:00 <junon> It basically means "discard the result of the expression and substitute `undefined` / do nothing"
17:36:00 <moon-child> oh yes, web security model is bonkers
17:36:00 <junon> Because in the old days, `javascript:somecode` would execute somecode and then set the result as the document's body, for some reason
17:36:00 <zid> I miss those days
17:36:00 <junon> wrapping it in `void()` prevented that behavior, so I still do it to this day to guarantee zero side effects (though it's probably not useful anymore)
17:36:00 <ZetItUp> junon: works like a charm :D
17:37:00 <junon> glad to hear it :)
17:37:00 <junon> basically sets itself as the first scroll handler then tells the event to stop processing any later handlers; doesn't remove them but prevents them from firing at all.
17:38:00 <junon> I hate the web.
17:39:00 * junon sashays back to writing Go for work
17:39:00 <moon-child> I think I prefer js to go
17:39:00 <junon> Go isn't a bad language, it's just a dumb language. The module system is bonkers though.
17:40:00 <zid> bonkers badonkers
17:40:00 <junon> I maintain too much JS to enjoy writing it these days.
17:40:00 <junon> and TS is just Microsoft advertising in the form of a programming language.
17:40:00 <moon-child> 'isn't a bad language, it's just a dumb language' I would apply that description to java more than go. I feel the former had a lot more thought put into its design
17:41:00 <moon-child> like, go's error model is bonkers. And type system is c lite, which I have definitely become disillusioned with; hm or dynamic or bust
17:41:00 <moon-child> imo
17:42:00 <junon> Java is the perfect language for writing boring code. If you want verbose, clear, no-nonsense code with a LOT of tools, a LOT of introspection, and a LOT of long identifiers, then Java is perfect. It gets out of your way when you need it to assuming you're using a featureful IDE (and not e.g. ViM, though there are ways... terrible ways... to make Vim java-friendly)
17:42:00 <junon> The only thing they screwed up with Java is unchecked exceptions IMO. Should have never existed.
17:42:00 <junon> Go's error system is indeed confusing as hell.
17:43:00 <junon> I'm still learning Go and that's something that even the experienced Go devs on my team struggle with.
17:43:00 <moon-child> if you want to get rid of unchecked exceptions, you also need to get rid of null. Otherwise it's impossible to write a meaningful method that throws nothing. Or you slap 'throws NullPointerException' on everything which is kinda dumb
17:43:00 <junon> I would be okay with a few reserved, language-level unchecked exceptions.
17:43:00 <junon> But not user-defined ones.
17:44:00 <moon-child> I mean, getting rid of null sounds like a pretty solid change to me... :)
17:44:00 <zid> I want the whole language not to be user defined
17:44:00 <zid> that's where the trouble starts
17:44:00 <zid> letting people write their own expressions
17:44:00 <zid> they start immediately taking the piss
17:44:00 <junon> OutOfMemoryException, NullPointerException, etc. But getting rid of null would also be nice. I don't mind it in Java too much though since they're easy to debug.
17:44:00 * gog throws up
17:45:00 <moon-child> gog: :/
17:46:00 <gog> i should have said "updog"
17:46:00 <zid> hey upgog
17:46:00 <junon> Java 8 and beyond did too much syntactically IMO. All the streams and arrow functions and stuff.
17:46:00 <junon> Java 7 was probably the best version of Java. Generics were added and that was all the language needed IMO.
17:47:00 <gog> what's upgog
17:47:00 <junon> Just like Javascript adding all sorts of crazy things without anyone saying "hey maybe the language doesn't need 100 different paradigms, we should probably cool it with all of the features".
17:47:00 <gog> every programming language should support every kind of construct
17:47:00 <zid> at the same time
17:47:00 <gog> yes
17:47:00 <zid> and none of them should interact cleanly
17:47:00 <mjg> :)
17:47:00 <zid> aka C++
17:47:00 <gog> even more yes
17:48:00 <junon> hEy HaVe yOu eVeR hEaRd oF mOnAdS?!!
17:48:00 <moon-child> so basically unix
17:48:00 <mjg> you take that back111
17:48:00 <gog> that reads like a "bofa" joke
17:49:00 <gog> bofa deez monads
17:49:00 <zid> MONA DEEZ NUTS
17:49:00 <moon-child> mjg: never!
17:50:00 <junon> so what's the difference between a socket and a file in unix? "everything is a file" oh okay so I can create a socket from the filesystem? "not anymore" why not? "lots of reasons, depends on who you ask" okay so if I create a socket in a program, can I write to it with write()? "not always" but I thought it was just a file "it is"
17:50:00 <moon-child> 'can create a socket from the filesystem? "not anymore"' ehh that's not really a problem
17:50:00 <zid> I don't find it particularly unusual that not all files are exactly the same, tbh
17:50:00 <zid> some files care about latency, some care about throughput even ignoring other things
17:50:00 <mjg> junon: ye, everyting is a file, except when it is not
17:50:00 <moon-child> filesystem is distinct from file. tain't plan9. Filesystem is just one way you can get files; obviously there are others
17:51:00 <moon-child> like, stdout is a file, but it might not be in the filesystem (before /proc)
17:51:00 <moon-child> ditto any pipe
17:51:00 <junon> . /dev/stdout is a file though (ignore the ., mirc is dumb)
17:51:00 <zid> As long as the /api/ is consistent in how it /acts/ on those files, I don't care
17:51:00 <zid> hold ctrl junon
17:51:00 <zid> like in every single application ever
17:51:00 <zid> trl
17:51:00 <junon> /test
17:51:00 <junon> thanks zig
17:51:00 <junon> zid
17:52:00 <zid> also / /blah works I believe
17:52:00 <zid> I don't think mirc is the dumb one here ngl :P
17:52:00 <mjg> oh?
17:52:00 <gog> /blah
17:52:00 <mjg> my entire life i was /msg #osdev crap
17:52:00 <mjg> does this owrk on irssi?
17:52:00 <moon-child> junon: ok, fine. but pipes. And idk if /dev/stdout was always a thing
17:52:00 <zid> /say probably also works
17:52:00 <moon-child> mjg: for irssi, do / /blabla
17:52:00 <moon-child> in weechat, it's one less keystroke: //blabla. :^)
17:52:00 <zid> I prefer ctrl
17:53:00 <junon> moon-child: we have /dev/tty# too
17:53:00 <zid> but that hits escape codes in terminals
17:53:00 <mjg> moon-child: nice
17:54:00 <moon-child> my POINT is there's no requirement that files exist on the fs. Like try this: touch x; tail -f x. And then in another terminal rm x
17:54:00 <junon> that file still exists on the FS though
17:54:00 <zid> files are just an opaque abstract object to perform a set of operations on like write and read
17:54:00 <zid> the semantics of those depend on what the other end does
17:54:00 <junon> tail's open fd still has a reference to x's inode
17:55:00 <moon-child> right
17:55:00 <zid> It's actually a problem, but not with unix's design
17:55:00 <moon-child> but from the view of filesystem as a hierarchical tree of pointers to files, it's nowhere
17:55:00 <moon-child> zid: ioctl be like
17:55:00 <junon> yeah
17:55:00 <junon> ioctl was the first nail in that coffin
17:55:00 <junon> well maybe not the first, but the first I know of
17:56:00 <moon-child> was it ioctl, or was it shared memory mappings?
17:56:00 <zid> The problem is that filesystems suck shit :p
17:56:00 <moon-child> cause shared memory is an _obvious_ sign that pipes were not enough for something. But idk which came first
17:56:00 <zid> They can't guarentee anything and have all sorts of races cus more than one file and more than one process is allowed to exist
17:56:00 <zid> Implementing ACID is basically impossible
17:56:00 <moon-child> zid: zfs :3
17:56:00 <mjg> man
17:57:00 <zid> I use sqlite instead of files
17:57:00 <mjg> what really sucks is the unix idiom of log rotation and whatnot
17:57:00 * moon-child wonders which of zfs and postgresql is the more reliable
17:57:00 <zid> because sqlite is basically just a library for making files that won't randomly corrupt as easily
17:57:00 <mjg> rename, send sighup... and how do you know when the daemon is done
17:57:00 <junon> modprobe sqlitefs
17:58:00 <moon-child> mjg: hmm, not up to date on that stuff but wouldn't it be better to pipe the log messages to a program that rotates on its own, auto-closing/moving/etc.?
17:58:00 <junon> mount -t sqlite /dev/sda1 /mnt && cat '/mnt/SELECT * FROM files WHERE name="hello.txt"'
17:58:00 <junon> could you imagine
17:59:00 <moon-child> seems kinda useless tbh
17:59:00 <moon-child> cause it doesn't compose with the rest of the system
17:59:00 <junon> that's never stopped anyone
17:59:00 <moon-child> so might as well just /usr/bin/sqlite3 /dev/sda1
17:59:00 <moon-child> like what's the advantage
17:59:00 <junon> can you do that?
17:59:00 <zid> sqlite doesn't work for certain kinds of files
18:00:00 <zid> Like, i don't want my movies in it
18:00:00 <moon-child> zid: why not?
18:00:00 <zid> why bother?
18:00:00 <zid> I'm writing them sequentially, once, and they're checksummed
18:00:00 <mjg> moon-child: well i'm curious what systemd is doing here
18:01:00 <mjg> moon-child: but ye, not having the file open but a pipe instead is one typical fix
18:01:00 <mjg> moon-child: the problem with it is spurious traffic for busy daemons
18:02:00 <moon-child> I think I heard systemd doesn't rotate, but has a custom binary format
18:02:00 <zid> sqlite's great for.. databasical info so that I don't have to write my own db routines, and great for small files that might change a bunch at runtime
18:02:00 <zid> like save games
18:02:00 <moon-child> (so since it's binary, easy to build indices and things to seek quickly)
18:02:00 <zid> firefox uses sqlite for your profile
18:06:00 <junon> Firefox also has ads in the address bar
18:07:00 <junon> https://twitter.com/ladyaeva/status/1445834339917320194
18:08:00 <moon-child> lmao nice
18:09:00 <junon> also I love her referring to people with custom distros as "arc linux install on death station 9000"
18:45:00 <ZetItUp> erm think i found why my code aint working, for some reason address 0x415-0x950 is filled with add %al, (%eax)
18:46:00 <mjg> that's 0's
18:46:00 <ZetItUp> ooh
19:03:00 <Bitweasil> Oh man. Yeah... you know you've been in the weeds too long when assembly and hex are halfway interchangeable.
19:11:00 <mjg> i only recognize a bunch
19:11:00 <mjg> 0 is kind of a special caes
19:26:00 <Oli> I am wondering about the name of any parser software with the concept of strictly enters processor opcodes and operands in binary notation directly, and labels to reference addresses, that may have been publicly released.
19:26:00 <clever> Bitweasil: i can spot a VPU function pre-amble just from looking at hexdumps....
19:28:00 <geist> yah nice job intel for not putting something more appropriate at opcode 0
19:29:00 <geist> even 8080 had a NOP there
19:29:00 <geist> https://pastraiser.com/cpu/i8080/i8080_opcodes.html
19:34:00 <Bitweasil> Seriously. 0x0 should be a NOP, or it should be a debug breakpoint or something.
19:34:00 <Bitweasil> If you're trying to execute it, you are *almost* certainly not doing what you intended.
19:34:00 <Bitweasil> 0x0: Play the Macerana on the PC speaker.
19:35:00 <clever> Bitweasil: pretty sure 0 is breakpoint on VPU
19:37:00 <Oli> 0x00: HCF
19:38:00 <Bitweasil> 0x00: NGGYU: Plays Never Gonna Give You Up on the CPU power supply inductors.
19:38:00 <clever> Bitweasil: heh, the inductors on one of my older laptops could maybe do that
19:38:00 <Oli> lol
19:39:00 <clever> junon: i have written a fuse sqlite fs in the past, was fairly simple
19:39:00 <clever> junon: the biggest flaw in my design, was that files where not using blocks, the ENTIRE contents of the file was in a single cell in a files table
19:39:00 <clever> but the goal was to deal with millions of tiny files
19:40:00 <geist> yah generally sane architectures at least make sure 0 does either nothing or something catastrophic
19:41:00 <geist> x86 is the only one i know off hand that doesn't.
19:41:00 <clever> the problem i was trying to solve with sqlite, is that i was actually running out of inodes before i ran out of free blocks on ext4, lol
19:41:00 <zid> I advocate that all architectures should make 00 and FF illegal instructions that fault.
19:41:00 <zid> fite me irl
19:41:00 <clever> zid: id rather join you :P
19:41:00 <Bitweasil> x86: "HAY GUYS LOOK WHAT I CAN DO!" "... seriously, stop blowing spit bubbles, I don't care if you can make them look like Mickey Mouse. That's disgusting."
19:42:00 <Bitweasil> I fully support those two being catastrophic.
19:42:00 <zid> The amount of bugs that become un-debuggable because 00 is valid is upsetting
19:42:00 <Oli> You reminded me of this article, about sending a music stream over radio frequencies produced by a processor executing instructions: https://archive.org/details/github.com-fulldecent-system-bus-radio_-_2018-01-19_00-13-51
19:42:00 <clever> Bitweasil: oh, did you hear about how an update system caused physical damage to printers?
19:42:00 <Bitweasil> Or at least "sit and spin."
19:42:00 <Bitweasil> Are we back to the LP: Printer on Fire thing? Or something different?
19:42:00 <clever> not fire, but physical damage
19:42:00 <geist> zid: i tend to think that way too. iirc arm64 does. though riscv does nop
19:42:00 <Bitweasil> Then no.
19:42:00 <clever> basically, the launcher for a game, would download /update.exe and run it
19:42:00 <clever> even if the server returned 404
19:43:00 <Bitweasil> ... uh.
19:43:00 <clever> if windows cant identify the header (its bloody html), it gets executed as a .com file via the dos subsystem
19:43:00 <Bitweasil> "Worry about it being down? That's inconceivable!" </Facebook>
19:43:00 <clever> that html, just happened to be the right opcodes for writing to the LPT port
19:43:00 <Bitweasil> I feel like this is a dumb idea, but.. OK...
19:43:00 <clever> windows they relayed those random bytes to the real printer over usb
19:44:00 <Bitweasil> Ok, we're at single facepalm...
19:44:00 <clever> and physically broke itself
19:44:00 <clever> the printer itself, didnt validate the commands, and began driving the stepper motors the wrong direction
19:44:00 <Bitweasil> ... and there's the double facepalm.
19:44:00 <clever> 1: check the http status code!
19:45:00 <clever> 2: if your .exe file contains html, dont run it via dos
19:45:00 <clever> 3: how did it even run on an x86 core???
19:45:00 <clever> 4: the printer should have validated the input
19:45:00 <Bitweasil> Do you have a link to a writeup on this anywhere?
19:46:00 <clever> one min
19:46:00 <clever> Bitweasil: https://nwn.blogs.com/nwn/2018/06/windows-second-life-yoz-linden-lab.html
19:48:00 <Bitweasil> Thanks... I'll share that around.
19:48:00 <Bitweasil> Man, aren't humans so good at computers??
19:56:00 <gog> i don't even know what computer is
19:57:00 <jimbzy> It's a thing that does stuff.
19:59:00 <Bitweasil> It's like that jerk who does *exactly what you said* - with the worst possible interpretation of it.
19:59:00 <Bitweasil> You say "turn right," he turns right immediately and walks into the wall.
21:40:00 <corecode> uh, doing 4 saturating 8-bit integer additions (rgbw pixel mixing) is oddly verbose in x86
21:41:00 <corecode> i guess doing 8-bit SIMD arithmetic isn't really a thing
21:41:00 <moon-child> p sure it is
21:41:00 <clever> corecode: the vector core on the rpi, has dedicated saturating and non-saturating modes fot a lot of its things
21:41:00 <moon-child> there are saturating instructions just for 8 and 16-bit
21:41:00 <moon-child> oh might be signed though. Then maybe easier to do it at higher precision and clamp
21:42:00 <moon-child> oh no, there's unsigned variants too. PADDUSB
21:46:00 <corecode> is that on x86?
21:47:00 <moon-child> yeah
21:48:00 <moon-child> also 'rgbw' bastard child of rgba and xyzw? :)
21:49:00 <corecode> no, it's for LED pixels
21:49:00 <corecode> it's basically the inverse of CMYK
21:51:00 <corecode> https://rust.godbolt.org/z/Wv4hxeasr
21:52:00 <corecode> look at this ridiculous code
21:53:00 <moon-child> ahh makes sense
21:56:00 <moon-child> anyway yeah paddusb is what you want
21:56:00 <corecode> yea but i don't know how to convince rustc to emit that
21:57:00 <moon-child> I never understood the fascination with getting compilers to emit specific sequences. People do the same with tail calls, writing pidgin threaded interpreters in c
21:57:00 <moon-child> if you care about what instructions get generated, write the whole loop in assembly
21:57:00 <moon-child> otherwise, what the compiler generates will be good enough adn don't waste your time on it
21:58:00 <corecode> i agree with the sentiment
21:59:00 <corecode> but where to stop
21:59:00 <corecode> there must be some expectation of what the compiler produces
21:59:00 <corecode> and if my expectation isn't met, it's maybe because i'm not phrasing it in a way the optimizer understands
22:00:00 <corecode> or maybe i need to use some (generic) intrinsics
22:02:00 <moon-child> intrinsics I don't like either :P
22:03:00 <moon-child> 'expectation of what the compiler produces' except when I am writing the compiler, my expectation is that the compiler will generate whatever code it cares to, and if that code is slow and--by judging from the assembly--I think I can do it faster myself, I do so
22:03:00 <corecode> i don't think that's realistic
22:04:00 <corecode> what if the compiler decides to create gigantic temporaries on the stack?
22:04:00 <corecode> or calls heap allocation functions?
22:04:00 <corecode> immediately fall back to asm?
22:07:00 <GreaseMonkey> if it creates gigantic temporaries on the stack it's probably because you declared some on there
22:07:00 <moon-child> I don't expect the compiler is _stupid_. If such cases occur, they will be the exception rather than the norm. (As well, how likely are such things occur but outside of inner loops you're fine~)
22:08:00 <GreaseMonkey> i've dealt with plenty of compiler stupidity when using GCC to compile code for a Cortex-M0+ but i've yet to see it be *that* stupid
22:08:00 <moon-child> gah, parenthesized sentence was garbled
22:09:00 <moon-child> should read something like: if such things occur but outside of inner loops, you're fine
22:12:00 <corecode> GreaseMonkey: what have you seen?
22:13:00 <GreaseMonkey> it usually boils down to the fact that GCC's Thumb-1 optimiser will never, ever, ever optimise a divide into a magic multiply, for any denominator that isn't a constant power of two it will ALWAYS defer to a software divide
22:13:00 <GreaseMonkey> but also there's a bug that had a fix for it several years ago in the mailing list that still hasn't been applied, where the cost of a multiply is estimated to be about the same as, in practice, apparently 12 instructions?
22:14:00 <moon-child> I have heard gcc is very bad at producing code for arches with strict alignment requirements
22:14:00 <GreaseMonkey> of course they managed to handle the case of an M0+ with a slow multiplier and they get the cost of that correct, but that's not the default
22:15:00 <GreaseMonkey> and lastly, the conversion to (S|U)XT(B|H) appears to be peephole-optimised, so any rearrangement of things will make what normally takes 1 instruction take 2 instructions instead (LSL #(8|16) \ (A|L)SR #(8|16))
22:15:00 <GreaseMonkey> oh yeah and sometimes it will push an extra temporary onto the stack just because it feels like pushing stuff onto the stack which is absolutely fantastic when you're writing an interrupt handler
22:16:00 <GreaseMonkey> as for GCC vs strict alignment requirements... it's actually not terribad
22:16:00 <GreaseMonkey> although newlib-nano using the slowest implementation of memcpy and memset it can come up with is really stupid
22:17:00 <GreaseMonkey> and if you're doing a C99-style structure initialisation, and you miss just one field from it? memset().
22:18:00 <GreaseMonkey> with that said... i wonder if GCC's RISC-V backend treats it as if it has strict alignment requirements, because hot damn are unaligned accesses on the FU740 slow
22:19:00 <GreaseMonkey> the handler for that is in OpenSBI which switches between M mode and the intended mode and reads or writes byte by byte
22:25:00 <geist> yah marking something as packed on riscv is really painful
22:25:00 <geist> even if it knows it's aligned it still basically does byte by byte
22:26:00 <geist> part of the problem there in my mind is the packed attribute is also overloaded with 'may be completely unaligned'
22:26:00 <geist> so marking a struct { uint32, uint32 } as packed also means assume it's unaligned, and thus the compiler will have a bad time with it
22:28:00 <geist> https://gcc.godbolt.org/z/5WP1eKojf ugh.
22:29:00 <geist> and clang does the same thing
22:41:00 <corecode> hehe
22:41:00 <corecode> so what's the solution here?
22:41:00 <corecode> i mean, this looks worse than 6052 code
22:41:00 <corecode> partially because there are more registers, but still