AFamousHistorian has quit [Ping timeout: 246 seconds]
vdamewood has quit [Quit: Life beckons]
AFamousHistorian has joined #osdev
AFamousHistorian has quit [Ping timeout: 260 seconds]
vdamewood has joined #osdev
heat has quit [Ping timeout: 246 seconds]
<kof673>
nikolar, this is WIP but has an example of critical bit trees https://0x0.st/s/iDFZFLAtT3p0pXdJ3djc2g/8swS.c this is for a "scripting language" so...one tree has all variable/etc. other names, and with a single capital letter after -- to lookup the type by name (capital letters disallowed in var names lol it will only be snake case lol ) then other trees look like <variable name><encoded data pointer to data for the vari
<kof673>
able or other item><0x00> this is a function to delete all the state of the interpreter. depending on the tree in question, it is either simple strings (just clr() the tree, which will free() all entries and "nodes") or use pfx() prefix search to find a single entry or all entries by name, decode the data pointer embedded within, free() that or call a function for that specific variable type/etc. ...and then clr() the tree
<kof673>
to remove the "strings"/entries of the tree and "nodes" as well
<kof673>
down at the very bottom are callback functions passed to pfx() that is the only "magic" perhaps...because the cb tree stuff I used does not allow embedded 0x00 in entries/strings, so have to store an "encoded data pointer" without any 0x00 inside it, and decode it on lookup, or in this case, to delete entries and the things they "point to"
<kof673>
i have generic functions to encode/decode binary data so that it does not contain 0x00....but a "C data pointer" is fixed size, so there are functions just for that, and a define with the size to easily make a C var to hold an "encoded data pointer", etc.
<kof673>
you could perhaps find a cb tree thing without such restriction
msv has quit [Remote host closed the connection]
msv has joined #osdev
<kof673>
err, need to separate components of the string somehow, so i disallow space ' ' in var names for example so it can be used for that purpose inside a cb tree e.g. <variable name> <SPACE ' '> <encoded data pointer><0x00>
craigo has quit [Quit: Leaving]
qubasa has quit [Ping timeout: 246 seconds]
ring0_starr has quit [Remote host closed the connection]
kilic has quit [Remote host closed the connection]
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
kilic has joined #osdev
housemate has joined #osdev
ionut_f has joined #osdev
housemate has quit [Ping timeout: 265 seconds]
cloudowind has quit [Ping timeout: 245 seconds]
cloudowind has joined #osdev
housemate has joined #osdev
cloudowind has quit [Ping timeout: 260 seconds]
the_oz has joined #osdev
the_oz_ has quit [Ping timeout: 252 seconds]
cloudowind has joined #osdev
ionut_f has quit [Ping timeout: 265 seconds]
hwpplayer1 has joined #osdev
<cloudowind>
orhchids are so intelligent more intelligent than i no doubt
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
housemate has joined #osdev
housemate has quit [Client Quit]
housemate has joined #osdev
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
ionut_f has joined #osdev
netbsduser has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
mahk has joined #osdev
housemate has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
ionut_f has quit [Remote host closed the connection]
housemate has quit [Read error: Connection reset by peer]
housemate has joined #osdev
GeDaMo has joined #osdev
housemate has quit [Ping timeout: 245 seconds]
Left_Turn has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 244 seconds]
housemate has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 252 seconds]
heat has joined #osdev
Dead_Bush_Sanpai has joined #osdev
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
muffin has joined #osdev
<muffin>
What happens if you try to access memory beyond physical memory?
<zid>
depending on arch, bus fault, or 0xFF or 0x00
<zid>
depending on if things drive the bus low or high
<zid>
(I think 0xFF default is more power efficient, and things selectively ground it, which causes current flow, which uses the power, rather than keeping it at 0x00 which leaks all the current all the time)
* Ermine
doesn't totally understand how computer operates at electrical level
<muffin>
Hmm...
<muffin>
I'm asking because on my Intel 64 computer, which first gets set up with UEFI, if I look at where the graphical memory is, it's a linear address that maps to a physical address beyond my physical memory
<zid>
you'd hope so
<zid>
if your device memory is overlapping your ram, then your ram is inaccessable in those locations
<zid>
so when you set up your pci-e devices (the bios does this) you put them all *after* your ram
<zid>
by writing big addresses into the BARs
<zid>
i.e my gpu has 12GB of ram or whatever, mapping that to 0 would be *very* unfortunate for me
mrpops2ko has joined #osdev
<zid>
11, what a weird number
<muffin>
Oh I see, thanks for the explanation!
<muffin>
So, basically all I have to do is to set up paging for an address beyond physical memory and write that into the BAR.
<zid>
you shouldn't need to mess with the BARs
<zid>
bios did that for you already
<zid>
That's why your LFB address is so high
<zid>
you just need some way to write to that physical address
<zid>
memory controller passes it onto the pci-e bus, device sees the address and goes "That's mine!" and subtracts the base address off it to get an offset, then knows "This is a write for offset 0x47 of my internal ram!"
<zid>
whether it's an ethernet card, gpu, or whatever, everything works like this
<muffin>
Very cool!
<muffin>
But let's say I want to change the BAR, I could right?
<zid>
yea should be able to
<muffin>
Cool
<zid>
but you might need to also let the pci-e controller above it know
<zid>
because the pci-e controllers route big chunks of addresses
<zid>
think of like, ip subnetting
<zid>
if you have cpu -> pci-e controller controlling all addresses that start 0x3FE0 + pci-e controller controlling all addresses 0x3FD0 + -> ...
<zid>
then your device might not even see the write if you move it to the wrong range
<zid>
because the write got delivered along the wrong pci-e host controller
<zid>
I apparently have a D0000000-E20FFFFF pci-e hub, FC200000-FC3FFFFF pci-e hub, of which FC200000-FC2FFFFF of which is actually handed off to a usb 3.0 hub, etc
<zid>
looking at aida
<zid>
The D00 range being my 16x slot the gpu is plugged into
<muffin>
That's the PCIe MMIO you are talking about?
<zid>
yea
<zid>
but it might just be device ram underneath
<zid>
or it might be registers, who knows
<zid>
(the pci-e config space knows)
<muffin>
I get that from ACPI MCFG and it tells me I only have one.
<zid>
OSs don't seem to bother to remap everything, instead they all have a bios option to futz with things to leave everything mapped at 3GB-4GB and just move the *ram* around >_<
<zid>
s/everything/anything
<zid>
I'd like to see what the e820 my bios delivers looks like but I am lazy
mrpops2ko has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
zxrom has joined #osdev
goliath has joined #osdev
muffin has quit [Quit: leaving]
bauen1 has quit [Ping timeout: 276 seconds]
housemate has joined #osdev
bauen1 has joined #osdev
goliath has quit [Quit: SIGSEGV]
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
<heat>
zid, huh that's weird
<heat>
4 root ports
<heat>
what do the pci addresses look like?
<heat>
also, yes, pci address assignment is complicated
<heat>
its chipset specific stuff and you need to parse a lot of ACPI to get the available decode zones, etc
Dead_Bush_Sanpai has quit [Ping timeout: 260 seconds]
<heat>
generally what happens is: 0 - ~3GB physical mem, 3-4G PCI decode region (plus the BIOS up top), 4G - end of phys mem, end of phys mem - $whatever 64-bit PCI decode
<heat>
for typical PCs
<heat>
then a PCI access gets sent to the root bridge and goes downstream according to whatever the PCI bridges/devices say they decode
karenw has joined #osdev
<nikolar>
> 3-4G PCI decode region
<nikolar>
i assume for 32-bit compat
<zid>
yea it was there when we had 2MB of ram
<zid>
and then we suddenly had 3GB and it was an issue
<zid>
so we started adding northbridges that were capable of splitting it into multiple ranges
<zid>
so that you could have it as a hole
<zid>
it = physical mem
<zid>
ISA had the same issue with 15-16MB
the_oz has quit [Ping timeout: 248 seconds]
the_oz has joined #osdev
<zid>
(also weirdly, with how pci-e takes prio over ram, it means that addresses go to the pci-e root *first*, then if they reject it, it goes to ram)
<heat>
not just 32-bit compat but rather lots of PCI devices only support 32-bit BARs
<zid>
aka 32bit compat :p
Dead_Bush_Sanpai has joined #osdev
<heat>
ones that have really big BARs (GPUs, storage) usually have those as 64-bit BARs yes
<heat>
but even accessing a 64-bit address thru PCI needs two cycles
<heat>
vs 1 for 32-bit
<Ermine>
i have a really big bar
<heat>
no need to lie ermine, no women here
<nikolar>
kek
edr has joined #osdev
karenw has quit [Read error: Connection reset by peer]
<Ermine>
>:(
hwpplayer1 has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
karenw has joined #osdev
steelswords9436 has quit [Read error: Connection reset by peer]
steelswords9436 has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 244 seconds]
Dead_Bush_Sanpai has joined #osdev
itszhadanjun has joined #osdev
itszhadanjun has quit [Quit: sleep]
gog has joined #osdev
kwilczynski has quit [Ping timeout: 265 seconds]
sskras has quit [Ping timeout: 265 seconds]
terrorjack45 has joined #osdev
larsjel has quit [Ping timeout: 265 seconds]
Stary has quit [Ping timeout: 265 seconds]
nadja has quit [Ping timeout: 265 seconds]
dequbed has joined #osdev
alexander_ has joined #osdev
terrorjack4 has quit [Ping timeout: 265 seconds]
alexander has quit [Ping timeout: 265 seconds]
terrorjack45 is now known as terrorjack4
larsjel has joined #osdev
kwilczynski has joined #osdev
Stary has joined #osdev
sskras has joined #osdev
craigo has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
vdamewood has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
bitfrog has quit [Remote host closed the connection]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
zxrom has left #osdev [Leaving]
solaare has quit [Ping timeout: 248 seconds]
solaare has joined #osdev
Maja has quit [Ping timeout: 252 seconds]
Maja has joined #osdev
sdomi has quit [Ping timeout: 264 seconds]
sdomi has joined #osdev
cloudowind has quit [Ping timeout: 248 seconds]
cloudowind has joined #osdev
adder has joined #osdev
x64S has joined #osdev
<geist>
yeah fun fact re: the 15-16MB hole. i have a tseng4000 VGA chip in my old 386. i scrounged up some docs for it and it actually has a control bit to enable that
<geist>
basically maps all of the up to 1MB it supports at 15MB
<geist>
makes sense for 286 era machines (and 386sx which is mostly drop in replacement) because they only had 24 bits of physical address pins
<Ermine>
where does it map by default?
<heat>
at 0
<heat>
memory starts at 0 wake up ARM sheeple
<karenw>
There's absolutely no issues just mapping stuff at 0x0. Especially in real mode...
<Ermine>
looking for something at address zero is totally not a problem
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
<zid>
I love having my top left pixels on my display determine how my interrupts route, idk about you
<nikolar>
zid: very convenient
<nikolar>
you change the interrupt routine by placing an image in the corner
chiselfuse has quit [Ping timeout: 264 seconds]
<childlikempress>
memory starts at (-1)<<47
chiselfuse has joined #osdev
<karenw>
childlikempress: warning: left shift of negative value [-Wshift-negative-value]
<karenw>
I think that's IB?
<zid>
irritable bowels
<zid>
left hand side negative is straight UB
<karenw>
IB => Implementation-Defined Behaviour
<zid>
that's IUDB
<zid>
IDB*
<zid>
IB is... infiniband? :P
<karenw>
Hmm, gcc at -O2 doesn't optimize it to oblivion and returns 0xffff800000000000 for `long foo(){ return (long)(-1) << 47; }`
<karenw>
I'm surprised it didn't just let control run off the end of the function tbh
<zid>
that's a clang thing :P
<zid>
and -O2 isn't very aggressive anyway
hwpplayer1 has quit [Quit: I'll be back]
<karenw>
-O2 is normally enough to get "UB results in nasal demons" behaviour
<karenw>
Or more sensibly "A path containing UB can never be executed, so I can pretend the entire block doesn't exist"
<zid>
not for things like aggressive eliminations because of UB, in my experience
xenos1984 has quit [Read error: Connection reset by peer]
<zid>
I get 0xAC1D29DD
<zid>
oh it truncated whoops
<zid>
yea FFFF800000000000
<zid>
surprised
<karenw>
I can't get it to omptimize it to oblivion even at -Ofast (gcc) / -O3 -ffast--math (clang)
<zid>
clang gives a 'this is undefined' warning
<zid>
but gives the same result
<zid>
I wonder if a bunch of software relies on it somewhere
<zid>
and it's harder to break it than it is to support it
<karenw>
"One version of MSVC for DOS supported this so we have to support it"
<zid>
msvc gives 0, and also a UB warning
<karenw>
Oh, my guess was wrong.
<zid>
warning C4293: '<<': shift count negative or too big, undefined behavior
<karenw>
Optimizing it to 0 is still sane though
<karenw>
Rather than the potential for time travel or segfaulting
<karenw>
Or the other insanity UB or IF;NDR can cause.
<zid>
yea maybe if we embedded it as the controlling expression somewhere
<zid>
it'd treat it as always true and always false at the same time
<zid>
but just taking its value gives.. a value, at least
<karenw>
Best UB I experienced was a switch going to a default case, but the default case printf'd the controlling expression and quite clearly output one of the other cases.
<zid>
hehe
<karenw>
I'd passed an argument via asm and forgot to clear the top half of esi
<karenw>
Or edi. Some 32-bit register
<karenw>
So the switch, switched on the full 32bit value, despite it being declared as a uint16_t. The printf only printed the lower 16bits.
<karenw>
Hilarity ensued
Left_Turn has joined #osdev
<karenw>
Actually, might have been declared as a uint8_t, same principle.
<nikolar>
afaik -ffast--math is only relevant for float math
<karenw>
Yeah, it's the equivlent to gcc -Ofast
<nikolar>
relaxes some constraints on precision which lets the compiler reorder oprations for perfomrance
<nikolar>
amongst other things
<nikolar>
btw, iirc, even when gcc optimizes to oblivion, it still gives you a `ret` at least
<nikolar>
unlike clang
<nikolar>
which let's you fall through
<nikolar>
so good guy gcc
Turn_Left has quit [Ping timeout: 276 seconds]
Turn_Left has joined #osdev
<zid>
I still don't understand why they added Ofast
<zid>
considering it implies a single option, -ffast-math
Left_Turn has quit [Ping timeout: 265 seconds]
<zid>
which is "Ignore IEEE's requirement that fused multiply add has worse precision than unfused", more or less
<zid>
err the same, when in reality it's worse
Left_Turn has joined #osdev
xenos1984 has joined #osdev
Turn_Left has quit [Ping timeout: 265 seconds]
Left_Turn has quit [Read error: Connection reset by peer]
<karenw>
nikolar: Laughs in `__asm goto`
<karenw>
zid: Clang agrees with you and removed it
<karenw>
To be fair, the __asm goto thing was considered a bug. It incorrectly optimized out the goto target, sometimes followed by ICEing, sometimes just outputting code that jumps past the end of the function