<clever>
heat_: i would assume that relies on the host understanding a repeated in/out?
<clever>
ive heard mention of not using vectorized load/store against trapped mmio before
vdamewood has quit [Quit: Life beckons]
<heat_>
yeah but KVM at least handles this specifically
<heat_>
whereas SIMD against MMIO will lead to a crash
<moon-child>
o.o
Matt|home has joined #osdev
Ram-Z has quit [Ping timeout: 258 seconds]
<zid>
I take it you basically have to be prepared to emulate 'everything' to never have virt crash/fail
<zid>
The hardware is just there to accelerate it when possible
Ram-Z has joined #osdev
Ram-Z has quit [Remote host closed the connection]
Ram-Z has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
<heat_>
i don't think so
<heat_>
bad instruction = #UD in the virtualized ring 0, i don't believe there's a vm exit for that
<zid>
you could wire your #ud handler to intentionally vmexit if you wanted, but I'm not sure why you're bringing it up
<heat_>
i thought that's what you meant by "everything"
<zid>
I mean in order to *never* have kvm 'fail'
<zid>
You *must* provide a full software emulation of x86
[Kalisto] has quit [Quit: No' vemo']
<zid>
the hardware is *only* there to accelerate
<zid>
not to implement
<zid>
if it vmexits on an avx-512febityzx instruction writing to an mmio addr, you need to be able to complete it in software
<heat_>
right, but that is always a vmexit, independently of the instruction
<moon-child>
now I'm curious
<heat_>
because MMIO is fake memory
<zid>
yes but you want to complete it
<zid>
not fail
<heat_>
and the matter of fact is that KVM does not do it because fuck that
<zid>
It was literally the first thing I said
<moon-child>
if you try to execute an instruction spanning two pages and the second one got swapped out, what's the faulting address? First byte of the second page?
<zid>
It's "shut your mouth"
<heat_>
and lots of instructions are really poorly defined on weird caching
<heat_>
like IIRC cmpxchg on UC (uncacheable) memory just always writes
<heat_>
moon-child, yep
[Kalisto] has joined #osdev
[Kalisto] has quit [Client Quit]
<heat_>
moon-child, and really thank fuck you do not have to decode instructions to find out what to fault in
[Kalisto] has joined #osdev
<moon-child>
yeah
rpnx has joined #osdev
[itchyjunk] has joined #osdev
qubasa has quit [Ping timeout: 258 seconds]
gbowne1 has joined #osdev
<heat_>
so i've just looked at arm64 memory ordering on device memory
<heat_>
huge yikes
kof123 has joined #osdev
goliath has quit [Quit: SIGSEGV]
heat_ has quit [Ping timeout: 260 seconds]
dude12312414 has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
rpnx has quit [Quit: My laptop has gone to sleep.]
sbalmos has quit [Ping timeout: 252 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
sbalmos has joined #osdev
PapaFrog has quit [Ping timeout: 240 seconds]
PapaFrog has joined #osdev
gabi-250_ has quit [Remote host closed the connection]
gabi-250_ has joined #osdev
mkwrz has quit [Ping timeout: 252 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
mkwrz has joined #osdev
<geist>
having fun rebuilding the 2.11 BSD kernel on the PDP-11
<geist>
definitely taking a while
<geist>
though the kernel is also appropriately smaller, so it's not a ridiculous amount of code to compile
Matt|home has quit [Remote host closed the connection]
rpnx has joined #osdev
<kazinsal>
oh nice
<kazinsal>
picked up some new hardware?
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
Burgundy has joined #osdev
qaqekco has joined #osdev
bliminse has quit [Quit: leaving]
vai has joined #osdev
elastic_dog has quit [Ping timeout: 260 seconds]
k0valski1889162 has joined #osdev
elastic_dog has joined #osdev
gabi-250_ has quit [Remote host closed the connection]
gabi-250_ has joined #osdev
Burgundy has quit [Ping timeout: 264 seconds]
bliminse has joined #osdev
antranigv has quit [Ping timeout: 258 seconds]
<vaxuser>
geist: does this ship with time(1)?
antranigv has joined #osdev
GeDaMo has joined #osdev
rpnx has quit [Quit: My laptop has gone to sleep.]
<ice_>
[12:33:30 PM] <My-Bad> Here're my log files and interrupt source. I'm unable to figure out what's wrong with it. The wiki also doesn't have much to say about it
My-Bad has quit [Quit: Client closed]
valshaped7424880 has joined #osdev
ice_ has quit [Quit: leaving]
joe9 has joined #osdev
gog has quit [Quit: Konversation terminated!]
xenos1984 has quit [Ping timeout: 258 seconds]
xenos1984 has joined #osdev
Turn_Left has quit [Ping timeout: 272 seconds]
gog has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Gooberpatrol66 has quit [Ping timeout: 252 seconds]
<zid>
"RISC-V isn't killing ARM (yet)" so much optimism
<zid>
it makes my sick
<netbsduser>
i would like to learn more about risc-v but the risc-v advocates i've spoken to have such a haughty and imperious manner which ill befits any civilised discussion
<moon-child>
RISC
<moon-child>
RISC
<moon-child>
RISC
<moon-child>
RISC
<moon-child>
RISC
<heat>
i had a debate with a guy in #riscv that said a helper instructions for individual crypto algorithms is super RISC
<netbsduser>
their hubristic terming of everything that isn't risc-v as "legacy architectures" for one
<heat>
based on some take from some guy in the 90s
<heat>
netbsduser, hey you should try looking at the ISA docs!
<moon-child>
'risc' is a meaningless term now
<heat>
they're the weirdest arch docs I've ever read
<Bitweasil>
Yeah, I believe they're fairly accessible, as far as ISA docs go.
<zid>
heat: entire_program t0, t1, t2
<heat>
i would say weird, but yes also accessible :)
<zid>
risciest cpu ever
<netbsduser>
heat: i have heard they are very terse
<netbsduser>
while i was complaining about how verbose the ARM ARM is someone said riscv's are the total opposite
<moon-child>
i would rather have more detail than not be sure what they mean
Turn_Left has joined #osdev
<heat>
but ARM ARM is too fucking much
<heat>
you're swimming in meaningless details when you just want to find out how to configure the MMU
<zid>
I like intel's manual style
<zid>
where yes, everything is in there 4 times
<zid>
but it means they can write various chapters like a story
<zid>
"this is how protection works"
<zid>
even though they have a chapter on control registers elsewhere that also describes most of it, you don't have to piece it together from that
<heat>
intel is fine, but I think I prefer AMD's style
<heat>
I just find it easier to read for some reason
<moon-child>
'The motivation is to avoid the need for an instruction which reads 5 registers, but this is likely to impose less overhead on the implementation than the guaranteed-forward-progress LR/SC which is provided to replace it' it's good to know that, not only did they fuck up, but they also fucked up
flom84 has joined #osdev
<moon-child>
'Atomic instructions are provided which operate on 32-bit and 64-bit quantities, but not 8 or 16-bit' wait seriously
flom84 has quit [Remote host closed the connection]
<moon-child>
ooof
Turn_Left has quit [Ping timeout: 264 seconds]
<zid>
you can tell risc-v code by eye because it's about 40% longer than you were expecting
<moon-child>
I did hear that riscv-c has pretty good density bytes-wise
<moon-child>
but uh
<heat>
you don't get it zid, it's faster because it's RISC
<zid>
ohh right, sorry
<moon-child>
apparently it sucks to implement so the people implementing big cores don't
<heat>
and, you know, microcode and instructions with inputs and outputs
<heat>
CISC!
<moon-child>
i hate when instructions have inputs and outputs!
<moon-child>
instructions should only have inputs, no outputs. Then they could all run infinitely fast
<heat>
what if we had an implicit output register?
<heat>
some sort of flags
<zid>
imagine having ADC
xenos1984 has quit [Ping timeout: 245 seconds]
<heat>
fwiw i'm pretty sure it's possible to build a fast riscv core, but you need to macro-op fuse the shit out of code
<zid>
yea it's ofc possible
<zid>
bad encodings can be worked around
<zid>
the question is just *how hard is it going to be*
<heat>
and that probably relies on having well defined code patterns
<zid>
and the answer for risc-v is "incredibly"
<heat>
yeah, we'll see
<zid>
so it's going to take a lot of R&D and a lot of silicon to get it fast
<zid>
doesn't really matter if the ISA is compatible with 7 cent micros, if it costs a billion dollars of R&D to make it as fast as 7 cents worth of tose little write-once micros
<netbsduser>
heat: i started off an aarch64 port of my kernel but didn't advance it any further for that reason
<netbsduser>
consulting the arm arm is painful compared to consulting other references
<Bitweasil>
It's an acquired read, just like most others.
<acidx>
Acquired Read Manual, yes
<moon-child>
one thing I will say is
<netbsduser>
patriotism demands i celebrate arm and pray for the intercession of sophie wilson, but the price is too dear
<moon-child>
when I have to search it, I say ^f whatever enter, and then go make some coffee
<netbsduser>
porting to the 68040/060 was much more fun
<moon-child>
zid: i mean, if they could make x86 fast...
<zid>
moon-child: x86 is designed to at least be a little fast
<zid>
[esi+eax*4] exists, 'call' exists, etc
<moon-child>
x86 was designed to be fast like 40 years ago
<acidx>
x86 is fast the same way that a beetle with a jet engine is fast
<zid>
you can just throw braindead amounts of silicon in braindead ways to make x86 fast
<zid>
making risc-v fast is going to require very complicated trickery
<moon-child>
??
<moon-child>
what makes you think so
<moon-child>
see e.g. the shit they do with x86 decoders
<heat>
because at its core is a very simple load-store architecture with an ALU
<moon-child>
heat: then so is riscv
<heat>
i am talking about riscv here
<heat>
and it's *bad*, not good
<heat>
1) there's an insane amount of fragmentation in extensions
<heat>
2) riscv codegen is a lot larger than arm64 or x86
<moon-child>
I'm not saying riscv is good. All I'm saying is I'm not at all convinced that riscv cpus would be slower than x86 if they got the $billions of intel r&d that x86 got
<heat>
i think they would at least be a little slower due to the problem being inherently harder to solve for riscv
<moon-child>
x86 has tso to deal with
<zid>
they wouldn't, necessarily
<zid>
but x86 doesn't require billions to be 80% as fast as it is
<zid>
risc *needs* those billions, to be fast
<zid>
x86 is fast in braindead ways, "add this big barrel shifter", "make this complex op go in 1 cycle"
<zid>
risc-v needs meta-tricks to be fast, "Fuse these 4 operations"
<heat>
moon-child, i'm not sure if tso is baggage
<moon-child>
zid: riscv is fast in braindead ways 'decode 8 instructions in parallel and then run 8 instructions in parallel'
<zid>
ah, vliw, that's always worked well yes
<heat>
riscv cannot do that moon-child
<moon-child>
????
<moon-child>
superscalar is responsible for quite a lot of your performance
<heat>
instructions are variable length with the C extension :)
<moon-child>
heat: why is tso baggage?
<moon-child>
err
<moon-child>
why is it not baggage?
<moon-child>
heat: see my message above re C
<heat>
what message?
<zid>
it's also just not very practical in reality, if things hit 1 cycle per instruction, you now need to care about deps, and that's immediately out of the window with risc
<zid>
as every op is going target the same reg
<heat>
You can't decode 8 insns in parallel if you don't even know the size
<zid>
cus you'll be doing like "Implementing adc using 20 instructions" constantly
<zid>
so they need *fusing*, not pipelining
<moon-child>
<moon-child> I did hear that riscv-c has pretty good density bytes-wise <moon-child> but uh <moon-child> apparently it sucks to implement so the people implementing big cores don't
<moon-child>
that said, c is a lot faster to decode in parallel than x86
<heat>
moon-child, re: tso, I find that TSO usually ends up saving you memory barriers you'd eventually need in any case, for atomic sequences
xenos1984 has joined #osdev
<moon-child>
heat: most code isn't doing coordination though
<heat>
also, fwiw most cores do implement c
<heat>
that's the default compiler target at least
<heat>
rv64gc
<zid>
which version of avx512 does it have
<moon-child>
still, I'd _much_ rather decode riscv-c than x86
<moon-child>
zid: riscv has exactly zero avxes :(
<zid>
ofc
<heat>
yeah but you can't do silly decoding tricks, unlike arm64
<zid>
you get to save a few thousand transistors on decoder, woo
<zid>
now enjoy adding 40 million op fuse transistors
<heat>
and also THEY DO NOT DO UNALIGNED ACCESSES
<heat>
fucking hell!!
<moon-child>
wait what I thought it was the opposite
<moon-child>
they say you can always do unaligned access, so on small cores it gets trapped
<zid>
all accesses MUST be unaligned?
<heat>
i think the trapped stuff was dropped in newer specs?
<heat>
and in any case trapping for unaligned access handling in automagic M mode is so fucking useless it's not even funny
<moon-child>
yeah
<heat>
i think riscv is a bizarre case of dual personality where it cannot decide if it wants to be a super ez to implement, simple embedded core or a big chonky server boi
<zid>
that's because it's true
<zid>
and it's not bizarre it's just stupid
<heat>
so you get everything in tiny little extensions, gl-esque
<zid>
"free teaching ISA! It's intentionally overly-simple so we can teach it in every course! cpu design, compiler design, assembly, etc"
<zid>
"ooh free, let's make those"
<zid>
and here we are
<heat>
and certain useful stuff that's inconsequential for big cores (like unaligned accesses) need to necessarily get dropped from the base ISA, just so nvidia and western digital can shove more riscv into their shit
<moon-child>
I mean
<moon-child>
the cost of an arm license probably doesn't matter as much for big cores with bigger margins
<moon-child>
so probably in practice it carves out a nice harmless niche in embedded and that's it
<nortti>
isn't ARM getting more restrictive with its architecture licenses?
<sham1>
Stop doing unaligned accesses FFS
<heat>
unaligned accesses are great for things like memcpy and memset
<sham1>
They're also pessimal
<heat>
barely
<sham1>
It's also undefined behaviour
<zid>
only if it's UD
<heat>
it's more optimal to do an unaligned access than to branch
<zid>
It's often defined by the platform, for obvious reasons
Turn_Left has joined #osdev
kpel has joined #osdev
kpel has quit [Client Quit]
Turn_Left has quit [Ping timeout: 264 seconds]
<err>
²Â/window 2
<err>
eh sorry
<geist>
kazinsal: oh yeah you missed that i got a large haul of vax equipment
<geist>
well DEC hardware
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
pretty_dumm_guy has joined #osdev
elastic_dog has quit [Ping timeout: 255 seconds]
<heat>
geist, yo what's fence.tso for? x86 emulation?
<geist>
it's a new arm thing?
<geist>
on riscv? yeah i dunno precisely
<heat>
yeah riscv
<geist>
i dont understand the whole tso push there except as you say something about x86
<heat>
everyone wants rosetta? :)
<geist>
it's an extension and not in any of the RVAs though
<geist>
well, it does make some sense. first thing to get people onto a new arch is emulate x86
<heat>
>RV64I is the mandatory base ISA for RVA22S64, including mandatory fence.tso, and is little-endian.
<heat>
>Later versions of the RV64I unprivileged ISA specification ratified in 2021 made clear that fence.tso is mandatory.
<geist>
oh okay never mind then
<geist>
i guess i should go read that more closely
<geist>
how that fits in with the other fence variants
elastic_dog has joined #osdev
<heat>
geist, btw here's a funny arm detail: "There is however no guarantee about ordering between memory accesses to different devices, or usually between accesses of different memory types."
<heat>
you need barriers around mmio :^
<geist>
absolutely, that's why you have to insert barriers there
<geist>
that's correct
<Ermine>
I may be wrong, but feels like numa moment
<geist>
there are complex rules there about multiple busses having outstanding transactions, and without a barrier the cpu will not sync between them
<Ermine>
Well, mmio. I'm wrong
<Ermine>
And you don't need those barriers on e.g. x86?
<heat>
x86 is always strongly ordered there
<geist>
right. x86 is just strongly ordered eveyrwhere, much to the expense of the hardware needed to implement that
<heat>
someone in EDK2 found a bug where 1) you write to the PCIe ECAM enabling memory accesses 2) you read to some of that device's memory and it failed
Turn_Left has joined #osdev
<geist>
ARM is more like 'hey that's diminishing returns for hardware to implement it, so here's a pile of complex rules and tools software can use to make a more optimal solution'
<geist>
yes, that's precisely the sort of thing where you have to add a barrier
<geist>
usual rule is if you read/write a bunch of stuff to a device, you should either insert a barrier after every write (which basically turns it from device -> strongly ordered) or you should barrier when you're 'done'
<heat>
they have barriers, but they're only a dsb st before the store and dsb ld after the load
<geist>
because there's no guarantee that any other device is on the same AXI bus and is ordered relative to it
<heat>
so it only offers what essentially is TSO
<geist>
yeah, and i should be more precise about which barrier, etc.
<heat>
#define mmio_hw_mb() __asm__ volatile("dmb sy" : : : "memory") <-- isn't this just too much?
<geist>
but the canonical exampe is pretty much the sme as your PCI example: take an IRQ for a device, write to the device's register acking the level triggered IRQ, then going to the interrupt controller and unmasking the IRQ< or something like
<geist>
well, not particularly, that's about what you need
<heat>
why not just a st?
<geist>
you might be able to do a st or ld there depending, but dsb sy is pretty solid
<heat>
or oshst
<geist>
definitely not osh
<geist>
it has to be sy level, since we're talking about devices
<heat>
linux does oshst and ishld though?
<heat>
sorry, oshld
<geist>
depends. shit i dunno man
<geist>
like, i'd have to page all that back in. my head is deep in riscv and PDP-11 right now :)
<geist>
i can only hold about 1.5 architectures in my head at a time :)
<heat>
heh :D
<geist>
but.... dsb sy is sufficient if overkill
<heat>
yeah dsb sy is always ok
<geist>
keep in mid that a lot of the lesser fences frequently get updated to dsb sy inside the cpu
<geist>
i think that's always allowed. the arch allows for finer grained stuff, but the implementation doesn't have to implement all the levels
<geist>
so i think things like corex-a53 just elevates everything to full barrier, iirc
<geist>
(making it even harder to test)
<heat>
yeah
<heat>
the cortex-a53 is the best core ever
<heat>
particularly all the errata :)
<geist>
but indeed over the last 10 years i've observed armv8 turn into the most complex architecture known to man
<heat>
LATE STAGE RISC!
<Ermine>
I think bunch of phones use it
<geist>
at least i 'grew up' with it, so i can still generally follow along, but it's harder and harder to recommend it to newbies
<heat>
Ermine, all of em
<geist>
since goddamn it's getting ridiculous
<vaxuser>
c++ of cpus?
<geist>
kinda, yeah
<heat>
is riscv the rust of architectures?
<Ermine>
does armv9 help?
<vaxuser>
note armv8 (and whatever comes next) are here to stay
<geist>
and yeah i went ahead and said it. i think i'd been generally bullish on ARM up until this exact moment when the bit flipped in my head
<vaxuser>
so one has to learn that shit
<vaxuser>
's on my todo :(
<heat>
Ermine, armv9 is armv8 with a feature set
<geist>
you feel a disturbance in the force
<Ermine>
:(
<geist>
i think that's my brain flipping the bit
<geist>
armv9 == armv8.5 + SVE (basically)
<GeDaMo>
Will armv9 be followed by armv10 or armva? :|
<zid>
arm512
<sham1>
So what would be the Haskell of ISAs
<zid>
then arm10
<heat>
is SPARC the java of ISAs?
<geist>
i think it's after working with riscv, which is like arm 10-15 years ago. it's fun an refrsching because it's so simple, but the dark side is as real complicated implementations come along it's highly underspecified
<sham1>
SPARC died, Java didn't
<Ermine>
what is elbrus then?
<geist>
so you start to get a lot of 'what the hell is this thing doing'
<vaxuser>
is tiktok the bsd of lolipops?
<heat>
geist, yep, i feel you
<heat>
sfence.vma moment
<geist>
but coming off arm it's not bad, because you already have the general knowledge of how cpus work, because to get good at armv8 you have to really think like a cpu designer
<geist>
and then you can fairly easily apply that knowledge to something like riscv, even if they dont spec it you can suss what it's doing
<heat>
except when they fuckin CACHE NON PRESENT TLB ENTRIES
<geist>
yeah that i need to ask sifive about
<geist>
i finally got an account on their JIRA the other day, so if there's anyone there left that wasn't laid off, i'm going to ask that precisely. thanks for reminding me
<heat>
do sifive cores do the same?
<geist>
thats where i observed it
<Ermine>
and trapping to firmware
<geist>
on both u75 and <redacted>
<heat>
wasn't it on the visionfive?
<geist>
u74
<heat>
guess not
<geist>
VF2 is a u74-mc
<geist>
but i also see it on <redacted>
<heat>
oh
<geist>
a newer core from them
<heat>
darn REDACTED
<geist>
the sifive designs are nice and clean and simple, so i really have nothing to complain about, but their docs are a little terse
<Ermine>
heat: you need O4 access level for that
<geist>
especially stuff like TLB maintenance they literally just copy/paste from the riscv spec
<heat>
you know, it really makes no sense as to why one would cache such a thing
<heat>
page fault optimization?
<heat>
confusing
<geist>
yeah my theory is the MMU translate unit has essentially a one entry cache and when you exit the PF and retry it already is latched and loaded
<geist>
so it just restarts the previous lookup
<heat>
maybe their TLB really is borked yeah
<heat>
what if it's related to pt walks?
joe9 has quit [Quit: leaving]
<geist>
think of it as there is a piece of hardware that's doing TLB translations every time it does a memory access
<geist>
and if it fails (TLB miss) it goes over and engages one of N page walkers to deal with it
<heat>
like it needs to know you changed the page tables so their cached thing doesn't fall over with a non-present PTE somewhere
<geist>
and if that fails, PF. fine. but if at the start of the PF the page walker hasn't cleared any state
<geist>
then if you dont sfence.vma (which would clear it) then after you exit the PF and restart, if there weren't any other TLB misses in the interim the walker starts, and sees that it already has the VMA loaded up and it just repeats the same answer
<geist>
without refreshing the walk
<geist>
so not really like a L0 walk, but kinda like one
<geist>
er L0 cache
<heat>
yeah i understand
<geist>
perhaps as an optimization for sequential TLB misses: the walker already stores it's state of how it got there, and can bump forward to the next entry
<heat>
are memory accesses usually sequential?
<geist>
but a sfence.vma tosses the state of the walker. so its like a cheesy page table cache
<geist>
probably a large amount, sure. kike copying a bunch of date
<heat>
i've never measured that, but i'd assume they would tend to be more random
<geist>
data
<geist>
seems like a 'free' optimization. basically just keeping the cursor active in case the next fetch is sequential
<geist>
but note all of this is totally fine, the architecture says quite specifically if you futz with the page table you run sfence.vma on the address because the 'sfence' instruction is worded that way because its generic
<geist>
ie, you're synchronizing the cpu and the page tables, not explicitly dumping the TLB
<geist>
the big question is do you have to broadcast sfence to the other cores right then too. i think the answer is no *except* you might get a spurious PF. which is generally okay..... unless it's in the kernel
<geist>
so that's a real question i have to answer
<heat>
yeah linux does it lazily over the various other cores
<heat>
and as for the kernel... you probably want to sync those up, depends on what you're mapping really. if you can survive a page fault entry into a sfence.vma
<heat>
if it's a stack or core data structures you really are risking it :/
Gooberpatrol66 has joined #osdev
Burgundy has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
heat has quit [Remote host closed the connection]
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
heat has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
xenos1984 has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
<gog>
hi
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
Turn_Left has quit [Remote host closed the connection]
pretty_dumm_guy has quit [Ping timeout: 255 seconds]
Turn_Left has joined #osdev
gbowne1 has joined #osdev
pretty_dumm_guy has joined #osdev
<Ermine>
gog: may I pet you
<gog>
yes
<vaxuser>
ey ggos
<vaxuser>
may i *not* pet you
heat has quit [Remote host closed the connection]
qookie has quit [Ping timeout: 240 seconds]
heat has joined #osdev
qookie has joined #osdev
<heat>
vaxuser, may i pet you?
<vaxuser>
no mate
<vaxuser>
don't want pedo charges
* zid
rubs heat but backwards
<zid>
AGAINST THE GRAIN BABY
* vaxuser
pats heat on the back
Turn_Left has quit [Ping timeout: 240 seconds]
Turn_Left has joined #osdev
<gog>
vaxuser: you may not not pet me
Turn_Left has quit [Max SendQ exceeded]
<vaxuser>
this is petual harassment
<moon-child>
is it may (not pet) or (may not) pet
Turn_Left has joined #osdev
* gog
meows loudly
* moon-child
pets gog
* gog
prr
<heat>
vaxuser, good i wasn't going to pet you anyways lmao
<heat>
get fucked
<vaxuser>
23:09 < heat> get fucked
<heat>
<vaxuser> 23:09 < heat> get fucked
<vaxuser>
again, heat, not only you are not my type, but you are in the wrong age bracket
<heat>
what's your type? BSD users?
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
ppmathis has quit [Quit: Ping timeout (120 seconds)]
ppmathis has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
Turn_Left has joined #osdev
<vaxuser>
heat: female compiler writers
<vaxuser>
here is a pro tip: don't get a gf from anything it-related :X
<heat>
i know
<heat>
you don't want to find out that the "love of your life" writes C#
<heat>
yikes, c ya
<vaxuser>
"love of your life" is such a high school concept
<heat>
it would be very on brand for you to say love doesn't exist
<moon-child>
vaxuser you told us you were a fellow kid
<heat>
or that love is pessimal
<moon-child>
are you not actually in high school??
<vaxuser>
of course i am, fellow kids
<vaxuser>
heat: it does, it just sucks in the long run
<vaxuser>
:X
<heat>
>30+ year old man posing as a kid
<klange>
how do you do fellow kids
<heat>
what's the polish equivalent of the FBI?
<heat>
hi klange
<heat>
how are you?
<klange>
old
<vaxuser>
are you the teacher
<heat>
aw, get better!
<klange>
i'm afraid there's no recovering from old, it's fatal
<vaxuser>
got midlife crisis yet?
<vaxuser>
or are you post that
<zid>
You're the youngest you will ever be
<zid>
It's all downhill from here, every day
<zid>
forever
<heat>
life is always downhill isn't it?
<zid>
no way
<zid>
but it's a step function
<moon-child>
zid: joke's on you, I haven't reached my prime yet
<zid>
someone good dies? +2.0
<klange>
it's uphill both ways in the snow
<vaxuser>
well there is still more than you already lived, up until around mid of your life expectancy
<zid>
find £20 in the carpark? +1.0
<zid>
it doesn't gradually rise over time, then plateau
<heat>
i yearn for the innocence of idk, being a 5 year old
<vaxuser>
klange: more importantly, life sucks and then you die
<zid>
life starts pretty bad, you cry all the time, but you get birthday presents and stuff
<zid>
and then people stop caring and you decline back to 0
<heat>
>you cry all the time, but you get birthday presents and stuff
<heat>
i see that as an absolute win
<zid>
you cry all the time now right, so the difference between being 5 and being 25 is that you get birthday presents when you're 5
<zid>
ergo you're on the decline
<moon-child>
i got you a birthday present!
<gog>
i write c#
<gog>
:<
<heat>
i still get birthday presents AND i don't cry
<zid>
It wasn't a power rangers toy though was it, that's what I wanted when I was 5
<heat>
otoh, i know what the C programming language is
<gog>
i'm going to cry
<heat>
so i am worse off than when i was 5
<mcrod`>
don’t cry
<gog>
since you're all mean to me about being a woman and a c# writer
* mcrod`
hug gog
<zid>
I'm not mean to you *because* you're a woman though
<zid>
the distinction is important
<heat>
C# programmers ☕
<zid>
I am mean to you and you HAPPEN to be a woman.
<moon-child>
I like my C# programmers like I like my coffee. Java.
<gog>
._.
<zid>
gog ur glasses came off
<zid>
your eyes are all tiny and gross
<gog>
o_o
<zid>
there we go
<heat>
all eyes are gross
<moon-child>
gog your pupils have dilated a bunch
<gog>
zoomies time
<moon-child>
are you a freebsd developer
<gog>
ew no
<mcrod`>
gog
<heat>
the only correct response
<mcrod`>
hug
<heat>
mcrod
<mcrod`>
wtf
<heat>
no
<mcrod`>
yes
<heat>
no
* gog
hug mcrod`
<heat>
GOG
<gog>
WHAT
<mcrod`>
it’s cuz i’m hot.
<heat>
SUP
nicesj has quit [Ping timeout: 248 seconds]
<heat>
geist, you know, i'm not entirely sure if a mmio_write that always does a dsb sy is desirable. is it?
<heat>
most interdependence between devices is rare enough that you can just manually add barriers if need be
<heat>
..i think
gog has quit [Ping timeout: 240 seconds]
danilogondolfo has quit [Quit: Leaving]
Turn_Left has quit [Read error: Connection reset by peer]