<Matt|home>
well.. this certainly speaks to my talents as an author. i wrote a partial tutorial/explanation on virtual address translation years ago, and going back and re-reading it i sure as hell have no idea what the hell i wrote
bauen1_ has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
cyberbanjo has quit [Remote host closed the connection]
cyberbanjo has joined #osdev
srjek|home has quit [Ping timeout: 260 seconds]
bradd has joined #osdev
moberg has quit [Ping timeout: 255 seconds]
moberg has joined #osdev
smach has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
found a nice user-curated z80 manual on their web site on mastodon today
<geist>
apparently he has 6502 stuff too. it's a nicely organzied read if you're interested
<bslsk05>
Note by Peter Mount: "Yesterday I posted about my Open Source 6502 assembly book.  Today it's the good old Z80's turn.  It cover's all of the official Z80 instructions as well as the undocumented o[…]"
<bslsk05>
Note by Peter Mount: "Yesterday I posted about my Open Source 6502 assembly book.  Today it's the good old Z80's turn.  It cover's all of the official Z80 instructions as well as the undocumented o[…]"
bgs has joined #osdev
dude12312414 has joined #osdev
bgs has quit [Remote host closed the connection]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
heat has quit [Ping timeout: 248 seconds]
Avaflow has joined #osdev
mcf has joined #osdev
epony has quit [*.net *.split]
pie_ has quit [*.net *.split]
vancz has quit [*.net *.split]
eschaton has quit [*.net *.split]
nanovad has quit [*.net *.split]
zhiayang has quit [*.net *.split]
wgrant has quit [*.net *.split]
Starfoxxes has quit [*.net *.split]
nur has quit [*.net *.split]
_xor has quit [*.net *.split]
koolazer has quit [*.net *.split]
fkrauthan has quit [*.net *.split]
dminuoso has quit [*.net *.split]
Mutabah has quit [*.net *.split]
colona has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
amj has quit [*.net *.split]
doppler has quit [*.net *.split]
troseman has quit [*.net *.split]
meisaka has quit [*.net *.split]
j`ey has quit [*.net *.split]
ozarker_ has quit [*.net *.split]
pbx has quit [*.net *.split]
andreas303 has quit [*.net *.split]
pg12 has quit [*.net *.split]
MuonNeutrino has quit [*.net *.split]
LambdaComplex has quit [*.net *.split]
Bitweasil has quit [*.net *.split]
acidx has quit [*.net *.split]
Beato has quit [*.net *.split]
warlock has quit [*.net *.split]
truepassion has quit [*.net *.split]
kanzure has quit [*.net *.split]
riverdc has quit [*.net *.split]
kanzure has joined #osdev
j`ey has joined #osdev
dude12312414 has quit [Remote host closed the connection]
Beato has joined #osdev
andreas303 has joined #osdev
zhiayang has joined #osdev
vancz has joined #osdev
pie_ has joined #osdev
riverdc has joined #osdev
fkrauthan has joined #osdev
mcfrdy has joined #osdev
nanovad has joined #osdev
Bitweasil has joined #osdev
dminuoso has joined #osdev
ozarker has joined #osdev
dude12312414 has joined #osdev
MuonNeutrino has joined #osdev
amj has joined #osdev
doppler has joined #osdev
LambdaComplex has joined #osdev
eschaton has joined #osdev
Mutabah has joined #osdev
meisaka has joined #osdev
koolazer has joined #osdev
acidx has joined #osdev
colona has joined #osdev
troseman has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
cyberbanjo has quit [Ping timeout: 260 seconds]
vdamewood has quit [Read error: Connection reset by peer]
<zid>
I've just woken up, someone explain how this is okay
<j`ey>
which bit?
<j`ey>
the "?:" ?
<j`ey>
or just how it's kinda obscure?
LostFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
PapaFrog has joined #osdev
zaquest has quit [Remote host closed the connection]
<Mutabah>
`?:` feels like a compiler extension? didn't think it was valid C
<GeDaMo>
Does it default to 0?
<j`ey>
a ?: b == a ? a : b
<Mondenkind>
yeah it's a gnuc thing
<j`ey>
linux doesnt care :P
scaleww has quit [Quit: Leaving]
epony has joined #osdev
vdamewood has joined #osdev
jimbzy has joined #osdev
xenos1984 has quit [Quit: Leaving.]
xenos1984 has joined #osdev
nyah has joined #osdev
bradd has quit [Ping timeout: 248 seconds]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
smach has quit [Ping timeout: 248 seconds]
xenos1984 has quit [Quit: Leaving.]
dude12312414 has joined #osdev
srjek|home has joined #osdev
xenos1984 has joined #osdev
Burgundy has joined #osdev
scaleww has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
orthoplex64 has quit [Read error: Connection reset by peer]
orthoplex64 has joined #osdev
terminalpusher has joined #osdev
gildasio has quit [Ping timeout: 255 seconds]
gildasio has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.7.1]
ThinkT510 has joined #osdev
heat has joined #osdev
wand_ has quit [Ping timeout: 255 seconds]
wand has joined #osdev
night_ has quit [Quit: goodbye]
night has joined #osdev
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
bgs has joined #osdev
dude12312414 has joined #osdev
gog has joined #osdev
<zid>
Remembered to check ebay, got me some cheap ram inc
<gog>
nice
<zid>
I now have 32GB instead of 24GB I guess, and I can run it at 866 instead of 800
<zid>
without it counting as an overclock, anyway
<zid>
I know the 866 I have will run at 1GHz without any extra voltage already
carbonfiber has joined #osdev
ids1024 has quit [Quit: WeeChat 3.2.1]
wootehfoot has joined #osdev
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
wand has quit [Ping timeout: 255 seconds]
wand has joined #osdev
gildasio has quit [Ping timeout: 255 seconds]
gildasio has joined #osdev
tacco has joined #osdev
jafarlihi has joined #osdev
<jafarlihi>
Is notion of FIRST and FOLLOW sets the same regardless of whether you are making a LL or LR or SLR or LALR parser? Are they calculated differently?
bgs has quit [Remote host closed the connection]
* kof123
.oO( if only there was a #proglangdesign channel )
<bslsk05>
dougallj.wordpress.com: Why is Rosetta 2 fast? | dougallj
<geist>
interesting quick examination of how it translates things
<geist>
i think the gist is: it's not that sophisticated a translator, but the M1 has some assist instructions and is fast as shit, it runs x86 code pretty well with a simple 1:1 translator
<heat>
oh yeah just saw it today
<geist>
aso things like having enough registers (31) to hold the entire x86 register file at once is a big win
<heat>
does it emulate avx-512?
<mrvn>
x86 or x86_64?
<j`ey>
_64
<heat>
i bring the real questions
<geist>
no of course not, but then the previous intel cpus they shipped didn't either
<geist>
so theres no real need to, since they only have to emulate existing x86 cpus
<geist>
existing macos x86 code that is
<geist>
that being said M1/M2 dont have 256 bit vectors, so i guess they have to jump through hoops for avx2 emulation
<mrvn>
I wonder if you can actually assign fixed register mapping between x86_64 and aarch64 registers and have enough left over to emulate opcodes the arm doesn't have.
<geist>
but that's fascinating more than anything else is the instruction extensions they have to better assist with edge cases, like differences in how the carry flag is calculated
<geist>
or the extra 2 flags x86 has, or the way shifts rotate into and out of bits that ARM doesn't do, etc
<geist>
so they have extension instructions to assist with that
<heat>
what cpuid signature does it report, intel?
<geist>
mrvn: it doesn't emulate, it does a straight translate
<geist>
presumably there are special cases (liek cpuid instruction) that cause it to dump the register state and call out into some helper routine
<mrvn>
geist: but not every instruction can be mapped 1:1 to an arm instruction. Some will need multiple instructions or function calls
<geist>
heat: i'm sure. probalby just some random haswell or whatnot
<geist>
mrvn: oh no i mean 1:1 as in 'for every x86 instruction it generates one or more arm instructions'
<geist>
but as in it does a translate
<geist>
1:N I guess
<geist>
what the page says makes sense is it always puts the ARM translated version of the binary just after the main one in main memory, so it can generate static references back to the data and bss segment in the original
wand has quit [Ping timeout: 255 seconds]
<geist>
seems like the tricky stuff would be dealing with x86 constructs like a branch table in the middle of the text or whatot
<geist>
or any sort of PC relative dynamic branch shenanigams. there's some sort of lookup table opcode on x86 i forget
<gog>
hi
<geist>
gog!
* geist
pets the gog
<mrvn>
geist: or doublethreading code so you have 2 programs just at an offset
* gog
prr
<mrvn>
jumping into the middle of an opcode realy screws with ahead of time translation
<geist>
mrvn: i dont think you can do that easily, since the code size is going to be different between the two arches, even if you just could go a 1:1
<geist>
arm64 tends to be somewhat larger, in my experience. like 30%
<mrvn>
geist: you can't do it at all on arm since opcodes have to be aligned.
<geist>
right. that too
<mrvn>
well, arm64. I think you can misalign the PC with thumb instructions.
<geist>
no thumb in arm64
<mrvn>
exactly
<geist>
you can still try to indirect branch to an unaligned address
<geist>
but it generates a trap
<mrvn>
They ported factorio to arm and a big problem was the FPU giving different results.
wand has joined #osdev
<geist>
they're pretty close. both ieee754, but i thin there are different rounding modes and whatnot
<geist>
ie, theyre both valid implementations so factorio must be relynig on some edge cases
<mrvn>
I wonder how much simpler that would have been with the M1 fpu extension that makes it behave like x86 exactly
<geist>
gosh if only you just read the link i pasted
<mrvn>
geist: fast-math flag and such
<geist>
yeah
<geist>
kinda interseting i wonder how they generate a div by zero fault in rosetta
<mrvn>
"One exception is the handling of the different possible bit patterns underlying NaN values, and another is whether tininess is detected before or after rounding."
<geist>
does it make a syscall that says 'oops i generated a zero'
<mrvn>
doesn't arm trap on /0?
<geist>
or i wonder if they have a 'div by zero' exception M1 fit
<geist>
nope.
<geist>
nor does riscv. i think that's fairly unique to x86 (or maybe 68k, i forget)
<mrvn>
I'm sure the M1 extension has that covered
<geist>
might be another control register bit to generate a trap
<geist>
anyway, i suspect only apple has the clout to get ARM to bend on these sort of extensions
<geist>
and/or a ridiculous amount of money exchanged hands
<geist>
normally ARM is very strict about extensions like this since they dont want the arch to fragment
<mrvn>
geist: did they make those official ARM extensions?
<geist>
perhaps. at least the user space ISA stuff. it mayb e the reason a bunch of these seemlgly 'one off' extensions exist
<mrvn>
"There’s a standard ARM alternate floating-point behaviour extension (FEAT_AFP) from ARMv8.7, but the M1 design predates the v8.7 standard, so Rosetta 2 uses a non-standard implementation." wow
<geist>
ie, if apple adds a user ISA extension maybe ARM forced them to become a ARM standard feature
<sbalmos>
oof
<geist>
that would make sense.
<geist>
also maybe it's possilbe these user extensions are disdabled with a control flag for non rosetta processes
<geist>
also a thing i could see ARM trying to force them to do, so they dont become standard defacto non standard instructions for general code
<mrvn>
It really makes sense when you want to port numeric apps from x86_64 to arm. They are hellishly fragile at some stages of the computation and you want the same results.
<geist>
yah and all the flag computation and manip stuff
<geist>
the page mentions that a bunch f those have real features around them, described as 'javascript' compatibility
<mrvn>
TSO sounds helpfull too
<mrvn>
Without TSO you would have to add a ton of memory barriers in the translation.
<geist>
yep. also note i think this is precisely why M1 supports 4K instructions (other high A* apple cpus used in ipods/etc dont)
<j`ey>
FJCVTVS
<geist>
purely for x86 compat
<j`ey>
4k page size
<j`ey>
*FJCVTZS
<geist>
j`ey: you need help there?
<j`ey>
Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero.
<geist>
ah yeah. as the person pointed out here javascript == x86
<geist>
but actually the fixed point stuff looks like not x86
<mrvn>
geist: I wonder how they handle jumps to computed addresses. They get the address of the original opcode and then have to find where that ended up after translation.
<geist>
but then i dont know details of FPU that much except as what an OS has to worry about (saving context, exceptions, etc)
<geist>
mrvn: yeah exactly
<geist>
anyway so it begins: got a solid block of about 4 hours of meetings today
<geist>
meeting thursday!
<mrvn>
It's 10 at night. More like Kindle time.
wootehfoot has quit [Quit: pillow time]
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
<vin>
Hi, I am trying to estimate total disk traffic in a hypothetical scenario. Where in a column-major store which has two realtions: 1 billion tuples in A(p,q,r) and 5B tuples in B(l,m,n). Both reside on the disk and each attribute is of 4 bytes. Assuming sufficient memory capacity exists, what will be the disk IO trafic for performing this join "SELECT p,q,l,m FROM A,B WHERE A.p=B.l;"
<vin>
So I am expecting it to be, 32GB of total I/O traffic. 4GB to gather A.p and 20GB to gather B.l and finally 8GB to gather both A.q and B.m (because only 1B tuple data required after join). Is that correct?
<geist>
uh! is this a homework question
<geist>
it seems oddly generic in that way that nothing in the real world would ever talk