Dead_Bush_Sanpai has quit [Ping timeout: 252 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
npc has joined #osdev
levitating has quit [Read error: Connection reset by peer]
levitating has joined #osdev
lynn_sh has joined #osdev
<lynn_sh>
hello. i tried making an account for the osdev forum and typed the special question's answer wrong. i redid it and it said i am flagged as a spammer. how do i handle this? it seems a bit over eager
levitating has quit [Ping timeout: 252 seconds]
<heat>
sortie, Mutabah: think you can do anything about this?
<heat>
it might not be possible because the oh so glorious chase is as unreachable as god himself
goliath has quit [Quit: SIGSEGV]
levitating has joined #osdev
lynn_sh has quit [Quit: Client closed]
lynn_sh has joined #osdev
xenos1984 has quit [Ping timeout: 272 seconds]
levitating has quit [Ping timeout: 248 seconds]
levitating has joined #osdev
<lynn_sh>
is there no hope to make an account now that it erronously flagged me?
levitating has quit [Remote host closed the connection]
levitating has joined #osdev
Turn_Left has joined #osdev
xenos1984 has joined #osdev
Left_Turn has quit [Ping timeout: 264 seconds]
levitating has quit [Ping timeout: 248 seconds]
levitating has joined #osdev
lynn_sh has quit [Quit: Client closed]
levitating has quit [Ping timeout: 248 seconds]
npc has quit [Remote host closed the connection]
hwpplayer1 has quit [Remote host closed the connection]
vai is now known as Jari--
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
netbsduser` has joined #osdev
Arthuria has quit [Ping timeout: 272 seconds]
netbsduser` has quit [Ping timeout: 244 seconds]
<j`ey>
does boch do bit perfect x87 emulation?
<nikolar>
What does bit perfect mean
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
<j`ey>
like exactly the same answers that hw would give? I meant to say x87 FPU
<j`ey>
for example fsin/fcos
<heat_>
oh h`ey j`ey
<heat_>
honestly dunno, possibly
<heat_>
if hw answers are even stable, which they probably aren't
<j`ey>
stable meaning across generations?
<j`ey>
of CPUs or?
<heat_>
probably uarchs
goliath has joined #osdev
<heat_>
i'm fairly sure floating point won't give you the exact same results on intel vs amd
<bslsk05>
​stackoverflow.com: c++ - Difference of floating arithmetics on AMD CPUs and Intel CPUs - Stack Overflow
<j`ey>
hmmm
housemate has joined #osdev
<j`ey>
context: porting some code that uses fsin/fcos inline asm, replacing that with calls to sinl/cosl doesnt work corectly
<heat_>
is this to arm, to another x86 cpu, ...?
<j`ey>
to arm
<heat_>
also ofc depends on the sin/cos implementation
<heat_>
all math libraries are distinct in lots of ways
housemate has quit [Max SendQ exceeded]
<j`ey>
yeah
<j`ey>
if you swap fsin for sin on x86, you also have the same issue
<heat_>
x87 is also long double, not double
housemate has joined #osdev
<zid`>
The ops are only specified to so many ULPs
<heat_>
j`ey, hmmmm arm doesn't have proper long double does it?
<heat_>
i think you're fucked buddy
<j`ey>
it has some form of long double at least cosl and stuff exist
<heat_>
glibc seems to make sinl() = sin() in those cases
<j`ey>
hmm
<heat_>
when in doubt open gdb and disasssemble sinl/cosl
<j`ey>
I was sure I got different results when using sin vs sinl :D
<heat_>
okay i can confirm my local libm.so.6 does seem to support long double
<heat_>
(i blame glibc's macro/build system soup for the unreadability)
<heat_>
in any case it uhhhhhh just might not be the same kind of long double, idk
<heat_>
you'd need to check whether anything breaks and why, and i honestly don't know what to do if it does break, i'm not a porting genius
<heat_>
you'd need to kindly email apple
<heat_>
HELLO ROSETTA X87 HOW THANKS
<zid`>
Good news, C doesn't give a shit how your floating point types work, so they could make it conforming with just sin = sinl, or they could do double double m ath
<j`ey>
maybe rosetta just calls sin too
<zid`>
and nobody can stop them
<j`ey>
and noone usually cares about some of the precision.. I need to figure out why this code seems to go wrong with it
heat_ is now known as heat
<geist>
yeah be careful about long double on arm64 too
<geist>
since that's 128 bit float that doesn't have support for
<geist>
so it'll fall back to software emulation
<geist>
at least if whatever the platform is using the standard abi
<j`ey>
yeah, just saw that
<heat>
in musl most libm functions are software emulated
<heat>
like sin() is straight up just domain reduction + a bunch of terms for a taylor series for cos/sin
<heat>
no fancy asm
benlyn has quit [Ping timeout: 248 seconds]
netbsduser` has joined #osdev
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
netbsduser` has quit [Ping timeout: 248 seconds]
housemate has joined #osdev
housemate has quit [Max SendQ exceeded]
Dead_Bush_Sanpai has quit [Quit: Dead_Bush_Sanpai]
<geist>
most newer architectures dont implement sin in hardware anyway
<geist>
especially with vectors, there's a vector based algo that probalby does the taylor series
<zid`>
I miss fsin but I don't give a shit about 80bits of precision and yea, you can get 32bits worth for like, 3 rounds of a fast algo
<zid`>
so the 100 cycle latency is pretty eatable :P
<heat>
is that because hardware sin sucks, or is it because newer architectures are all RISC-y?
<geist>
i think the latter. fairly certain SSE and AVX dont have sin/cos, and never will, so that decision was made back in the 90s (for x86)
<zid`>
x87 was great for its time, but the way it's implemented just doesn't gel well anymore
<zid`>
it was wide because 'science accelerator' and stack based 'because you can write a fortran compiler for x87 in 2 days'
<heat>
what makes it so hw sincos sucks but sqrt is good?
<zid`>
big 80bit tables but compressed down to be smol so they get funkily processed is my guess
<zid`>
the fast iterative methods are both new, and need you to have more than the register size of state hanging around
<zid`>
sin_r
<nikolar>
Doesn't the same go for sqrt
<nikolar>
To be fair, floats suck either way
<zid`>
sqrt has had fast approximation methods for a longer time, so the latency is only 50 :P
<zid`>
You have to figure out what was hot research to put into silicon in 84 when it was designed :P
<nikolar>
Kek
<nikolar>
Do all of your math in fixed point
<heat>
INTS
<heat>
be a good boy, be like C, default to int
<heat>
8-bit math? promote to int. 16-bit math? promote to int. load a 64-bit constant? don't forget the suffix or you'll silently truncate to int
<heat>
0.0f? more like 0
<zid`>
0.0d
housemate has joined #osdev
<heat>
ok i had to test this but im so sad 0.0f is not a valid null pointer constant
<heat>
can we ask the owo guy to fix this
<zid`>
lol
<zid`>
octal only I'm afraid
<nikolar>
Lol
theruran has joined #osdev
<nikolar>
He's too busy adding more uwus into the standard
<heat>
uwu nuww pointew dewefewence is a fucky wucky
<heat>
wundefined behaviow
netbsduser` has joined #osdev
<nikolar>
Kek
netbsduser` has quit [Ping timeout: 252 seconds]
<froggey>
sqrt is one of the well-specified operations, you'll get bit-identical results across all IEEE-compliant implementations, so maybe there's some incentive for a hw impl there
gildasio has quit [Ping timeout: 264 seconds]
<froggey>
along with add/sub/mul/div. not true for anything else afaik
gildasio has joined #osdev
housemate_ has joined #osdev
housemate has quit [Ping timeout: 248 seconds]
<childlikempress>
fma
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
fma deeznuts
<kazinsal>
I for one do not want the verb "fuse" to be anywhere near my nuts