<geist>
you could run a yield instruction while you poll at least to make it easier on the cpu if it's hyperthreaded
h4zel has quit [Ping timeout: 245 seconds]
h4zel has joined #osdev
dude12312414 has joined #osdev
nvmd has quit [Quit: Later, nerds.]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
srjek|home has joined #osdev
mctpyt has quit [Ping timeout: 252 seconds]
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
freakazoid343 has quit [Ping timeout: 265 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
freakazoid12345 has joined #osdev
[itchyjunk] has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
<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...
<klange>
One of the last few hard requirements for ToaruOS 2, I think.
Oli has quit [Quit: leaving]
srjek|home has quit [Ping timeout: 245 seconds]
sts-q has joined #osdev
dutch has quit [Quit: WeeChat 3.3]
sdfgsdfgDropBear has joined #osdev
<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
<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.
<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...
<geist>
yah always seemed like a fun thing to implement
<geist>
something about driving real physical disks so you can actually hear it seeking (or not) because you improved your code
<geist>
SSDs take away all the fun
h4zel has quit [Ping timeout: 265 seconds]
Burgundy has joined #osdev
nostalgia has quit [Ping timeout: 245 seconds]
mahmutov has joined #osdev
Beato has quit [Quit: I have been discovered!]
mahmutov has quit [Ping timeout: 245 seconds]
Beato has joined #osdev
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
gorgonical has quit [Ping timeout: 252 seconds]
ElectronApps has joined #osdev
gorgonical has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
freakazoid12345 has quit [Ping timeout: 268 seconds]
andrewrk has quit [Ping timeout: 265 seconds]
andrewrk has joined #osdev
gorgonical has quit [Ping timeout: 245 seconds]
gorgonical has joined #osdev
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
sts-q has quit [Ping timeout: 265 seconds]
jjuran has quit [Read error: Connection reset by peer]
jjuran has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
junon has joined #osdev
sdfgsdfgDropBear has joined #osdev
elderK has quit [Quit: Connection closed for inactivity]
brettgilio7 has joined #osdev
brettgilio has quit [Ping timeout: 240 seconds]
brettgilio7 is now known as brettgilio
dennis95 has joined #osdev
nyah has joined #osdev
GeDaMo has joined #osdev
dormito has quit [Quit: WeeChat 3.1]
Arthuria has joined #osdev
pretty_dumm_guy has joined #osdev
dutch has joined #osdev
myon98 has quit [Quit: Bouncer maintainance...]
darkstardevx has quit [Ping timeout: 245 seconds]
darkstardevx has joined #osdev
Vercas3 has joined #osdev
Vercas has quit [Ping timeout: 276 seconds]
Vercas3 is now known as Vercas
Oli has joined #osdev
ahalaney has joined #osdev
NeoCron has joined #osdev
Oli has quit [Quit: Lost terminal]
Oli has joined #osdev
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
srjek|home has joined #osdev
Oli has quit [Quit: Lost terminal]
Oli has joined #osdev
[itchyjunk] has joined #osdev
ahalaney has quit [Quit: Leaving]
ahalaney has joined #osdev
ElectronApps has quit [Remote host closed the connection]
freakazoid343 has joined #osdev
jjuran has quit [Quit: jjuran]
jjuran has joined #osdev
jjuran has quit [Client Quit]
jjuran has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
ahalaney has quit [Remote host closed the connection]
opios2 has quit [Ping timeout: 252 seconds]
Arthuria has quit [Remote host closed the connection]
andrewrk has quit [Ping timeout: 245 seconds]
andrewrk has joined #osdev
ahalaney has joined #osdev
NeoCron has quit [Remote host closed the connection]
NeoCron has joined #osdev
Vercas6 has joined #osdev
eremitah has quit [Remote host closed the connection]
LittleFox has quit [Remote host closed the connection]
<zid>
no but I also basically disable all javascript
<ZetItUp>
hehe
<moon-child>
i have js on, scrolling is fine
<ZetItUp>
hmm
<zid>
Time to profile your browser
<zid>
chrome has a profiler built in at least
<junon>
ZetItUp it also feels weird to me
<junon>
not just you
<zid>
maybe it's the css sidepanel stuff
<zid>
messing with ya
<junon>
No it's jquery which always attaches listeners to pass them to its own listener set.
<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.
<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.
<moon-child>
man
<moon-child>
web is a fucking mess
<junon>
Yes. I hope it dies some day.
<ZetItUp>
junon will try that :D
<junon>
And in chrome at least you can click "remove" and see if it makes any difference.
<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
<ZetItUp>
yeah removing it solved it hehe
<Oli>
You have made me ponder about whether a responsive web site or operative system development are harder to pull in general.
<zid>
don't worry, web devs have almost finished reimplementing winapi
<zid>
so they're the same thing
<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.
<zid>
except the winapi is hosted on 14 other computers
<moon-child>
junon: yes, os development is pretty much the epitome of 'fuck it, I'll fix it myself'
<zid>
You don't want me to fix it, trust me
<zid>
"Why would anybody ever use this api anyway? *delete*"
<moon-child>
well, you get to fix your own shit
<moon-child>
I fix mine
<moon-child>
:)
<zid>
"Why would I have written this api? *delete*"
<junon>
ZetItUp: curious, does running this in the console also fix it (after a refresh)?: void(window.addEventListener('scroll',e=>e.stopImmediatePropagation(),true))
<moon-child>
junon: why void()
<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.
<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
<junon>
It basically means "discard the result of the expression and substitute `undefined` / do nothing"
<moon-child>
oh yes, web security model is bonkers
<junon>
Because in the old days, `javascript:somecode` would execute somecode and then set the result as the document's body, for some reason
<zid>
I miss those days
<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)
<ZetItUp>
junon: works like a charm :D
<junon>
glad to hear it :)
<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.
<junon>
I hate the web.
* junon
sashays back to writing Go for work
<moon-child>
I think I prefer js to go
<junon>
Go isn't a bad language, it's just a dumb language. The module system is bonkers though.
<zid>
bonkers badonkers
<junon>
I maintain too much JS to enjoy writing it these days.
<junon>
and TS is just Microsoft advertising in the form of a programming language.
<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
<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
<moon-child>
imo
<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)
<junon>
The only thing they screwed up with Java is unchecked exceptions IMO. Should have never existed.
<junon>
Go's error system is indeed confusing as hell.
<junon>
I'm still learning Go and that's something that even the experienced Go devs on my team struggle with.
<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
<junon>
I would be okay with a few reserved, language-level unchecked exceptions.
<junon>
But not user-defined ones.
<moon-child>
I mean, getting rid of null sounds like a pretty solid change to me... :)
<zid>
I want the whole language not to be user defined
<zid>
that's where the trouble starts
<zid>
letting people write their own expressions
<zid>
they start immediately taking the piss
<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.
* gog
throws up
<moon-child>
gog: :/
<gog>
i should have said "updog"
<zid>
hey upgog
<junon>
Java 8 and beyond did too much syntactically IMO. All the streams and arrow functions and stuff.
<junon>
Java 7 was probably the best version of Java. Generics were added and that was all the language needed IMO.
<gog>
what's upgog
<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".
<gog>
every programming language should support every kind of construct
<zid>
at the same time
<gog>
yes
<zid>
and none of them should interact cleanly
<mjg>
:)
<zid>
aka C++
<gog>
even more yes
<junon>
hEy HaVe yOu eVeR hEaRd oF mOnAdS?!!
<moon-child>
so basically unix
<mjg>
you take that back111
<gog>
that reads like a "bofa" joke
<gog>
bofa deez monads
<zid>
MONA DEEZ NUTS
<moon-child>
mjg: never!
<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"
<moon-child>
'can create a socket from the filesystem? "not anymore"' ehh that's not really a problem
<zid>
I don't find it particularly unusual that not all files are exactly the same, tbh
<zid>
some files care about latency, some care about throughput even ignoring other things
<mjg>
junon: ye, everyting is a file, except when it is not
<moon-child>
filesystem is distinct from file. tain't plan9. Filesystem is just one way you can get files; obviously there are others
k0valski has joined #osdev
<moon-child>
like, stdout is a file, but it might not be in the filesystem (before /proc)
<moon-child>
ditto any pipe
<junon>
. /dev/stdout is a file though (ignore the ., mirc is dumb)
<zid>
As long as the /api/ is consistent in how it /acts/ on those files, I don't care
<zid>
hold ctrl junon
<zid>
like in every single application ever
<zid>
trl
<junon>
/test
<junon>
thanks zig
<junon>
zid
<zid>
also / /blah works I believe
<zid>
I don't think mirc is the dumb one here ngl :P
<mjg>
oh?
<gog>
/blah
<mjg>
my entire life i was /msg #osdev crap
<mjg>
does this owrk on irssi?
<moon-child>
junon: ok, fine. but pipes. And idk if /dev/stdout was always a thing
<zid>
/say probably also works
<moon-child>
mjg: for irssi, do / /blabla
<moon-child>
in weechat, it's one less keystroke: //blabla. :^)
<zid>
I prefer ctrl
<junon>
moon-child: we have /dev/tty# too
<zid>
but that hits escape codes in terminals
<mjg>
moon-child: nice
<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
<junon>
that file still exists on the FS though
<zid>
files are just an opaque abstract object to perform a set of operations on like write and read
<zid>
the semantics of those depend on what the other end does
<junon>
tail's open fd still has a reference to x's inode
<moon-child>
right
<zid>
It's actually a problem, but not with unix's design
<moon-child>
but from the view of filesystem as a hierarchical tree of pointers to files, it's nowhere
<moon-child>
zid: ioctl be like
<junon>
yeah
<junon>
ioctl was the first nail in that coffin
<junon>
well maybe not the first, but the first I know of
<moon-child>
was it ioctl, or was it shared memory mappings?
<zid>
The problem is that filesystems suck shit :p
<moon-child>
cause shared memory is an _obvious_ sign that pipes were not enough for something. But idk which came first
<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
<zid>
Implementing ACID is basically impossible
<moon-child>
zid: zfs :3
<mjg>
man
Kartikeya has quit [Ping timeout: 245 seconds]
<zid>
I use sqlite instead of files
<mjg>
what really sucks is the unix idiom of log rotation and whatnot
* moon-child
wonders which of zfs and postgresql is the more reliable
<zid>
because sqlite is basically just a library for making files that won't randomly corrupt as easily
<mjg>
rename, send sighup... and how do you know when the daemon is done
<junon>
modprobe sqlitefs
<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.?
<junon>
mount -t sqlite /dev/sda1 /mnt && cat '/mnt/SELECT * FROM files WHERE name="hello.txt"'
<junon>
could you imagine
<moon-child>
seems kinda useless tbh
<moon-child>
cause it doesn't compose with the rest of the system
<junon>
that's never stopped anyone
<moon-child>
so might as well just /usr/bin/sqlite3 /dev/sda1
<moon-child>
like what's the advantage
<junon>
can you do that?
<zid>
sqlite doesn't work for certain kinds of files
<zid>
Like, i don't want my movies in it
<moon-child>
zid: why not?
<zid>
why bother?
<zid>
I'm writing them sequentially, once, and they're checksummed
<mjg>
moon-child: well i'm curious what systemd is doing here
sprock has joined #osdev
<mjg>
moon-child: but ye, not having the file open but a pipe instead is one typical fix
<mjg>
moon-child: the problem with it is spurious traffic for busy daemons
<moon-child>
I think I heard systemd doesn't rotate, but has a custom binary format
<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
<zid>
like save games
<moon-child>
(so since it's binary, easy to build indices and things to seek quickly)
<junon>
also I love her referring to people with custom distros as "arc linux install on death station 9000"
Kartikeya has joined #osdev
srjek|home has quit [Ping timeout: 265 seconds]
<ZetItUp>
erm think i found why my code aint working, for some reason address 0x415-0x950 is filled with add %al, (%eax)
<mjg>
that's 0's
<ZetItUp>
ooh
<Bitweasil>
Oh man. Yeah... you know you've been in the weeds too long when assembly and hex are halfway interchangeable.
<mjg>
i only recognize a bunch
<mjg>
0 is kind of a special caes
<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.
<clever>
Bitweasil: i can spot a VPU function pre-amble just from looking at hexdumps....
<geist>
yah nice job intel for not putting something more appropriate at opcode 0
<Bitweasil>
Seriously. 0x0 should be a NOP, or it should be a debug breakpoint or something.
<Bitweasil>
If you're trying to execute it, you are *almost* certainly not doing what you intended.
<Bitweasil>
0x0: Play the Macerana on the PC speaker.
<clever>
Bitweasil: pretty sure 0 is breakpoint on VPU
<Oli>
0x00: HCF
<Bitweasil>
0x00: NGGYU: Plays Never Gonna Give You Up on the CPU power supply inductors.
<clever>
Bitweasil: heh, the inductors on one of my older laptops could maybe do that
<Oli>
lol
<clever>
junon: i have written a fuse sqlite fs in the past, was fairly simple
<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
<clever>
but the goal was to deal with millions of tiny files
<geist>
yah generally sane architectures at least make sure 0 does either nothing or something catastrophic
<geist>
x86 is the only one i know off hand that doesn't.
<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
<zid>
I advocate that all architectures should make 00 and FF illegal instructions that fault.
<zid>
fite me irl
<clever>
zid: id rather join you :P
<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."
<Bitweasil>
I fully support those two being catastrophic.
<zid>
The amount of bugs that become un-debuggable because 00 is valid is upsetting
<corecode>
yea but i don't know how to convince rustc to emit that
<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
<moon-child>
if you care about what instructions get generated, write the whole loop in assembly
<moon-child>
otherwise, what the compiler generates will be good enough adn don't waste your time on it
<corecode>
i agree with the sentiment
<corecode>
but where to stop
<corecode>
there must be some expectation of what the compiler produces
dormito has joined #osdev
<corecode>
and if my expectation isn't met, it's maybe because i'm not phrasing it in a way the optimizer understands
<corecode>
or maybe i need to use some (generic) intrinsics
ahalaney has quit [Remote host closed the connection]
<moon-child>
intrinsics I don't like either :P
<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
<corecode>
i don't think that's realistic
<corecode>
what if the compiler decides to create gigantic temporaries on the stack?
<corecode>
or calls heap allocation functions?
<corecode>
immediately fall back to asm?
<GreaseMonkey>
if it creates gigantic temporaries on the stack it's probably because you declared some on there
<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~)
<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
<moon-child>
gah, parenthesized sentence was garbled
<moon-child>
should read something like: if such things occur but outside of inner loops, you're fine
Burgundy has quit [Ping timeout: 245 seconds]
<corecode>
GreaseMonkey: what have you seen?
<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
<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?
<moon-child>
I have heard gcc is very bad at producing code for arches with strict alignment requirements
<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
<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))
<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
<GreaseMonkey>
as for GCC vs strict alignment requirements... it's actually not terribad
<GreaseMonkey>
although newlib-nano using the slowest implementation of memcpy and memset it can come up with is really stupid
<GreaseMonkey>
and if you're doing a C99-style structure initialisation, and you miss just one field from it? memset().
<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
<GreaseMonkey>
the handler for that is in OpenSBI which switches between M mode and the intended mode and reads or writes byte by byte
LostFrog has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<geist>
yah marking something as packed on riscv is really painful
<geist>
even if it knows it's aligned it still basically does byte by byte
<geist>
part of the problem there in my mind is the packed attribute is also overloaded with 'may be completely unaligned'
<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