<moon-child>
.net garbage collector is a 30k line file
[itchyjunk] has joined #osdev
<klange>
That sounds distinctly like it's in "something significantly smaller could be way better, but it'll never happen because no one is going to allow the deletion of 30k lines of code in one commit".
<klange>
+territory.
<heat>
so I just found my favourite tool ever
<heat>
filterdiff
immibis_ has joined #osdev
<heat>
i definitely stan for this one
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
* sortie
is having normal one, went amok at a concert, 4 beers in, various bands that does not follow me stalking my profile, drunkenly porting opensh-8.8p1 at 1 AM, living that wild osdev lifestyle
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
heat has quit [Remote host closed the connection]
heat has joined #osdev
gog has joined #osdev
YuutaW has quit [Ping timeout: 268 seconds]
<geist>
j`ey: interesting so the selection dag is basically a huge pile of this turns into that?
sdfgsdfg has joined #osdev
<j`ey>
geist: yup
<geist>
off hand do you know what the file is? I can probably juist find it by sorting file size
<j`ey>
50k lines worth of this turns into that for x85 :P
<klange>
I should load it up in my editor.
<j`ey>
X86ISelLiwering.cpp
<klange>
See how long it takes the Kuroko C++ highlighter to bang through it.
<j`ey>
X86ISelLowering.cpp
<heat>
AArch64ISelLowering.cpp for arm64
<klange>
okay my copy is a bit old and it's only 18k lines
<klange>
and it still only took a second to highlight, nice
<klange>
This checkout of llvm is from... 2013!
<j`ey>
a bit old
<klange>
At least that's newer than, like, the one I used in college in Adve's compilers course.
<heat>
i'm currently upgrading my llvm toolchain from 12.0.0 to 13.0.0 and now it has to build 200 more object files
<heat>
woohoo
<klange>
~4s for the 52.6K line version
<heat>
the best part of working on llvm is waiting
<klange>
And my asynchronous highlighting is working fantastically and I can view and interact with the file before it finishes
<geist>
haha yeah. the x86 version is 2.2MB
<heat>
it legitimately doesn't open in github
<klange>
Let's toss this in a toaru vm and see how things go
<geist>
yah gvim seems to handle it, though YCM gives up saying its too big
<geist>
but anyway i guess someone was here asking what it takes to port llvm to a new arch: this is probably the meat of it
<klange>
oh and I seem to have correctly detected the 2-space indentation, too, so that's nice
<klange>
is this... pride in one's work?
<klange>
am I actually... happy with something I've built?
<heat>
yay pride
<klange>
My OS may get all the hacker news posts, but bim really is the thing I've put the most love into and is the most real-world usable thing I've made.
<geist>
yah soemtimes that happens
<klange>
I regret giving it a dumb pun name.
<heat>
linux, GNU, LLVM
<heat>
lots of poor names out there
srjek has joined #osdev
YuutaW has quit [Read error: Connection reset by peer]
nyah has quit [Remote host closed the connection]
arahael has quit [Ping timeout: 252 seconds]
arahael has joined #osdev
Oli has quit [Quit: leaving]
[itchyjunk] has quit [Quit: Leaving]
srjek has quit [Ping timeout: 252 seconds]
arandomcomrade has joined #osdev
arandomcomrade has left #osdev [Leaving]
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
Burgundy has joined #osdev
<graphitemaster>
Hey osdev, please review my really basic allocator but designed for a specific use case that no one seems to have considered for allocators
<bslsk05>
gist.github.com: A constant time allocator · GitHub
ElectronApps has joined #osdev
<moon-child>
graphitemaster: I think that in such a situation I should rather avoid dynamic memory allocation entirely
<moon-child>
‘Helper function to get the integer log 2 of |_value|’ why not just do this in terms of clz?
scoobydoo has quit [Ping timeout: 256 seconds]
scoobydoo has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
heat has quit [Quit: Leaving]
<rustyy>
so, i am trying to reverse-engineer a few libraries from VMware ESXi, opened them up just fine in ida pro, it seems like esxi kernel is just a linux kernel...
<rustyy>
and as for userspace, esxi runs busybox..
<kazinsal>
soooooorta
<kazinsal>
the kernel isn't actually linux, but it is mostly userspace-compatible with linux
<kazinsal>
for a while there was a driver interface layer that was somewhat linux-compatible as well but that was removed in... I think 7.0?
<rustyy>
kazinsal: huhh, good to know, thanks!
<kazinsal>
the Software Freedom Conservancy spent ten years trying to sue VMware for GPL non-compliance and got nowhere with it
<kazinsal>
a few early ESX versions did run on top of a linux kernel but in like 3.x VMkernel was introduced
m5zs7k has quit [Write error: Connection reset by peer]
m5zs7k has joined #osdev
xenos1984 has quit [Quit: Leaving.]
xenos1984 has joined #osdev
jjuran has quit [Ping timeout: 256 seconds]
jjuran has joined #osdev
xenos1984 has quit [Quit: Leaving.]
archenoth has joined #osdev
Oshawott has quit [Ping timeout: 245 seconds]
elderK has joined #osdev
<geist>
yah that was my experience with it
<geist>
basically a posixy environment, but i wouldn't be surprised if there weren't huge missing holes of implementation
<geist>
which makes sense, they just need to implement what they need
m3a has quit [Quit: leaving]
adachristine has joined #osdev
gog has quit [Quit: byee]
gog has joined #osdev
gog has quit [Client Quit]
adachristine is now known as gog
givemeyourpies has quit [Quit: Going offline, see ya! (www.adiirc.com)]
givemeyourpies has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
Arthuria has joined #osdev
GeDaMo has joined #osdev
[itchyjunk] has joined #osdev
dormito has joined #osdev
dutch has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
<zid>
I am too stupid for day 3 of advent of code
<GeDaMo>
Did you skip day 1 and day 2 ? :P
<GeDaMo>
I'm smart enough to not start in the first place :P
<klange>
It's really poorly written.
<riv>
too many words
<zid>
It is really poorly written half the time year
<zid>
yeah
<junon>
> Considering only the first bit of each number, there are five 0 bits and seven 1 bits. Since the most common bit is 1, the first bit of the gamma rate is 1.
<zid>
CO2 scrubber rating is impossible to calculate, anyway
<junon>
This reads like nonsense to me
<zid>
reads fine to me
<zid>
It should be in command form though
<junon>
Eat number has 5 bits
<zid>
"Consider only the first bit of each number. There are five numbers with .."
<junon>
Oh
<junon>
God I had to read it like 4 times to understand what it's trying to say
<zid>
I refuse to build a tree or scan the input more than once else it'd be easy tbh
<zid>
I'm trying to do part 2 part 2 by inverting the bits and it's frying my brain
<junon>
You don't need to scan more than once though?
<junon>
This is a linear time operation
<zid>
it makes it trivial if you do
<klange>
I don't think you can do part two by inverting the bits. You have a different set of numbers to look at.
<zid>
but I don't wanna cus it should be linear
<junon>
unless I'm mistaking it
<zid>
klange: You can do it if you run it twice ;)
<zid>
I should just do a test-case but that's effort
<klange>
I would say I'm doing these in Kuroko as a stress test of the language, but the language works great and I doubt I will discover any bugs with these things
<klange>
More just doing it out of principle...
Arthuria has quit [Ping timeout: 252 seconds]
<junon>
the XOR of N with a number of equal bit width with all bits high (1) is the equivalent of a bitwise `NOT N` right?
<zid>
yes
<junon>
thanks
<zid>
remember to mask by 0xFFF
<zid>
or whatever
<zid>
depending what you're up to
<junon>
right yeah
<zid>
trie, copying the list to a partial list recursively etc are all easier than what I am doing >_<
ahalaney has joined #osdev
<junon>
zid you're talking about 2021's AOC day 3 right?
<zid>
part 2
<zid>
not part 1
<junon>
20 lines of python solved it for me, you don't need any data structures other than an array or two.
<junon>
Ohh
<junon>
Oh there's a part 2
<zid>
there's a part 2 on every day
<junon>
oh I see, I've never done AOC before.
<zid>
Okay to parameterize part 2 I need to flip a <= and a >= hmm
<zid>
change it to g(p) and it does infact pull something off the stack for an arg, hmm
<zid>
Presumably I'll need to get in there and start popping error codes and crap once I start dealing with stuff properly
<zid>
and I'll have to nix the quick attribute hack
<zid>
nice, enabled the lapic.. GPF at 0x79870f07fe804053 :D
<gog>
you can declare an interrupt handler with two parameters and gcc will put the error code in the second
<zid>
oh okay so it does do useful things, nice
<gog>
yeah but it's still dodgy
<gog>
ok gcc elides the preamble at -O1
<zid>
now figure out what 79870f07fe804053 means for me
<zid>
You're doing well so far
<GeDaMo>
I think that's a number :|
<nshp>
I think those are x86 instructions
<nshp>
fun game
<zid>
0: 79 87 jns 0xffffffffffffff89
<zid>
2: 0f 07 sysret
<gog>
it's your blockchain address
<zid>
all I can think of is that it's some trash in some memory somewhere
<zid>
some apic reg holding where to deliver interrupts to or whatever
<zid>
okay I think I just broke /bin/init at some point when I was messing with my commit history etc
<zid>
needed to build clean it
sprock has quit [Ping timeout: 252 seconds]
<geist>
zid: yah was gonna point out those look like ininstructions
<geist>
0f is a good tell since it's a prefix for a lot of 2 byte instructions
srjek has quit [Ping timeout: 252 seconds]
<zid>
Trying to figure out why I only get one e1000 interrupt now :)
<zid>
not sure if lapic or I broke my networking somehow
hxx has joined #osdev
<zid>
maybe because it went through the PIC or something?
mahmutov has quit [Ping timeout: 252 seconds]
<zid>
Hmm I get an int 8 now, but not as a double fault at least, not sure why though
<zid>
aand the forums just crashed, nice
<geist>
there may be multiple places you need to ack it. also are e1000 irqs implicitly edge or level triggered?
<zid>
I fixed that, I was getting it from the PIC, I don't think I want it from the PIC
<geist>
possible you have to clear some 'i read this' status on the e1000 itself
<zid>
I stopped acking the PIC I changed it to acking the lapic, I assume it's still possible to get pci int pin irqs through the lapic?
<geist>
yah the int 8 was probably because you didn't relocate the PIC's base addresses?
<zid>
or do I need to upgrade to msi
<geist>
to properly use the lapic i think you have to read all the ACPI nonsense to get the full mapping, which is a lot of work
<geist>
honestly i'd probably stick to PIC and MSI where you can use it
<gog>
yeah you need to parse MADT and a bunch of other things to get to the point of being able to use MSI
nvmd has joined #osdev
<zid>
Yea I think you do too, but if I can.. pretend I read it in qemu and vmware
<geist>
then yes you can use lapic
<zid>
do you think it's true though, that if I disable the pic, I have to swap pci interrupts over to msi interrupts, so that I can still redirect them outside of 0-15?
<geist>
the main advantage over PIC in that case is you generally dont have to deal with stacked interrupts
<geist>
think of MSI as a completely different mechanism that per device you can opt into bypassing the whole PIC/ioapic thing
<geist>
but it's not a given, but kinda is for anything modern
<zid>
yea I know that much
<geist>
it's basically independent of whether or not the fallback irq controller is PIC or ioapic
<geist>
so you can stick with PIC and then on a per device use MSI
<zid>
I'm just wondering if it's possible to convince the lapic to do something similar to the pic, and move my INTA# back to interrupt 35
<geist>
but for dumb old devices like serial ports, just use PIC
<geist>
lapic or ioapic?
<zid>
I've not touched the ioapic, that sounds like the next step
<geist>
oh i thought that's what you meant when you said lapic
<geist>
lapic != ioapic. lapic does not deal with external interrupts
<geist>
but you'll need a driver for it nonetheless
<zid>
it's all in the same section in the manual
<zid>
:/
<geist>
sure. because lapic and ioapic are both derivatives of the original 'APIC' chip in the 90s
<eryjus>
split architecture
<zid>
Local APICs can receive interrupts from the following sources: ... Externally connected I/O devices ...
<eryjus>
took me a while to get my head around that
<geist>
sure, but lapics aren't themselves attached to external interrupts
<zid>
which is how I am getting the int 8, let's check the ioapic to see if I can move the delivery address
<geist>
so they dont participate in routing them
<geist>
int8 is probalby because you didn't relocate the PIC
hxx has quit [Quit: Leaving]
* j`ey
actually playing around with some OS code again
<geist>
coming out of the bios the first PIC is probably pointing at 8-15 and the second is like 70-7f
<geist>
so you got an external legacy irq0 whic was routed to int 8 on the cpu
<zid>
I can't tell if I should uncomment my pic code or not
<geist>
you should at least hard disable it if you're going to do that
<geist>
but then you need an ioapic driver
<geist>
so again i'd just recommend using PIC and then MSI for devices that support it
<zid>
okay so I guess I forgot to hard disable it, I figured the ioapic was just doing the 1:1 mapping
<zid>
like the pic does at boot
<zid>
but apparently the pic is what's doing it
<geist>
since fully using ioapic requires more ACPI work
<geist>
aah gotta go. meeting time
<zid>
Is it just me or does the manual completely fail to mention the ioapic other than passively in the lapic part
<zid>
I guess it's just.. "The ioapic does what the ioapic chip did, good luck"
<zid>
I think MADT will contain the ioapic base addr then I treat it like the old pic but talk to it differently, is the gist of it
<zid>
okay doesn't look too bad, just some tables with where to where, a base address, etc
sprock has joined #osdev
givemeyourpies has joined #osdev
YuutaW has joined #osdev
heat_ has joined #osdev
Ameisen has quit [Quit: Quitting]
heat has quit [Read error: Connection reset by peer]
Ameisen has joined #osdev
sprock has quit [Ping timeout: 252 seconds]
Ameisen has quit [Quit: Quitting]
Ameisen has joined #osdev
sprock has joined #osdev
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
<geist>
yah it's not too weird
<kazinsal>
iirc it's really the IRQ routing stuff you have to figure out through ACPI bytecode that's the really weird part
dormito has quit [Quit: WeeChat 3.3]
GeDaMo has quit [Remote host closed the connection]
<geist>
right, if you want to take advantage of he 'unpacked' irqs to the global interrupt numbers, etc
<geist>
but like i said i think in modern stuff *most* irqs can be MSI, and it's really just a few legacy things that still route to the old IRQ numbers, so you can just use the PIC for those
<geist>
at least base don what i see linux do for most modernish machines i've booted on recently
<geist>
they dont use the PIC, but the number of non MSI based hardware irqs are just a handful
<kazinsal>
totally
<geist>
downside with the PIC on an SMP machine though is you can only route them to cpu 0
<geist>
i dont know if this PIC + MSI strategy will always work, but having to use the ioapics really sucks with ACPI
<geist>
since the tables for the relocation are part of the DSDT which is one of the bytecode interpreted tables
<geist>
i dug into it recently and the TL;DR is as you parse the per device records and run their bytecode, it says 'PCI device X's GSI (global interrupt) is at ioapic N vector M'
<geist>
or at least about 80% sure that's the case. I know it's in the DSDT, but that may be not precisely what it's telling you
<geist>
looks like in the Old Days the mptable bios structure had the same info. So in as much as that may still exist and be filled out, you might be able to use it, but it's deprecated as long as ACPI is around
<geist>
i remember doing this like 25 years ago and it was mptable based which was at least fairly easy to parse at the time
<geist>
but alas ACPI made it all worse
<kazinsal>
would be interesting to see how many new boards still support the MP table spec
<kazinsal>
entirely out of curiosity though, not out of desire to implement. like you said it's been deprecated for two decades now
<junon>
yay llvm finally migrating their BZ issues to GH
CaCode has joined #osdev
gdd has quit [Read error: Connection reset by peer]
Burgundy has quit [Ping timeout: 252 seconds]
sprock has quit [Ping timeout: 252 seconds]
air has quit [Ping timeout: 252 seconds]
sdfgsdfg has joined #osdev
gdd has joined #osdev
dutch has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
nostalgia has joined #osdev
dormito has joined #osdev
nostalgia has quit [Remote host closed the connection]
srjek has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
<klange>
RIP forum, once again
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<zid>
yup
<junon>
Oh noo
air has joined #osdev
<klange>
The wiki is still functioning, though, so at least there's that.
<kazinsal>
RIP the database
ahalaney has quit [Remote host closed the connection]
<heat_>
nothing better than a good nap so I can stay up all night