<geist>
zen 4 guide? i ust googled for it, first hit
<geist>
zen 4 optimization guide
<mjg>
so i'm gonna see about doing a full build
<mjg>
but it is going to take quite some time
<heat>
geist, yeah found it, thanks
<geist>
ah interesting, the reason gcc did your code efore where it used rip relative into a register, then tested it, then conditionally branched may be because:
<heat>
it agrees with the intel manual and says that for cmp/alu + branch the flag-writing instruction may not use rip-relative addressing to get fused
<geist>
for instruction fusion to happen: "• The flag writing instruction cannot use rIP relative memory addressing."
<geist>
ie, the `cmpl 0, 0[rip]` style thing clang did is a bad instruction
<heat>
yes, intel said the same thing
<heat>
yep, clang is wrong there
<moon-child>
oh huh
<moon-child>
I guess that's because for fusion it wants to use the rip of the branching instruction
<heat>
O0 was actually more correct than O2
<mrvn>
is that fusion a new thing?
<heat>
clang played itself
<geist>
that implies to me maybe it's using the ALU to compute the address maybe?
<geist>
and thus steps on its own toes to get the flag results
<geist>
moon-child: oh yeah thats true too!
<geist>
actually that's probably it, the notion of what the RIP is is a bit more funky in a fused instruction sequence
<mrvn>
geist: you don't think it has dedicated adders for address computations?
<geist>
the uop cache probably stores a fused instruction at the start of the first of them
dude12312414 has quit [Remote host closed the connection]
<moon-child>
I guess there's some subtlety because if the memory access faults you do have to point at the comparison op
<geist>
and thus can't easily reconstruct the RIP on subsequent runs
<moon-child>
even when not rip-relative
<moon-child>
but that's off the fast path, so presumably easier to handle
<gog>
hi
<geist>
well, he compariso op wouild still be the base of the fusion
<geist>
so no info loss there
<geist>
it'd be if it needed to fault at the base of the branch, which it shouldn't be able to for normal instructoin reasons
<geist>
so my guess is as it's running uops the RIP of thenext instruction is basically 'free' because it's part of the instruction dispatch mechanism
<geist>
but it only makes sense if it's at the boundary of the original instruction
<geist>
mrvn: re instruction fusion, that goes way back, though i dont remember precisely when it started showing up on x86 hardware. maybe late p4 era? core 2?
<geist>
and dunno when amd got it
<geist>
moon-child: it does beg the question what happens if an irq fires in the middle of a fused instruction, or if you have a single step debug going on, or even an instruction-address-match in the debug hardware
<geist>
that has to throw a huge wrench in it
<mrvn>
what actually gets fused? The cmp and branch?
<geist>
yah
<geist>
even on modern ARM hardware the optimization guides tell you what compare and branch instructions are fused
<mrvn>
my guess would be that those turn of fusing
<moon-child>
irq I would guess you just finish the fused op first
<geist>
and also in ARM64 a sequence of address synthesis instructions can be fused to a single cycle
<moon-child>
single step debug is more interesting though. I wonder how that's implemented
<heat>
if (single-step) dont_fuse()
<geist>
ie, `adrp + add` to synthesize a 64bit address gets fused into a single 64bit immediate load in arm64
<moon-child>
maybe it rigs the decoder to inject an interrupt instruction after the next instruction or something?
<mrvn>
moon-child: in the olden days the debugger would replace the next opcode with a BRK opcode.
<moon-child>
what if it's a branch?
<mrvn>
moon-child: the destination of the branch in that case. for conditional both targets
<geist>
but this knowledge of what gets fused does matter of course, because you want to avoid breaking up the sequence, even if it would othrwise be a good idea (ie, adding space between two instructions that depend on each other0
<mrvn>
that's quite ugly when it changes.
<moon-child>
performance ain't portable
<heat>
and you want to encourage these sequences too
<heat>
cough cough clang
<geist>
it'll be interesting to see what happens when folks start to build really high end riscv implementations and if fusion there will become register specific
<heat>
why register?
<geist>
ie, are you supposed to use t0 when synthesizing an address, and only if you use that register can it fuse it, etc
<mrvn>
with t0 being the temp register?
<geist>
in the case of conditional stuff the condition bits are written back to a GP register, so if you dont want the sequence to have any side effects you need to arrange for it to be overwritten
<geist>
so i've seen for example the standard sequence of using ra instruction to compute the address of something you're about to branch to
<moon-child>
I swear, riscv is going to implement uarchitectural flag renaming :^)
<clever>
if a spec lacks instruction timing (not an mcu), then i can see how risc-v can have vastly different performance ratings, a naive implementation would just be 1 clock per opcode flat
<geist>
which then has the effect of overwriting the result register
<clever>
and more complex opcodes then impose a freq limit
<geist>
but yeah in riscv a common pattern would be something like 'slt + beq'
<mrvn>
Somehow I feel this fusing is cheating. For riscv why do risk when you want complex instructions (except encdoded as multiple risc opcodes)? On x86? It's CISC, why not have fused opcodes?
<geist>
with a trashed register. you *could* for example do something cute like 'based on which t register you used, hint prefer taken or not'
<mrvn>
I hate cpus that don't have general purpose registers. Even if it's only that some registers will be slower.
<geist>
mrvn: well you'd ove riscv sicne it's the exact opposite of arm64 in that regard
<geist>
only GP registers, nothing else
gxt has quit [Remote host closed the connection]
<mrvn>
not even stack?
<geist>
not even stack
gxt has joined #osdev
<mrvn>
I like that ARM doesn't have a hardware stack register, only a convention.
<geist>
i forget the raw code sequence to get a copy of the current PC. but there's a pair of address calculation instructions, so probably something like 'adr x1, 0(pc)' or soemthing
SpikeHeron has joined #osdev
<mrvn>
PC isn't a general purpose?
<geist>
no
<geist>
more importantly it's not even a register. it's simply PC
<mrvn>
They tried that on ARM but there are a bunch of things you can't do with the PC. Architectually it's a bad idea to have the PC as general purpose register.
bch has joined #osdev
<geist>
yah they copied that from DEC systems, which tended to do that
<geist>
ie, r7 on pdp-11 and r15 on vax
<mrvn>
Seems so nice to just have "add pc, pc, #40" to jump somewhere. But building that into the gates gets more complex.
<mrvn>
return from function? pop pc
<geist>
ah 'auipc' instruction on riscv is how you can read the current PC if you wanted to
<mrvn>
You should never need that. Except once at program start to relocate your code. :)
<clever>
one trick ive seen somewhere (i think in arm), was to `bl foo:` and just `foo:` on the very next line
<clever>
and now the addr of foo, is in `lr`
<geist>
right, which on anything halfway modern is terrible
<geist>
that's what you hd to do in i386
<mrvn>
That's the x86 way
<clever>
the branch prediction cant deal with that?
<geist>
and it fouls up the call stack sinc eyou have an unbalanced call/ret
<geist>
on i386 the solution is to call a little routine that reads the IP off the stack, then rets
<clever>
but on arm, it doesnt touch the stack, so you can abuse it like that?
<mrvn>
you can "bl get_pc" and make it a function with ret
<geist>
no, the little optimizatoin in modern cpus that it uses to branch predict through the ret
<geist>
so yeah it breaks the branch predictor
<mrvn>
given the use case is to relocate your binary does that matter?
<geist>
even riscv has a trick there, since ther'es no real ret instruction, just a `jal ra` but it says pretty specifically that if you indirect through 'ra' it should treat it like a function return
<geist>
whereas if you use another register like t0 it should treat it as a regular indirect
<clever>
the weirdest use of lr that ive seen is the centurion cpu6, where you basically have `ld r0, [lr++]`
<clever>
and the ABI expects args to immediately follow the call/bl opcode
<geist>
so they're leaving it such that the branch predictor can guess a bit based on the register you're using to what you intend to do
<geist>
yah args after call are not that odd in older machines. bnchs was just saying they were working on a 68k machine that puts the args just after the trap instruction
<geist>
probably a pretty similar sequence on 68k
<bnchs>
yeah this is only for a specific OS for the 68k
<clever>
and something i read about recently, that changes how i view 6502, is that the 0-page is treated like 256 bytes of registers
<mrvn>
They stopped doing that when memory protection (MPU or MMU) was added.
<geist>
an even older technique you see in machines where there was no hardware stack was to spill registers just before (or after) the call instruction
<mrvn>
clever: the 0-page has extra, shorter, opcodes to access.
<clever>
yeah
<geist>
basically just dump spilled regs right there in the text seqment. doesn't let you recurse but at least gives you functions
<clever>
previously, i hadnt thought about abusing 0-page like that
<mrvn>
ouch.
<clever>
i was thinking more in modern terms, where you overflow into the stack frame
bgs has joined #osdev
<mrvn>
that is a major speed difference.
<clever>
which is why i basically never did 6502 asm :P
<geist>
yah 0 page it's quite frequent to set up a bunch of global arg registers there too for whatever binary you have.
<mrvn>
Now what would be really nice is if you could set a base address for the 0-page.
<geist>
ie, load the X Y of your drawing routines into some dedicated 0 page regs then jsr blit
<geist>
mrvn: 6809 which is the successor to the 6800 that 6502 qwas kinda a fork of has exactly that
<zid>
It's like a 256 element shadow stack calling convention :P
<clever>
i recently went over the schematics for the vic20 and c64, and found drastic design differeneces
<geist>
an 8 bit register that lets you set the 'direct page' which is what i think 6800 called it
<mrvn>
kind of makes is random-access stack
<geist>
actually now that i think about it 6800 may have had a relocatable direct page too
<clever>
the vic20 does address decoding entirely with dumb logic gates, and a few 3bit -> 8pin decoders
<geist>
but 6502 was intended to be super super simple
<zid>
apollo AGC had a call and change memory bank instruction which is cool
<clever>
while the c64 has bloody dram, and all address decoding in one magic black-box
<geist>
fun thing that z80 does to assist with that: during dead cycles while the cpu is doing work it tosses out an incrementing address on the bus so the dram refresh logic ca use it
<geist>
there's an internal counter in the cpu that's always running
<geist>
actually i find it to make it kinda a nightmare to debug one with a logic analyzer since it's just continually throwing stuff on the bus
<clever>
the PLA on the c64 seems to handle both dram refresh, and generating ras and cas cycles to the dram, when the addr targets ram
<clever>
the other major difference i noticed, was just how the ram is handled
<mrvn>
long live sram and vram.
<clever>
vic20, just had a heap of 1024 x 4bit sram chips, and later models bodged some 2048x8bit chips in, with an OR gate to join bank/chip selects
<clever>
but the c64, just has a pair of 64kb x 4bit drams, 8bit row, 8bit column, 4bit data
<geist>
one of the countless 'build an 8 bit breadboard machine' folks on youtube is doing a very detailed z80 based machine and he refused to just use a gigantic modern SRAM and actually has a board set up for the dram logic in TTL
nyah has quit [Quit: leaving]
<geist>
kinda interesting
<geist>
but he's almost way too detailed to be interesting
<geist>
https://youtu.be/GMS8MQHRRyg a good sequence if yo have infinity time to watch it and want to listen to a droning british guy go on forever
<bslsk05>
'Designing A Z80 Computer Part1' by Jerry Walker (00:45:08)
<geist>
apologies if one of you is this guy
<geist>
note the firt one is 45 minutes long
<geist>
he's on part 23 now...
<clever>
heh
<mrvn>
geist: I'm more interested in building the cpu than the stuff around it.
bch has quit [Ping timeout: 260 seconds]
bch has joined #osdev
zaquest has joined #osdev
energizer_ is now known as energizer
bch has quit [Ping timeout: 252 seconds]
bch has joined #osdev
* geist
nods
<geist>
mrvn: you like amiga, this might be a fun read
<bslsk05>
fabiensanglard.net: The polygons of Another World
bch has quit [Ping timeout: 252 seconds]
bgs has quit [Remote host closed the connection]
<mrvn>
"With a rate of 4,000 bytes per milliseconds, blitting the BKGD buffer at the start of each new frame took "only" 8 ms." Copying memory has come a long way.
<mrvn>
geist: I wrote a flight simulator for m68k with generated landscapes. flat shaded 3D scenes are fun with hardware.
<geist>
yah a fairly beat up a500 just went up for sale locally that i'm resisting the urge to get
<geist>
it being PAL helps a lot
<geist>
a 1040st went up for sale last week that i resisted the urge
<geist>
but it was also pretty pricey. i'd rather get an a500 or a1200
<mrvn>
you can buy an A4000 board and chips.
<mrvn>
I also love the hack to connect an RPi to the Amiga bus.
<clever>
mrvn: the drivers in emu68 are an even bigger hack
<clever>
the rpi mmio, is mapped into the guest addr space, and m68k asm pokes rpi registers!
<mrvn>
I'm talking about the boards that connect the RPI GPIO pins to the amiga bus and makes the rpi the cpu card for the system.
<clever>
yeah
<clever>
emu68 uses that board as well
<mrvn>
It's fun to see that modern CPUs can bit-bang the main systems bus with a bit of extra logic to get the timing exact.
heat has quit [Read error: Connection reset by peer]
gxt has quit [Ping timeout: 255 seconds]
heat has joined #osdev
<clever>
mrvn: the hardest part, is that the fpga doesnt really have enough cycles to over-sample the rpi bus, so it needs to be clocked by the rpi, and sample on the right edge of that clock
<clever>
the whole thing is being pushed to the limit
<mrvn>
you could always get a faster fpga
gxt has joined #osdev
<mrvn>
I imagine an A4000 cpu card would need something better
craigo has joined #osdev
craigo has quit [Client Quit]
weinholt has quit [Ping timeout: 260 seconds]
weinholt has joined #osdev
[itchyjunk] has quit [Ping timeout: 252 seconds]
[itchyjunk] has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
Dyskos has joined #osdev
smach has joined #osdev
smach has quit [Ping timeout: 248 seconds]
GreaseMonkey has quit [Quit: No Ping reply in 180 seconds.]
<Iris_Persephone>
I'm actually considering using Rust
mctpyt has joined #osdev
mctpyt_ has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
heat has quit [Remote host closed the connection]
heat has joined #osdev
mctpyt has quit [Ping timeout: 248 seconds]
<geist>
well, i'd say it might make sense to be pretty proficient in rust already before trying to write an os in it
<geist>
OTOH, yolo!
<Iris_Persephone>
eh I'm about as proficient in Rust as I am in C :p
xenos1984 has joined #osdev
<zid>
..could you write an OS in C? :P
<Iris_Persephone>
not _yet_
bch has joined #osdev
<geist>
hey if you realize it's a challenge and are willing to take it on, SGTM
<Iris_Persephone>
well yeah, obviously this is going to take years
<Iris_Persephone>
but the journey of a thousand miles starts with a single step and all that
<kof123>
i still feel spite is underrated
<Iris_Persephone>
hmm?
<kazinsal>
geist: hey, have you ever replaced any of the caps on your vax?
<zid>
I'd just immediately start taking the steps, if it interests you
<kof123>
i think k lange said once he was doing something out of pure spite lol
<kazinsal>
I was fiddling around with some stuff on mine last night and then it shut off followed by the unmistakable smell of a capacitor giving up the ghost
<kof123>
just tips from veterans lol
<zid>
you won't know what the fuck you're doing until you fail to do it
<kazinsal>
wondering if the power supplies on those things tend to go after thirty some odd years
<mjg>
people claim failure is great because they fail!!
<mjg>
true sigmas redefine goals to claim success
smeso has quit [Quit: smeso]
<Iris_Persephone>
programming out of spite is fun, I was so fed up with my MIPS courses that I reimplemented the whole thing in Python just to prove how east it is
<mjg>
corp 101
<Iris_Persephone>
s/east/easy
<mjg>
thta's some 'nice guy' thing to do mate
<Iris_Persephone>
MIPS is surprisingly fun as assembly goes actually
<Iris_Persephone>
okay well not
<Iris_Persephone>
like
<zid>
because everybody loves delay slots
<zid>
and load delay slots
<Iris_Persephone>
all of MIPS in Python or whatever, just the program we were doing
<mjg>
sparc moment!
<zid>
cringe r.r. mips
<sham1>
Ugh, Python is just the pits
<Iris_Persephone>
hey I didn't choose it the uni did
<Iris_Persephone>
and Python was the language I was most familiar with
<zid>
yea everybody seems to use mips, that's what riscv was designed to do
<zid>
replace mips in all those courses
<zid>
then you wouldn't have issues trying to find vhdl or whatever
<zid>
Like, I have a riscv logisim file, it's tiny and you could teach people with it
<Iris_Persephone>
we're using MARS because this course is supposed to be "baby's first assembly code"
<zid>
yea it's either MARS or SPIM
<zid>
##asm gets a lot of people asking HOW PRINT NUMBER?
<zid>
because it has a print string swi
<zid>
but they have no idea how to build a string, and how to implement sprintf %d
<zid>
so I am at least vaguely familiar with them
Vercas has joined #osdev
smeso has joined #osdev
<Iris_Persephone>
hold on isn't it just syscall with your number in $a0 and the code 1 in $v0
<zid>
They have print string, they don't have 'print number' and don't realize it's possible to have a) non-mutable strings b) format numbers into strings
<zid>
d) enough knowledge of mips to know division gives you the remainder, which you can use to implement it
<kof123>
yeah it was tongue in cheek, "this sucks so bad i can do better" is a start of some things
<kof123>
*but "..." is how some things start
heat has quit [Remote host closed the connection]
heat has joined #osdev
<zid>
spim has print_int it seems at least, maybe it was MARS that didn't only
Vercas has quit [Client Quit]
<Iris_Persephone>
what's the point of pseudoinstructions in a course that's designed to teach you how processors work on the low level
Vercas has joined #osdev
<zid>
The problem is how broad of a knowledge base you need to actually produce meaningful output
<zid>
where you can actually do the assembly part
<zid>
you ideally need to do away with assemblers, linkers, execution environments, mathematics, etc
<zid>
I've seen a *lot* of people say "I am learning asm, how do x?"
<zid>
and the next 8 hours are teaching them number theory and binutils instead
<Iris_Persephone>
kof123: knowledge is knowing that what you're going to make is shit. wisdom is doing it anyway
<Iris_Persephone>
oh god not binutils
Vercas has quit [Client Quit]
Vercas has joined #osdev
Arthuria has joined #osdev
<sham1>
At least number theory is useful
<zid>
It's number theory they were already taught when they were 10 but just forgot, to be fair :P
<Iris_Persephone>
what like
Vercas has quit [Client Quit]
<zid>
place value
<Iris_Persephone>
binary versus decimal representations?
<Iris_Persephone>
oh god
<Iris_Persephone>
that's even worse
<zid>
123 is one hundred, two tens, and three ones
<zid>
once you internalize that, you can write sprintf %d
Vercas has joined #osdev
<Iris_Persephone>
is this in the concept of significant bits
<Iris_Persephone>
s/concept/context
<sham1>
Significant decimal digits
Arthuria has quit [Remote host closed the connection]
bch has quit [Ping timeout: 255 seconds]
bradd has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
bauen1_ has joined #osdev
bauen1 has quit [Ping timeout: 255 seconds]
Iris_Persephone has quit [Ping timeout: 255 seconds]
slidercrank has quit [Ping timeout: 256 seconds]
unimplemented has joined #osdev
smach has joined #osdev
Iris_Persephone has joined #osdev
bnchs has quit [Remote host closed the connection]
ketan has joined #osdev
levitating_ has quit [Ping timeout: 268 seconds]
levitating has joined #osdev
n1tram1 has joined #osdev
Iris_Persephone has quit [Ping timeout: 252 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 252 seconds]
danilogondolfo has joined #osdev
SGautam has joined #osdev
smach has quit [Ping timeout: 248 seconds]
vdamewood has joined #osdev
ilovethinking has joined #osdev
<ilovethinking>
is it a good idea to make my scancode array so that scancode_array[scancode] = character?
gog has joined #osdev
<ilovethinking>
so for example scancode_array[0x23] = 'H'
<moon-child>
ilovethinking: input translation is a giant ball of beeswax if you want to do it right
<moon-child>
I wouldn't worry about it too much
<ilovethinking>
so i just shouldn't translate them for now?
<moon-child>
no, you should translate. Just don't worry too much about how
<ilovethinking>
so how shpuld i translate
<Mutabah>
a set of scancode tables, like you described
<moon-child>
what you proposed sounds fine. Though I would suggest handling shift ahead of time (so eg scancode_array[0x23][0] is 'h', [1] is 'H')
<moon-child>
I'm just saying that this is not the big, fancy, proper solution; if that's what you want, you should plan to research more and add something fancier later; if, more likely, you don't care too much, then just be aware of that and act intentionally
<Mutabah>
Lazy option is to have just two - one for no shift/caps, the other for shift/caps
<ilovethinking>
but how do i actually implement it without wasting hours? cuz the scancode set is massive
<Mutabah>
(More complex solutions would have lots of rules, with capslock only impacting letters - but shift impacting all keys)
<Mutabah>
Grab someone else's?
<Mutabah>
Although... there's only 101 keys on a standard US keyboard
<moon-child>
yes, I was about to sa
<moon-child>
y
<moon-child>
just implement the normal ones
<zid>
and you know, it's basically just hitting a-z a-Z 0-9 for 3/4 of it
<Mutabah>
The scancodes are also ordered based on key position (on the original IBM keyboard afaik)
<ilovethinking>
i won't implement released for now
<moon-child>
isn't release just a bit in the scancode?
<moon-child>
it is for ps/2, at least
ketan has quit [Quit: Leaving]
<Mutabah>
Depends on the mode iirc
<Mutabah>
it's either the high bit in the scancode, or it's a prefix byte
<kazinsal>
it's high bit set on scancode set 1, 0xF0 prefix byte on set 2
* moon-child
nods
<kazinsal>
pretty sure it's the same 0xF0 prefix byte on set 3
Turn_Left has joined #osdev
<moon-child>
either way, not much effort. It's not like release x is a completely different code from press x
<bslsk05>
outerproduct.net: Why no one should use the AT&T syntax ever, for any reason, under any circumstances
<ilovethinking>
gog: grats :)
<ilovethinking>
Mutabah: yeah, i have no clue how i'mm planning to go about backspace/shift
* Mutabah
is away (not here ...)
<mrvn>
zid: are you actually using that over kvm?
<zid>
moberg: I found out a really bonkers wtf in AT&T syntax (or maybe just gas, but that's basically the same thing) he doesn't mention
craigo has quit [Quit: Leaving]
<mrvn>
ilovethinking: also consider ctrl, alt, super, hyper
<mrvn>
(windows, menu)
<zid>
it seems to have equs for DWORD WORD etc to 2, 1, etc
<zid>
so me and someone spent like 2 hours tracking down a bug in some code that did mov dword [eax], 12
<zid>
s/moberg/moon-child
<zid>
which it saw as... eax with a displacement of 2
<ilovethinking>
mrvn: how should i go about uppercase letters
<ilovethinking>
?
<zid>
because of 'ptr' missing
<mrvn>
ilovethinking: usualy each entry in the scancode table is an array using all the modifiers as index.
* gog
points
<mrvn>
zid: and that is why I like "move.w" on m68k
<ilovethinking>
mmm
<ilovethinking>
ill figure it out later
<ilovethinking>
what should i work on next
<mrvn>
ilovethinking: yeah, start with just two entries for no-shift and shift and think about it later.
<mrvn>
ilovethinking: the timer IRQ and then multitasking
nyah has joined #osdev
<ilovethinking>
timer irq? what;s that for
<ilovethinking>
i mean what will i need it for]
<moon-child>
some userspace application wants to eat your entire cpu and never give it up
<moon-child>
but you want to be able to schedule it out and let something else run
<moon-child>
timer interrupt lets you do that
<mrvn>
or for sleep(5);
<mrvn>
I would have done timer before keyboard because it's simpler to working than PS/2.
<ilovethinking>
i have done too much already anyways, ps/2 keyboard hsouldve been the first thing but i have physical and virtual memory already
<mrvn>
virtual memory is always the first because otherwise you have to rewrite everything else when you switch to virtual.
<mrvn>
Plus on x86_64 you simply can't do without.
<ilovethinking>
the timer sounds so complciated for now
<mrvn>
the PIT is trivial to setup
<moon-child>
it is trivial. But you can also get by just fine without, for the most part. Most applications are well behaved
<mrvn>
you want to do cooperative multitasking? *shiver*
<moon-child>
obviously a bad idea for a real production thing
<moon-child>
but again, it more or less actually works in practice
<mrvn>
On the other hand you9 have keyboard interupts. So you would preempt on key presses.
<moon-child>
and deemphasising it helps avoid the notion that timers are related to scheduling. Which is important imo
<mrvn>
true
<mctpyt_>
hello! nice to find such an active channel about osdev
<ilovethinking>
hi
<moon-child>
(also avoids using timer instead of tsc for querying time, which is also to the good)
<ilovethinking>
mrvn: trivial means not important?
<klange>
'trivial' in this context means 'easy' or 'not complicated'.
<sham1>
"trivial". Left as an exercise to the reader
<SerHack>
Hey, I was wondering if I can get any help. I'm getting a triple fault on loading a GDT table, which register should I check for Selector Error Code?
<gog>
it'll be on the stack
<zid>
also, just use qemu and tell it to log interrupts
<zid>
it's easier
<gog>
also that
<SerHack>
I'm logging interrupts for that reason
<zid>
-d int -no-reboot
<zid>
and just looke at the v=00 e=00 stuff
<zid>
you want the first non-smm interrupt, it'll say old = 0xfffffff, new = 0xe
<zid>
or somethin
<zid>
is it a 32bit or 64bit gdt?
<SerHack>
yeah, I understood the old and new but I was getting out of mind where I could find that selector error code..
<SerHack>
It's a 16bit one
<zid>
a *what*
<zid>
is that.. allowed?
<zid>
gog: You're the GDT police, is that allowed?
<bslsk05>
'Nathan Evans - Wellerman (Sea Shanty)' by NathanEvansVEVO (00:02:36)
* lav
shants the shanty
<mrvn>
reprogramming successfull
<mrvn>
grrr argh
* gog
drinks sugar and tea and rum
<mrvn>
Note to self: When building space station with artifical gravity make it rotate to make it challenging.
<gog>
are you playing ksp
<mrvn>
watching Dark Matter
<gog>
ohh
wand has quit [Ping timeout: 255 seconds]
<GeDaMo>
Docking with a rotating space station is challenging in Elite :|
<mrvn>
GeDaMo: at least there you do that along the axis and not from the side.
* sham1
threads shit up
<sham1>
50 minutes for a learning result? Yeah, how about no
<sham1>
I hope that even with Python's gimped threads it'll become more manageable
n1tram1 has quit [Ping timeout: 255 seconds]
SpikeHeron has quit [Ping timeout: 268 seconds]
xvmt has quit [Ping timeout: 248 seconds]
xvmt has joined #osdev
JerryXiao has quit [Ping timeout: 264 seconds]
JerryXiao has joined #osdev
divine_ has joined #osdev
gog has quit [Quit: byee]
gog has joined #osdev
SpikeHeron has joined #osdev
mats1 has joined #osdev
ilovethinking has joined #osdev
ilovethinking has quit [Remote host closed the connection]
bgs has joined #osdev
Benjojo has quit [Ping timeout: 255 seconds]
Benjojo has joined #osdev
mats1 has quit [Ping timeout: 255 seconds]
kkd has quit [Ping timeout: 252 seconds]
mats1 has joined #osdev
kkd has joined #osdev
terminalpusher has joined #osdev
Iris_Persephone has quit [Ping timeout: 260 seconds]
xenos1984 has quit [Ping timeout: 252 seconds]
acidx has joined #osdev
xenos1984 has joined #osdev
acidx_ has joined #osdev
acidx_ has quit [Client Quit]
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
GreaseMonkey has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
Iris_Persephone has joined #osdev
dude12312414 has joined #osdev
xenos1984 has joined #osdev
simpl_e has joined #osdev
Iris_Persephone has quit [Ping timeout: 255 seconds]
heat_ has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
bah, llvm-objdump -d poorly formats riscv output so short opcodes get misaligned
<heat>
annoying
<kof123>
yeah but is it misaligned in color or not?
<heat>
llvm-objdump does not have coloring, binutils objdump is the one who does
<heat>
it's also much faster
<heat>
binutils objdump miles clear
<gog>
hi
<heat>
hi
<lav>
ih
<moon-child>
hoi
<heat>
hearts of iron to you too
<moon-child>
am TEM
<moon-child>
>_<
<gog>
am CAT
<lav>
meow
<gog>
=^.^=
<gog>
i'm rewriting code i don't need to rewrite i should stop
<heat>
no
<gog>
yes
<moon-child>
definitely not
<gog>
i deleted it
<moon-child>
:\
<gog>
stop the rewrite dead
<moon-child>
anything which was not invented here is BAD
<moon-child>
past gog? who knows wtf that bitch was thinking
<gog>
i already invented it
<moon-child>
probably trying to sabotage you
<heat>
100%
<gog>
probably but she might have been trying to help me
<heat>
past gog stupid, present gog modern brian kernighan
<gog>
past gog: wise, considerate. present gog: clown, baby, fool
<heat>
if time keeps flowing does that mean that present gog invariably becomes a stupid instantaneously? yes
<lav>
present lav: silly little cat
* moon-child
pets gog
* gog
prrr
<GeDaMo>
Remember that future gog knows where you live :|
<moon-child>
oh shit
<moon-child>
better move then
<gog>
i'm not afraid of her
<gog>
she's even more of a clown
<heat>
🤡
<zid>
future me is an asshole so I do things to sabotage him
<mrvn>
future gog is a you problem
<gog>
nah
heat has quit [Ping timeout: 248 seconds]
<kof123>
" not invented here is BAD" that's a good point, time seems left out of NIH (whether arguing in favor or against)
<gog>
given infinite time i will invent everything
<zid>
dirty bastard
* gog
uninvents zid
<zid>
I wondered who was spreading *that*, but knowing it was you makes sense I guess
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
bnchs has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
slidercrank has quit [Ping timeout: 255 seconds]
<mrvn>
I only rewrite bad code not invented here. so everything. :)
<gog>
:)
<mrvn>
considering c strings bad makes it easy to judge NIH software
danilogondolfo has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
joe9 has joined #osdev
<sham1>
C strings bad makes it very easy to add one's own (better) string abstraction
<mrvn>
malloc also returns zeroed out memory and zeroed memory must be valid nullptr.
<zid>
'better'
<zid>
Yet in practice, you never see that
<mrvn>
zid: std::string?
<\Test_User>
why does any other string form need to be an abstraction
<\Test_User>
ptr,len is a valid string with no abstractions needed
<mrvn>
that's an abstraction
<sham1>
^
<mrvn>
len, data is also a valid string
<zid>
I don't bother with a real 'abstraction' because it's just too much work
<sham1>
Not requiring O(n) to do length computation is already a huge win
<zid>
to put a wrapper around everything that takes a struct string { int len; char *s }; everywhere you'd normally take a char *
<zid>
sham1: 99% of the time, you don't need to do that, and .99% of the time you know the length anyway
<sham1>
There's not much else in terms of abstracting you can do without automatic memory management. At least in a nice way
<\Test_User>
you'd typically want to do that yes, but you don't need to struct {} it, leaving it as a non-abstraction
<zid>
Yea that's what I said
<\Test_User>
unless you also consider a buffer to be an abstraction
<mrvn>
zid and 0.01% of the time somebody exploits it to steel your bank account info
<zid>
I specifically don't bother creating an actual abstraction, I just deal with raw strings and side-channel the lengths around
<sham1>
Well it is. It's a conceptual abstraction. There is no such a thing as a "buffer" in a computer
<zid>
see: strncpy
<zid>
strncpy doesn't take a pascal struct, it just takes a string + length
<mrvn>
zid: that's about the worst function you could name: Warning: If there is no null byte among the first n bytes of src, the string placed in dest will not be null-terminated.
<sham1>
It's trivial to write a pascal struct wrapper for strncpy
<zid>
yes, yes it is
<zid>
but it's still more work than not doing it
<zid>
and if you have 1 wrapper you should really have every wrapper
<zid>
so I just.. don't
<zid>
because it's a huge waste of time
<sham1>
I just let my tooling generate it from IDL
<sham1>
:D
<mrvn>
zid: it's easy to not have char* at all and only length prefixed buffers.
<zid>
The only time I make a string abstraction is when I am writing very defensive code that *would* have to check the length of the string multiple times
terminalpusher has quit [Remote host closed the connection]
<zid>
like if I am hanging strings off a datastructure then releasing it into the aether and the string comes back to me later in a different context and I can't side-channel the length in
<zid>
I have to attach it to the string then and there
<mrvn>
The problem with your approach is that one day you will forget.
terminalpusher has joined #osdev
<zid>
so to give a random example, I load a bunch of resource files and I load them all into a struct resource { struct level_data *d; char *filename; }; and then later I want to support dynamic reload of my assets by hitting f5
<zid>
but they need to check for alternate forms like .png or .jpg
<zid>
I *might* in that case, attach a length
<zid>
but even then, unlikely
<zid>
strings generally are loaded, manipulated and discarded in the same spot
<mrvn>
for that it's good to have a { size_t size; size_t used; char data[]; }
<zid>
so you can just have the length in an automatic variable
<zid>
for the entire object lifetime of the string
<zid>
less likely: The string's lifetime exceeds the life-time of the auto, double less likely: It exceeds it *and* I need to modify it from the end in future.
<mrvn>
well, strings should be immutable.
<\Test_User>
why, modifying in-place means you don't need to copy the whole thing (especially if it remains the same length)
<mrvn>
\Test_User: why would you modify a string? use a buffer
<\Test_User>
why have strings and not just buffers
<mrvn>
because then you can use them as e.g. keys in hashtables without having to copy them all the time.
<mrvn>
and place them in .rodata
<\Test_User>
`const` buffers then
<mrvn>
that's a possible alias for string
Matt|home has quit [Remote host closed the connection]
Matt|home has joined #osdev
<mrvn>
variables should also be mutable, immutable or const.
<\Test_User>
what's neither mutable nor immutable...
<mrvn>
can be modified but by you
<\Test_User>
ah
<mrvn>
not by you I mean
<mrvn>
immutable objects can be used as keys in maps or hashtables and such. Everything else you have to copy.
<mrvn>
const is a contract by the function that the string won't be modified while immutable is a contract to the function that the string won't be modified later.
gorgonical has joined #osdev
<gorgonical>
Woodworking in an apartment isn't easy, but sometimes it is fun and even worth doing. I built a desktop table for perching my keyboard/mouse on instead of random boxes and books
<gorgonical>
The quest for ergonomics continues
<zid>
osdevdev
<zid>
where you develop furniture for doing osdev in
AmyMalik is now known as MelMalik
<mrvn>
woodworking your keyboard is fun too
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
terminalpusher has quit [Remote host closed the connection]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
bgs has quit [Remote host closed the connection]
Iris_Persephone has joined #osdev
Brnocrist has quit [Ping timeout: 252 seconds]
Brnocrist has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.7.1]
heat has joined #osdev
<heat>
good morning
<zid>
heat thinks it's monday morning
<zid>
he's very confused
<heat>
i'm a bit slow
<Iris_Persephone>
oh wow I totally forgot I left my client connected
<Iris_Persephone>
heya guys
<mrvn>
zid: how could a monday morning ever be good?
<zid>
write yourself an os yet?
<zid>
or me one?
<heat>
we should all write an OS together
<heat>
as a community
<heat>
that will totally work, it's a new idea
<zid>
Yea I can't see a flaw in that plan
<gog>
ok so should my input come through a stream that's backed by a ring buffer
<gog>
seems the most easiest way to implement that
<heat>
gog
<heat>
hi
<gog>
hi heat
<heat>
wanna come contribute to my operating system
<gog>
as soon as i'm done with mine
<heat>
i'll take whatever evil idea you're hatching up with the PLT
<zid>
I'd go for a high water line, then panic() and delete the OS
<gog>
you don't want it, madness lies this way
<heat>
i think it's monday morning
<zid>
Maybe I'll make a little text mode console thing
<heat>
i am the way
<zid>
my bochsvbe stuff just gets in the way
<heat>
gog: if you were online on Discord I could send you great gifs
<gog>
i am online
<gog>
i am not online
<zid>
you are not online
Matt|home has quit [Quit: Leaving]
<zid>
glog should I quickly hack up a way to type
<gog>
i'm going online
<gog>
yes
<zid>
not online
<gog>
hack up anything
<zid>
okay will you supervise
<zid>
my eyes are bad, I don't have my adult supervision yet
<moon-child>
and then git submodule update --remote to update the pointer
<zid>
okay done
<zid>
cool
<heat>
i usually just cd to the git submodule and git pull
<heat>
then git add the results and commit
<zid>
oh it made a dir called bootstrap that's not what I wanted..
<mrvn>
gog: input is a device. Someone has to open it and read from it. Shouldn't you have a uring?
<gog>
¯\_(ツ)_/¯
<moon-child>
uring? why u?
<moon-child>
microkernel?
<Iris_Persephone>
should probably get that checked by a doctor
<heat>
zid, what do you want to do?
<mrvn>
moon-child: Some user space program will open then device, like getty.
<moon-child>
sure, but that's on a separate layer
<mrvn>
moon-child: and for the in kernel layers you could just use the same ring structure
<mrvn>
moon-child: do you create threads for device drivers?
<zid>
heat: .
<gog>
what's a device
<moon-child>
mrvn: no
<moon-child>
but my thingy is weird and not representative. And I abandoned it
<heat>
zid, . what
<moon-child>
.
<moon-child>
that's it
<zid>
that's literally it
<mrvn>
gog: things that produces or consumes a stream and has maybe some other functions.
<heat>
zombo dot
<moon-child>
WELCOME
<gog>
what if it produces and consumes blocks
<heat>
welcome to dot
<moon-child>
you can do .
<mrvn>
gog: then it's a block device, slightly different functionality as that generally can seek
<zid>
You can't have a submodule at the root of your repository because both .git folder would conflicts.
<zid>
You must create your submodule in a subfolder.
<zid>
okay so fuck submodules
<zid>
we're forking
<gog>
ah ok you can seek a block
<heat>
yes zid, that's not how submodules work
<heat>
if you're basing your work out of the "submodule", it's a fork
<zid>
yes
<zid>
I literally just checked the documentation because you didn't know
<moon-child>
gog: ok so basically
<zid>
stop trying to teach me things I already learned ahead of you
<heat>
you didn't ask
<heat>
you just said .
<moon-child>
you have a write high watermark, and a write head, and a read high watermark and a read head
<mrvn>
gog: for a char device I would pass the data in the ring and for block devices pass descriptors.
<mrvn>
(pointers to buffers=
<moon-child>
to write, you bump the watermark, write your shit, and then bump the head
<moon-child>
should be waitfree, works in interrupt handlers, or multicores, or whatever
<moon-child>
magic
<mrvn>
works with plain kernel, with threads for devices, processes in a mycrokernel, user space programms.
<mrvn>
MAGIC
<zid>
okay so let's set up some interrupts I guess
<moon-child>
also read/write are monotonic so you don't need multiword atomics. Can just sample read head to find out if there's any space to write to; no aba or w/e
<zid>
what IRQ was keyboard?
<heat>
1 right?
<gog>
my crow kernel
<gog>
:thinking:
<mrvn>
gog: it's black
<heat>
zid, yeh 1 is keyb, 12 is mouse
<moon-child>
yeah I think 1
<mrvn>
caaaw caaaw caaaw
<moon-child>
pit is 0
<heat>
pit is also 2
<heat>
irq redirection baby!
<zid>
pit is 2 yea
<zid>
cus my irq mask is usually 3
<zid>
for keyboard and pit
<moon-child>
mmmm
<heat>
that would make it 0
wikan has joined #osdev
<wikan>
does anyone have any manual with intel opcodes?
<zid>
what are manual ones? what are automatic ones too while we're at it