<zid>
I keep telling him not to keep his yellowcake on top of the server racks but he won't listen
<zid>
says he needs a snack while he works
<gamozo>
Is it always the same dimm? :D
<zid>
I think that is just a specific dimm
<zid>
looking at the output
<zid>
channel 1 dimm 0
<geist>
hehe
<geist>
i do wonder in general if ECC errors happen more in the summer than winter, etc
<geist>
my server for example is sitting about 2 feet from the roof
Likorn has joined #osdev
heat has joined #osdev
<gamozo>
Oooh! For me the answer was yes!
<gamozo>
But my servers were not in an air-conditioned room that got to like 115 F in the summer
<gamozo>
EEC was up a lot (I think the ecc errors were thermal/fan issues in the first place)
<zid>
yea ecc errors massively overcounts stray high energy photons, what they mainly measure is how shitty the dimm was manufactured
<gamozo>
I've definitely stopped buying DIMMs by sorting my price and my problem has since stopped :D
<gamozo>
Ahaha. Also got air conditioning!
<zid>
gamozo I need you to check your drawer of old dimms for 4x8GB of 933MHz ECC UDIMMs kthx
<gamozo>
I've got a bunch of DDR2 floating around, if you want that? :D
<zid>
something tells me it isn't 933MHz :p
<gamozo>
Every time I go through a box I find some random stick of RAM. I'd just toss them out of the computer once I got ecc errors
<gamozo>
Nope :(
<zid>
Failing that, I need a mac pro 2013 in someone's shed to steal from
<gamozo>
I've got a powermac g4 with 1.25 GHz dual PPC processors, does that help?
<gamozo>
It's my PPC test rig, I love it
<gamozo>
Bought it for like $300 on ebay a few years ago when I had to develop a PPC emulator
<gamozo>
I had no idea they made them with 2 processors, I was surprised. It also has gigabit ethernet on the board?!
<zid>
well you'd need two if they're ppc :P
<zid>
otherwise it wouldn't do anything
<gamozo>
Ahaha
<gamozo>
I want to add Alpha to my collection, but those are so expensive. I wanna play around with that memory ordering
<zid>
I have a friend who loves alpha
<zid>
I always troll him and ask him do debug why my printf is reporting elHlo ,roWl!d
<zid>
https://www.ebay.co.uk/itm/265106467803 I think these are what I need, for some reason it's a super rare dimm that happened to be shipped as part of one of the higher sku mac pro 2013s
<bslsk05>
www.ebay.co.uk: Authentic Apple OEM 32GB RAM (x4 8GB) 14900 PC3 DDR3 SDRAM From 2013 Mac Pro | eBay
<zid>
so it's half the price if you search for old mac ram, than if you search for a crucial model number or whatever
<zid>
I get to pay import duty on top of that price too, can't find any nearby
Likorn_ has joined #osdev
nyah has quit [Ping timeout: 272 seconds]
Likorn has quit [Ping timeout: 276 seconds]
freakazoid333 has quit [Read error: Connection reset by peer]
nsmb has joined #osdev
Likorn_ has quit [Quit: WeeChat 3.4.1]
troseman_ has joined #osdev
troseman has quit [Ping timeout: 256 seconds]
No_File has joined #osdev
No_File has quit [Client Quit]
freakazoid333 has joined #osdev
rustyy has quit [Quit: leaving]
vdamewood has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Killed (zinc.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
No_File has joined #osdev
<mrvn>
anyone tried gcc -static-pie?
No_File has quit [Client Quit]
<clever>
that sounds perfect for what i was asking about earlier
<mrvn>
and seems to be from gcc 8
<mrvn>
2017
<clever>
vc4-elf-gcc (GCC) 6.2.1 20161217
<clever>
might have trouble there
<clever>
dang
heat has quit [Ping timeout: 272 seconds]
rustyy has joined #osdev
<mrvn>
It sounds like the option would add a stub to the binary that handles all the relocations.
<mrvn>
maybe even evaluate the initarray
<clever>
neat
<clever>
kind of assumes that gcc knows what subset of asm is pie safe then?
<clever>
so it can generate the stub
<clever>
but then again, it should also know that, so it can prefer that subset when doing normal pie builds?
<mrvn>
no more or less than any PIC code. It should just add the relocation function from a dynamic linker into the binary.
<clever>
yeah
bradd has quit [Remote host closed the connection]
troseman_ has quit [Ping timeout: 244 seconds]
bradd has joined #osdev
GeDaMo has joined #osdev
duckworld has quit [Ping timeout: 252 seconds]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
mahmutov has joined #osdev
duckworld has joined #osdev
nsmb has quit [Ping timeout: 246 seconds]
the_lanetly_052 has joined #osdev
Likorn has joined #osdev
wootehfoot has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
dennis95 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
the_lanetly_052 has quit [Ping timeout: 276 seconds]
vinleod has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
terminalpusher has joined #osdev
<sortie>
<geist> i'm torn between 'lets just do posix so i can be like sortix' and 'meh more fun to build a lower level more embeddedy but user space thing'
<sortie>
<geist> and the latter is probably an actually useful thing
<sortie>
Excellent choices :)
<sortie>
Personally I'm doubling down on my direction because actually being a fully self-hosting networked POSIX system that's 1) server workflow oriented 2) easy to hack on locally, really is possible given all my investment so far and gets very far into
<sortie>
'actually useful territory'
<sortie>
Like, you know, one would pick it up, play around with it a bit, hack on it a bit, and put it into production of some less important but cool workflow on whatever server/VM one happens to have around to play with
<sortie>
But your second suggestion likely has a lot higher bang/buck ratio, given the big investment needed to get as POSIX as I am and also to build the ports ecosystem
<sortie>
I always applaud thinking about what one personally wants out of osdev and aligning the OS's goals with that :)
the_lanetly_052 has joined #osdev
Burgundy has quit [Ping timeout: 240 seconds]
Likorn has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
mahmutov has quit [Ping timeout: 244 seconds]
Terlisimo has joined #osdev
<kazinsal>
augh. it's light out. why is that allowed to happen so suddenly?
<sortie>
Power outage?
<kazinsal>
it just so happens that it's 5:30am and I was really hoping it wouldn't be by now
<kazinsal>
it's now sunday which means a) I have plans this evening that I can't skip out on and b) I have a plan to go to a music store and throw a bunch of money at some people to give me some guitar gear...
<kazinsal>
unfortunately the extremely-late-night screening of Dr. No took more of my night than I expected
<kazinsal>
and now I'm downloading -- er, perfectly legally acquiring -- the whole series of Connery era Bond films...
nyah has joined #osdev
mahmutov has joined #osdev
vdamewood has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 240 seconds]
vinleod is now known as vdamewood
nick64 has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
gog has joined #osdev
wand has quit [Ping timeout: 240 seconds]
wand has joined #osdev
<dzwdz>
so last night i got down to having only one kernel page mapped in the user processes and i wonder
<dzwdz>
is there actually any legitimate reason why one might want that?
<sortie>
Well it allows a big user-space and it also does have some memory protective properties in the face of current RAM memory leak bypasses and so on
<sortie>
I'm having one of those days when I'm debugging my TCP stack using raw sockets
No_File has joined #osdev
<bauen1>
dzwdz: how did you get down to only 1 page ? don't you need the gdt iirc idt mapped, presumably along a bit of helper code for syscalls / interrupts ?
<dzwdz>
the largest thing is the idt which is 2048 bytes
<dzwdz>
and i got the isr trampolines into 5 bytes each + a bit of helper code
<dzwdz>
the other stuff is tiny enough not to matter
<sortie>
okeydokie I managed to reproduce my TCP socket leaks for half open connections
No_File has quit [Quit: Client closed]
<zid>
4k is a lot if all you're doing is reloading cr
<zid>
and jumping out of a stub
nsmb has joined #osdev
<dzwdz>
isn't a jmp alone 5 bytes?
heat has joined #osdev
<dzwdz>
if you want 256 isrs you just don't have the space to reload cr and jump away 256 times
<sortie>
Just one of those days when osdev requires reading ancient documents from the Defense Advanced Research Projects Agency
<dzwdz>
zid: but that wouldn't fit
<zid>
it fits fine in 4096 last I checked
<dzwdz>
but i'm talking a single page for everything
<dzwdz>
including the IDT, which takes 2k alone
<zid>
oh you'd need a kernel stack page..
<zid>
oh an entire kernel in 4k?
<zid>
not 4k of kernel mapped
<dzwdz>
no, just the part that's mapped
<zid>
what are you doing for reg save, is the page writeable?
<dzwdz>
it is writeable, and i'm using pusha
<zid>
I suppose you could technically be incredibly silly and use a bunch of MSRs to hold regs though :D
<dzwdz>
it's terrible lmao
<zid>
oh x86
<dzwdz>
i do believe you could do the same thing on x64
<zid>
pusha doesn't exist
<zid>
and every table is twice as big
<dzwdz>
without pusha
<dzwdz>
oh
<zid>
so it'd be.. a challenge
<dzwdz>
well every table being twice as big would be a slight issue
<zid>
if you wanted the full interrupt number range you'd b asically be out of space already
<dzwdz>
yup
<zid>
but.. who needs more than like.. 48
<zid>
Just use a 2M page :p
<zid>
I wonder how many entry points you could effectively re-use
<zid>
like, what if you set the IDT entries to an invalid value so that it page faulted, and then "If CR2 has that magic value, we check the interrupt bit otherwise it's a syscall" or whatever
<zid>
so that you don't actually need as many unique addresses floating around
<dzwdz>
this is such a weird idea, i love it
<dzwdz>
so basically the way it works in my setup is that i have 255 movs to %ebx
<dzwdz>
each idt entry points to the middle of one of those
<zid>
yea it was really common to just have mov rax, blah; jmp rax x256 in a huge nasm macro at one time
<zid>
in the 80s when people were doing x86
<dzwdz>
then it gets reinterpreted as `pusha; mov $[interrupt idx], %ebx; nop`
<dzwdz>
that's basically what i was doing before but it was taking up too much space
<dzwdz>
i wonder how bad sliding down those 200 movs is for performance
<zid>
on a modern cpu probably fuck all cost
<zid>
on an x86 only cpu really bad
<heat>
you need to jmp though?
<dzwdz>
256 call instructions would take up the same amount of space, but then you'd to get the interrupt index you'd need to divide the return address by 5
<dzwdz>
which i guess is probably faster
<zid>
the calls would fuck you
<dzwdz>
heat: wdym?
<zid>
if you're sliding through some movs
<zid>
you just only have the last mov do anything
<heat>
exactly
<zid>
so I assume you meant mov jmp or mov ret or something not just mov
<dzwdz>
i have overlapping instructions
<heat>
????
<heat>
stop it, get some help
<zid>
okay but you need 256 different decodings
<zid>
but you can only have 16 or so before it'll resynchronize
<zid>
so I'm still confused
<heat>
the canonical way to do it is to have a macro with mov $vector, %eax; jmp interrupt_handler
<zid>
which I mentioned :D
<zid>
>yea it was really common to just have mov rax, blah; jmp rax x256 in a huge nasm macro at one time
<zid>
well, jmp thing
<zid>
not rax
<zid>
to turn an interrupt vector into a common path with interrupt number
<zid>
somewhat ironically after that you'd tend to switch on the interrupt number, re-vectoring it, but it saved duplicating the intro 256 times I guess
<dzwdz>
maybe this will be easier to explain if i send the actual patch
<bslsk05>
github.com: kernel/i386: shave down the ISRs to 1279 bytes · dzwdz/camellia@cb23d7e · GitHub
<dzwdz>
oh and note: i'm not actually doing this on the main branch, i was just fucking around
<zid>
see, you do have a 256x macro :P
<dzwdz>
indeed i do
<zid>
why not pushal outside btw and save it from inside every vector
<zid>
oh I guess.. that doesn't work
<dzwdz>
i'm clobbering %al and %ebx
<zid>
these are the vectors so there's nothing prior
<zid>
Okay so explain this, it looks like you re-vectored the idt so they're all 5 bytes instead of 8, and offset it by 1
<zid>
and in each vector you wrote both pushal; mov al, vec and mov ebx, pushalmovalvc
<dzwdz>
it jumps into the pushal
<zid>
but the interrupt itself jumps to the pushal cus the +1
<zid>
when does the mov ebx run?
<zid>
and why
<dzwdz>
and then after the nop it interprets all the other vectors as `mov [some junk], %ebx`
<zid>
oh so it's to set the sled up, I see
<zid>
okay so how I would describe this, 10 mins ago, is
<heat>
if you want to shave down the ISRs, push the interrupt number and don't clobber anything there
<heat>
doing encoding crazyness is not the way
<zid>
"I put a padding byte between each vector, so that when we sled through it, it doesn't reload eax repeatedly it just clobbers ebx instead"
<heat>
pushb \interrupt_num
<zid>
yea that seems.. vastly shorter
<heat>
jmp _isr_stage2
<zid>
probably 2 bytes
<dzwdz>
oh that's true, actually
<dzwdz>
but where's the fun in that
<zid>
you could keep your sled thing by doing a 16bit load of bx with 'pushb n' assuming that encodes in 1 byte still..
<zid>
or some other useless 16bit native op
<dzwdz>
oh i could very probably get it down to 3 bytes per vector
<zid>
nod
<zid>
oh you'd need 66 bb for that, so 4 bytes
<zid>
I need a useless op that's 16bit native in pmode
<dzwdz>
xor %ebx?
<zid>
that'll either take a 32bit immediate, or a 16bit but need an override just the same I assume
<dzwdz>
why would it need an override?
<zid>
to make it 16bit
<zid>
mov bx, 0x1234 -> 66 bb 34 12
<zid>
mov ebx, 0x12345678 -> bb 78 56 34 12
<dzwdz>
ah
<zid>
so you need an instruction that *doesn't* need the override but *does* take a 16bit immediate, to save an extra byte, but idk if one exists.
noocsharp has joined #osdev
friedy10- has joined #osdev
wolfshappen has quit [Quit: later]
wolfshappen has joined #osdev
<stephe>
im trying to test if a20 is enabled by checking for 0x55aa in real mode with qemu + gdb, if i check manually in gdb i see it: 0x107dfe:0x550xaa, but if i check in assembly i get 0x0000 (movw $0xffff, %ax; movw %ax, %es; movw %es:0x7e0e, %bx).... any ideas what im doing wrong?
<heat>
are you sure the math is correct?
<stephe>
no, it could be wrong but i think its right :) i'll check once more
<stephe>
the boot sector is loaded from 0x7c00 to 0x7c00 + 0x200 = 0x7e00, so the last two bytes should be 0x7dfe - 0x7dff? so if we add 1 meg to that we get 0x107dfe, which is where i checked memory in gdb and found 0x55aa. converting the segment + offset in assembly to physical address is 0xffff0 + 0x7e0e = 0x107dfe, so that checks out
<mrvn>
Why does the IDT have to point at anything valid at all? Just let it fault, check the cause, change address spaces and let it retry.
<mrvn>
the entries I mean
dude12312414 has joined #osdev
Burgundy has joined #osdev
<sortie>
Is a TCP SYN packet with a zero window considered invalid by the standards?
<zid>
are your args all the right way around in that at&t mess? :P
<sortie>
I'm having some trouble with those TCP SYN WND=0 packets because SYN/FIN are considered part of the send window and there's no window room for the SIN
<stephe>
zid: :)
<zid>
There is never room for SIN
<zid>
repent sortie
<sortie>
I need to make TCP RFC introducing the SIN bit as an evil bit counterpart
<heat>
sortie, the tcp header is not part of the window is it?
<sortie>
The header is not
<heat>
i think it juts accounts for data
<sortie>
But SIN and FYN are part of the sequence numbers, thus the window
<sortie>
I see two ways of handling this. The first is to be compatible with the invalid TCP SYN WND=0 packet and just rewrite it as WND=1 when in the LISTEN state. The second is to reject it.
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<sortie>
Ordinarily I'd lean towards the compatibility behavior (since ‘an implementation must be conservative in its sending behavior, and liberal in its receiving behavior) but since at least two hobby operating systems have caught the SYN WND=0 bug connecting to my irc.sortix.org perhaps it's best to reject (’with great power comes great responsibility’)
<sortie>
cc geist whatcha think?
<sham1>
What would a 0-length SYN even mean
<heat>
it's not a 0 length SYN
<heat>
it's a SYN with a window size of 0
<heat>
i.e you can't send data to it
<sortie>
WND=0 means ‘stop sending I'm overloaded and have no room left‘
<sortie>
SYN WND=0 means ‘Let's synchronize but I have no room to hear your SYN’
<heat>
no!
<heat>
that's not what it means
<sortie>
heat, prove me wrong. :)
<heat>
you can send tcp headers to a zero window'd host
<heat>
i.e tcp keepalive
<heat>
erm, not keepalive?
<heat>
that thing where you ack it periodically when in zero window
<sortie>
Yes, you can still send TCP headers
<sortie>
But there's no room for new data
<sortie>
Which includes SYN and FIN by definition since they're part of the window
<heat>
but it's not data
<sortie>
Yes they are
<sortie>
It's just not actual bytes sent
<sortie>
They're in the window as counted by the state machine's counters
<mrvn>
Do they add anything to the data buffered on the other side?
<heat>
no
<mrvn>
then let it slide.
<sham1>
hah!
<mrvn>
worst case the other side drops the packet because the window is full
<bslsk05>
datatracker.ietf.org: RFC 793 - Transmission Control Protocol
<sortie>
“send window
<sortie>
This represents the sequence numbers which the remote (receiving) TCP is willing to receive. It is the value of the window field specified in segments from the remote (data receiving) TCP. The range of new sequence numbers which may be emitted by a TCP lies between SND.NXT and SND.UNA + SND.WND - 1.”
<dennis95>
RFC 793 section 3.3 "Note that when the receive window is zero no segments should be acceptable except ACK segments"
heat has quit [Read error: Connection reset by peer]
<dennis95>
That sounds like SYN cannot be received when window is zero
<sortie>
Since SYN and FIN are counted in those sequence numbers, a zero send window received in LISTEN means the remote is unwilling to accept a sequence number for SYN
heat has joined #osdev
<sortie>
dennis95, boom
<mrvn>
Wouldn't a window size of 0 prevent you from sending syn cookies?
<sortie>
You wouldn't SYN WND=0
<sortie>
You wouldn't steal a car
<heat>
mrvn, why would it?
<heat>
sortie: still, compatibility.
<sortie>
heat, why?
<mrvn>
heat: becasue the cookie has no space on the reciever side
<sortie>
heat, everything is sending SYN 0<WND or irc.sortix.org wouldn't work for lots of people
<heat>
a syn cookie is a syn-ack with specially encoded fields
<sortie>
heat, and rejecting it made you and geist fix your operating systems
<mrvn>
and "except ACK segments", ok. never mind.
<heat>
sortie, otoh, being compatible with existing network stacks is more important than being pedantic
<heat>
again, be liberal in what you accept
<sortie>
heat, fix your OS
<sortie>
:P
<heat>
i did
<heat>
fix yours :P
<sortie>
Mine is correct
<sortie>
OK that stray ACK packet is wrong, I'll fix that, thanks for the suggestion
<heat>
you could, you know, just syn-ack
<sortie>
And let those meddling kids get away with it?
<heat>
you actually won't have that much state once you rework your listening code
<sortie>
+ if ( !hdr.th_win )
<sortie>
+ return;
<sortie>
Easy peasy
<sortie>
Just drop the packet
<sortie>
A bit more confusing than a stray ACK though
<heat>
it's the same result
<heat>
the client will just drop the ACK and try again
<mrvn>
according to RFC 793 ACKs are excempted. why would it be dropped?
<heat>
because an ACK in response to a SYN is completely incorrect
<sortie>
mrvn, the bug was that if I get a SYN WND=0 then I just send back an ACK instead of a SYN ACK since there was no window room for the SYN
<mrvn>
yeah, don't do that. :)
<sortie>
Instead I'll just drop SYN WND=0 packets
<sortie>
I'll be invisible to buggy network stacks though
<mrvn>
isn't there an "ICMP you did something wrong"?
<sortie>
Although MOST of the ones I'll meet are probably from osdevers
<heat>
no
<heat>
you could RST but RST'ing here is also wrong
<zid>
man such a stickler
<sortie>
RST is my favorite bit. “There is no hand that you are talking to.”
<mrvn>
Why would it matter what is at 0x107dfe when you are reading from 0x7dfe?
<stephe>
mrvn: im trying to check that memory wraps around with a20 disabled, so i think they should be equal?
<mrvn>
Lets check dx first.
<mrvn>
What's at 0x7dfe?
<stephe>
0xaa55
troseman has joined #osdev
<stephe>
it should be the end of the first 512 byte sector of the floppy (which is loaded at 0x7c00, so 0x7c00 + 512 - 2 = 0x7dfe)
<mrvn>
0xffff0 + 0x7e0e = 0x107dfe, so that checks out.
<mrvn>
But if both addresses hold 0xaa55 then with or without a20 you should always get the same number. So what you get is strange and your test is broken.
<mrvn>
what is in es and bx at the breakpoint?
<stephe>
es = 0xffff , bx = 0x7e0e
<zid>
does qemu even support this
<zid>
istr that the A20 is just wedged open for perf, otherwise it'd have to emulate x86 instead of just running it
<zid>
but maybe I was thinking of some other vm
<heat>
i believe it does
<stephe>
i thought it does too
<mrvn>
zid: qemu != kvm for some options
<mrvn>
Maybe qemu like you call it doesn't support memory over 1MB at all for 16bit mode?
<mrvn>
I wonder why you even care. Just set A20 already and go to 23/64bit.
<zid>
how does it pull that off?
<zid>
as far as I can tell it'd have to emulate it
<mrvn>
zid: it does if you don't use/have kvm
<mrvn>
zid: or map everything above 1MB to a zero page and ignore writes.
<zid>
and by emulate it I mean like.. full dynarec that inserts an AND onto every single memory op
<zid>
hmm I guess it could do silly things with paging
<heat>
realistically a fully emulated x86 with an and before memory ops is still faster than a 16-bit cpu
<heat>
and this is only useful in 16-bit mode
<mrvn>
way to fast. you have to add lots of sleeps to get 16MHz performance for your old games.
<heat>
also can it even emulate memory accesses like that?
<heat>
since, you know, mmio and whatnot
<mrvn>
what mmio in 16bit?
<heat>
vga
<mrvn>
that's below 1MB
<heat>
firmware EEPROM
<heat>
yes, and it's still mmio
<mrvn>
qemu brings it's own firmware
<geist>
yay sortie is back!
<heat>
mrvn, and you still can't write to it.
<heat>
if you can, it's broken
<sortie>
geist, sure am
<geist>
sortie: yah i didn't mean sortix wasn't actually useful BTW. there was kinda an unspoken rest of that sentence which was 'to me'
<sortie>
Yeah I did implicitly read that :)
<geist>
as in given my general interests a lower level user spcae thing that's not posixy is probalby more intrinsically useful
<geist>
okay cool. yeah
<sortie>
It's really the bang/buck ratio and what stuff one enjoys to build and use
<geist>
right
bauen1 has quit [Remote host closed the connection]
<geist>
and i did this once before with newos, but i just kinda dont feel like resurrecting it. i'd rather build a newos v2 and go through the effort again, given what i know now
<sortie>
Oh man I'm so deep in TCP right now
<sortie>
Them sockets be leaking so bad it's sinking the ship
bauen1 has joined #osdev
ripmalware has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
<stephe>
mrvn: hmm is there a way to turn off kvm and make qemu only emulate?
<mrvn>
there is "-enable-kvm" so look for the opposite
the_lanetly_052 has quit [Ping timeout: 272 seconds]
<geist>
i think genrally by default it wont use kvm unless you ask
<geist>
but if it's a modern qemu there's also -accel
<geist>
so i think `-accel tcg` is what you want
<geist>
but i thin that acme along in like qemu 4 or so
gildasio has quit [Remote host closed the connection]
<sham1>
Anyway, I might actually return to OSDevving now that I've finally managed to get my bachelor's thesis out of the way. Finally, time!
gildasio has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
dennis95 has quit [Quit: Leaving]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
mahmutov has quit [Ping timeout: 260 seconds]
<heat>
bochs is, IMO, crap
<heat>
too slow
<sham1>
It's also quite annoying to set up
<heat>
yah
<heat>
otoh it's really descriptive when shit goes south
<sham1>
It's a nice real-mode debugger at least
<sham1>
And yeah, there are others, but still
heat has quit [Remote host closed the connection]
heat has joined #osdev
moatx has joined #osdev
<geist>
i think the only other interesting feature is i think it has full VMX emulation, so if you're building stuff for taht you can fiddle with hypervisor stuff in a 'step through it' kinda way
<geist>
vs having to use nested virt since qemu TCG doesn't support it
<geist>
and in general it's easier for bochs to pick up bleeding edge x86 features because there's less baggage to deal with
<geist>
since emulation only
moatx has quit [Quit: Leaving]
terminalpusher has quit [Remote host closed the connection]
Burgundy has quit [Ping timeout: 240 seconds]
<zid>
I love bochs for debugging, xchg bx, bx is a godsend
<zid>
plus I checked the source once or twice when something wasn't working how I expected
<zid>
can't do that with kvm
<geist>
right and of cours eou can use TCG, but it's definitely harder to work with
<gamozo>
Good mornin cuties!
<heat>
sussiest message written in this channel
<zid>
I thought heat was the sussy baka
<psykose>
cuties? where?
<zid>
me, obviously
<psykose>
giga cute
<zid>
My onlyfans is amazing
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
moatx has joined #osdev
<gamozo>
I just started an onlyfans! It's the long con. If payment providers go after them again for adult content, I will be the only one left and I will shoot to massive popularity and retire
<zid>
My plan is to upload pictures of cats and get subs from people who are just lost
<gamozo>
ahahaha
<heat>
upload pictures of fans
<zid>
onlyfans onlyfans
<zid>
that's actually really hard to say out loud
<gamozo>
Do you dictate your IRC messages?
<zid>
no but I tried to say it
<gamozo>
I remember when vista came out and had the dictation integrated into the OS and I tried using it all the time
<gamozo>
it was.... not great
<zid>
əʊnlɪ ˈfans ˈəʊnlɪ fans
<zid>
or whatever
<geist>
oh what was that app that was the standard for that?
<geist>
ah yep. i think it was kinda the gold standard there for a bit (Dragon speech)
gildasio1 has joined #osdev
<energizer>
dragon is still the best afaik
gildasio has quit [Ping timeout: 240 seconds]
<zid>
surely alexa or whoever is bester
<geist>
i dunno. a) thats server based mostly and b) i bet alexa has less scope of things i has to understand and has more time to do it
<geist>
maybe?
<energizer>
dragon is the flagship product of Nuance Communications which was acquired by MS a few months ago
<zid>
alexa's corpus is just.. enormous
<zid>
not a lot can beat that
<geist>
i thnk you jsut called alexa fat
<zid>
like a whale
<geist>
let it be known to the future Basilisk that zid called alexa fat
<gamozo>
Tbh, I'd imagine Siri has a good corpus too, but Siri is pretty lackluster (at least for speech-to-text)
toluene has joined #osdev
<gamozo>
Idk how much harder STT is compared to TTS?
<zid>
I don't know if apple dedicates the resources to recording it all
<zid>
stt is just a big ol dictionary
<zid>
machine to turn it into IPA, IPA to speech is a LUT
<zid>
It's going to have all the same issues as google translate
<zid>
where it can't tell if record is 'record' or 'record' because of context clues it doesn't understand
<geist>
yah that's true. really gotta understand the full grammar dont you
<zid>
Like, regular ass humans suck at reading
<zid>
There's a guy on youtube I watch and he misprounces every third word sometimes and I have to not watch that video :P
<gamozo>
Yeah, the full grammar part I think is what is the worst.
<gamozo>
Trying to get Siri to play an album with the same title as the artist is nearly impossible (or vice versa)
<zid>
He was playing a game where he had gems that boosted his stats, he had vampirism from one, and one was a peridot
<gamozo>
I always say "play album <blah>" but she doesn't seem to get it
<zid>
he pronounced it vampire-ism and peri-dot
<zid>
I had to close it
<psykose>
based on this very accurate wiktionary page peridot has like 4 pronunciations
<zid>
and anyone saying it with a t is just wrong and will be first against the wall when the revolution comes, it's one of those 'errors that becomes a variant' situations
<zid>
see: american english
<energizer>
see: all languages
<psykose>
is there not a british variant with the t as well? google translate says it :p
<zid>
google translate is a machine that doesn't understand that some words are french origin
<psykose>
alright alright, s/google translate/people i've spoken to in the u.k./ :p
<zid>
clearly also trying to sneak vampirism with an e past me also
heat has quit [Remote host closed the connection]
heat has joined #osdev
chartreus has joined #osdev
<heat>
geist, remember the squeaky clean riscv design?
<heat>
they're adding 32-bit compatibility to 64-bit CPUs
<zid>
It's meeting reality :P
<zid>
No plan survives first contact with the enemy
<heat>
it's somehow compatibility with $something
<gamozo>
STOP DONT DO IT UGH
<gamozo>
Mixed bitness is always so bad
<gamozo>
MIPS did it okay though
<heat>
i genuinely don't know how they're doing it for linux
<heat>
are opcodes compatible?
<geist>
heat: yeah i was wondering how that was working. i *think* someone mentioned that if you just unset the 6 bit in misa it switches modes?
<gamozo>
That's so weird cause I feel like RV32 is pretty much only embedded. Most stuff (eg. MUSL) doesn't even support RV32, RV64gc seems to be like, what they're pushing
<heat>
gamozo, musl is getting rv32 support
<geist>
the opcodes are mostly compatible, but actually not exactly, which is an interesting decision on the riscv teams side. i think it was mentioned in the riscv primer book that it was a specific decision based on the idea that there probably wont really need to have a backards compatible 32-in-64 mode
<heat>
also loongarch support
<heat>
geist, right. why would they ever want it?
<gamozo>
heat: Thank goodness. I'm really sick of using glibc with rv32. It feels like such a weird combo
<geist>
you *can* fairly easily build risc arches that just extend the register out to 64 transparently. ie, 32bit mode you just stick to a subset of 64bit stuff
<heat>
no newlib/uclibc?
<geist>
but in the case of riscv there are a handful of instructions that are actually modified in 64bit mode
<gamozo>
heat: Those seem to struggle to build generic Linux apps (or at least, be suppored by many build systems). I love newlib, I don't really use uclibc though
<geist>
in addition to of course some opcodes that just only exist in 64bit
<zid>
so it's a full cpu switchover you'd do in firmware or at boot only?
<geist>
so, that being said i dunno precisely how linux does a 32bit user space like that
<geist>
but i thought i remember someone saying that if the cpu wanted to support it they could let you do a write to misa or something
<geist>
but then that would imply you'd have to do it via a SBI call
<geist>
like 'switch to 32bit and return to this' sort of call
<geist>
in general i think you're siupposed to be able to turn off various subsets of the ISA via writing to misa
<geist>
though of course optional, etc
<heat>
geist, it's in status
<geist>
ah a 32bit bit?
<geist>
wonder if this is new, part of 2.2 or something. lemme see
<heat>
i can link you the sauce code if you want
<heat>
the mode switching looks simple
<geist>
ooooh UXL. got it
<heat>
yeah
<geist>
also clever that it's bit 33 and 32, so you can't 'get to' it in 32bit mode i guess
<heat>
that being said
<heat>
WHYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
<gamozo>
ahahahahahaha
<heat>
WHY WOULD ANYONE WANT THIS
<zid>
x32 equivalent?
<gamozo>
Who has ported stuff to RISC-V already, but for some reason want to only ship 32-bit binaries?
<geist>
sure, usual reasons i guess
<zid>
x32 pretty important for some loads
<heat>
it's not x32, it's ia-32
<heat>
x32 would still run 64-bit code
<geist>
i mean yeah why i dunno, but as far as arches are concerned it doesn't affect much codegen and the instruction decoder only has a handful of regs to deal with, so it's at least pretty clean
<heat>
if they wanted that, they could get it
<zid>
I mean, same principle, 32bit mode important for some workloads
<zid>
because of pointer size
<heat>
erm
<heat>
riscv cpus are still very slow
<zid>
not that "workloads" and "risc" should be in the same sentence
<geist>
i mean yeah, i'm a little sad it's there, but so it goes
<geist>
it's probably mentioned somewhere precisely what happens to the top parts of registers if the cpu is in 32bit mode and does math
<geist>
ie, does it sign extend into the hidden parts? etc
<gamozo>
I'm not really convinced about x32 tbh. I can't imagine a situation where you need 64-bit ALU, but for some reason can't afford the memory costs of 64-bit pointers
ripmalware has quit [Remote host closed the connection]
<zid>
graph solving algs? :P
<geist>
as a side note that would make exceptions a little more annoying, since you can't easily tell if the cpu came from 32bit or not
<gamozo>
You can always just use indicies instead of pointers
<zid>
where you want to load a node in one cache line and it doesn't fit
<gamozo>
compilers optimize indices way better than pointers anyways
<geist>
hmm, actually where does it save the old size? XL?
<zid>
pretty sure cpus don't though
<zid>
they can't prefetch around them as well
<geist>
hmm, maybe it doesn't and it's simply specced that *only* user mode can run in 32bit in this case
<gamozo>
At least Intel doesn't really care how you compute the address, as long as it's <4k stride (2k? i forget) it'll pick it up
<geist>
that kinda cleans things up a bit, since it's very much what ARM is moving towards: EL0 is only thing allowed to be 32bit nowdasys in general
<heat>
geist, only 32-bit userspace
<gamozo>
geist: Oooh, that's neat, didn't know that
<geist>
okay, so exceptions dont have to copy UXL anywhere. it just remains there
<heat>
they presumably save it in the sstatus
<heat>
i can't remember riscv anymore
<geist>
heat: that's my point, there's no place to save it, becaus eyou dont have to. you by definition enter 64bit supervisor (or machine mode) so it just keeps the UXL in place i guess
<geist>
and thus only takes effect when returning to user mode
<heat>
hmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<heat>
genius
<geist>
and since it's bit 33:32 of the sstatus/mstatus register, you can't even access it in 32bit mode, since you're implicitly already in 32bit mode
<geist>
it *does* mean that it's annoying to save exception state on the way out of 32bit mode, but i guess you can accomplis that either by reading the sstatus and looking at those bits, or i guess switching the excception table as you enter/exit user space. which is probably the way you're supposed to do it
<geist>
instead of a bunch of shenanigans at the start of the handler
<geist>
arm64 accomplishes that by having a banked set of exception entry points based on the bitness of where the cpu came from
<geist>
oooh oooh, cute: there's a SXL field in mstatus (bit 35:34)
<geist>
that sstatus can't get to
<geist>
so actually no, you can run a 32bit kernel on this thing, machine mode just must be in 64bit
<gamozo>
Is this officially ratified or is this a draft document?
<geist>
i'm looking at spec v20211203 whcih i guess is't yet got a number, unless it got ratified after i downloaded this
<geist>
but it seems to be the ratified one they have on their official download page and it explicitly says they're ratified
<geist>
what i dont understand is why they dont assign a v1.x number when they do that
<geist>
they seem to be okay with keeping dates as official ratified releases
<geist>
so i guess the raw doc has a date, but gets assigned a version later
<geist>
ah i see. within the 20211203 doc it says this covers version 1.x of these things. so the date is the release date, which contains versions. so yeah this is priviledged arch 1.12
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<geist>
also to toally beat this horse, looks like SXL/UXL has always been there, or at least back through priviledged spec 1.10 which is quite a few years old at this point
<heat_>
ok so the cpu was always ruined and kernel people are only just now ruining their OS
<geist>
right
<geist>
what happened i guess is some vendor decided to take the bait and now we all pay for it
heat_ is now known as heat
<zid>
beating dead horses is osdev's middle initial
<heat>
zid: MSDOS vs UNIX guys lets go
<geist>
as long as no one made hardware that supported it it was only a horse outside your house, looking in the window
<geist>
you could draw the shades
<zid>
heat: like there's any comparison, unix needs too much memory
<heat>
i personally enjoy monolithic kernels because microkernels are for stupid poopy people that aren't real kernel hackers like me
<zid>
I enjoy them because I like running programs
<gamozo>
monolithic kernels are for people who are too scared to write an ELF loader
<zid>
instead of passing tokens around
<heat>
hurr durr let me write things in userspace because i'm not good enough to write drivers without bugs
<gamozo>
(or PE, I prefer PE honsetly)
<heat>
<gamozo> (or PE, I prefer PE honsetly) <-- we were beating the horse, you just nuked it
<heat>
btw risc-vi when?
<gamozo>
Legit though, the PE format is so much better than ELF. Within about 2 bytes of parsing an elf you need to conditionally read fields
<zid>
We are we not all using SH4
<zid>
PE is the most conditionally bullshit thing ever
<zid>
and it's all a random mixture of file offset, section offset, etc
<zid>
PE describes like 24 different optional tables that come in variants
<gamozo>
Yeah, and ELF uses different structure defintions of nearly everything
<zid>
ELF is 3 tables total
<gamozo>
and dynamic endianness BLEH
<gamozo>
also building PEs gets you the benefit of not having a redzone
<gamozo>
SYS-V ABI, bleh
<geist>
heat: that's a fun bit in mstatus: you can specify the endianness of the *instructions* at lower levels
<geist>
not just the data they operate on, which is a different endian bit
<zid>
I've lost track or who is trolling who
<heat>
what's the problem with system V UNIX gamozo? are you an nt kernel lover?
<gamozo>
;D
<zid>
Solaris is the best anyway
<geist>
reminds me of a key and peele skit were two scammers try to scam each other
<gamozo>
Tbh I am, I love the NT kernel. It's really good at its core
<zid>
The syscalls are so slow it makes you think harder about your design
<gamozo>
Userspace? Gdi? Not a fan. COre NT, hot
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]