<klange>
I ported the old mines.py from toaru 1.2.x to Kuroko.
<mrvn>
klange: does it have "?" tiles?
<mrvn>
is it always solvable without guessing?
<klange>
I only have flags and the 'trick' of regenerating the board if the first click is a mine.
<mrvn>
yeah, failing on the first try is boring.
<froggey>
bastard tetris, but for minesweeper: you always fail on the first click
<mrvn>
decades back I implemented minesweeper with dificulty level: easy - you never uncover a mine unless there is no other placer the mine could be, medium - you don't uncover a mine till you have enough tiles so that one mine is fixed, hard - totaly random except the first click isn't a mine.
<zid>
basweep
<zid>
bastet is a funny ol game
<mrvn>
First person minesweeper is also fun.
<mrvn>
Ever played 3D minesweeper?
<klange>
Still missing some things from mines.py, like dialog boxes, and the status bar saying how many mines there are, but this is a reasonable demonstration the the windowing APIs are working nicely.
<mrvn>
klange: I want menu entries with videos
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
<geist>
gog: make sure yo set the *top* of the stack in the RSP0 in the Tss. i've made that mistake like 40 times
<gog>
haha yes
<gog>
it is indeed the highest address of the stack
<gog>
in any case it does work
<gog>
i just have other problems now
<geist>
woot. yeah i didn't read the whole backlog
<zid>
Yea I made that mistake in boros
<zid>
tss.stack = stack; so tempting :(
<kazinsal>
ooh, 86box has support for serial pass through and serial to named pipes now
<mrvn>
zid: nobody put's baby in a corner
<gog>
i still need to make changes to my threading code
<gog>
"threading"
<gog>
task code
<gog>
my next major goal is to get the fbcon out of the kernel
<heat>
nooooooooooo
<mrvn>
zid: what's wrong with that?
<zid>
My task code handles precisely one task because I don't allocate multiple struct task yet, oops
<gog>
my task code actually can handle multiple tasks shockingly enough it's just a bit of voodoo to me still
<gog>
because i didn't write the code all myself
<gog>
and i only half understand it
<heat>
github actions sucks at running qemu :/
<zid>
gog how are you erm.. loading your task?
<gog>
i'm not
<zid>
I cheated and used a grub module to get mine into memory just so I could test things
<heat>
i'm looking at TWO LARGE CHEATS
<gog>
i cheated even more and have the user task code in the kernel, i'm just making the pages that contain it user mode
<zid>
nice
<zid>
"iretq;"
<zid>
"push 0x200000;" /* FIXME: _start from ELF */
<gog>
but when i do split it all out i can already load multiple modules
<zid>
I need to write.. another elf loader :D
<mrvn>
I have played with multiple user task codes in the kernel all linked to 0x100000 with different LMAs.
CryptoDavid has quit [Quit: Connection closed for inactivity]
bradd has joined #osdev
Matt|home has joined #osdev
Arthuria has quit [Remote host closed the connection]
slidercrank has joined #osdev
valshaped has quit [Ping timeout: 252 seconds]
<kazinsal>
I'm fiddling with building C for 8086/8088s with OpenWatcom and it's got some neat pragmas you can use to tell the compiler to use bespoke calling conventions for specific functions
<geist>
neat. yeah guesse that sort of thing really mattered
<kazinsal>
eg if I do `#pragma aux memcpy parm [SI] [DI] [CX]` and then define memcpy in an assembly object any calls emitted to memcpy will use those registers for the three parameters (left to right) instead of using cdecl
<kof123>
ooh, that might actually be useful for me kazinsal, good to know
<kazinsal>
kof123: I'll probably do a writeup for this if I can stick with it long enough to do this stupid april fools osdev joke for once, after years and years of saying I'd do it
<kazinsal>
adhd_brain.txt
bgs has joined #osdev
<kazinsal>
openwatcom has a bunch of frontends that emulate different C compilers' flags and outputs
<kazinsal>
but some of them don't support all the right flags that you need for a dumb project like this
<kazinsal>
eg the gcc one doesn't support the tiny memory model for some reason
<zid>
looks light it might be easier than gcc's way
<kazinsal>
yeah, it's pretty easy to read and write
<moon-child>
I heard it proposed that, if you want to use custom calling conventions with gcc, you should diy with inline asm
<moon-child>
of course, this doesn't work for stuff like memcpy where the compiler generates calls itself
<moon-child>
but otherwise more expressive--can specify clobbers, etc.
<zid>
yea you have to attribute naked and int register r asm("rax"); shit
<zid>
it's annoying
<moon-child>
no, not that
<moon-child>
I meant for generating the call
<moon-child>
not for writing the callee
<moon-child>
assuming latter is in asm
<zid>
oh yea the call is like, unpossible
<moon-child>
like I _just_ said
<moon-child>
you can do it with inline asm
<kazinsal>
actually zid that reminds me I need to plug this into IDA and see if this pragma aux assignment thing assembled a function that gets called or if it makes the compiler emit whatever assembly you tell it to spit out instead of emitting a call
<kazinsal>
neat. it inlines whatever you tell it to
valshaped has joined #osdev
<geist>
zid: sad thing i've learned over the last few years: clang doesn't do the register asm("reg"); thing inside a function for the purposes of pinning stuff
<geist>
it oly really supports it in the global sense
<zid>
oh, that's rude of it
<moon-child>
it doesn't support globally reserved registers
<moon-child>
except I think x18 on arm
<moon-child>
(and maybe the same thing for riscv)
bgs has quit [Remote host closed the connection]
<geist>
yah though if you -ffixed-register it probably does
<moon-child>
that's what I'm saying, it only supports that for a couple of things
<moon-child>
not for all registers like gcc does
* geist
nods
<geist>
we fied a few of those bugs for clang for zircon, because we wanted to use another one
<geist>
x20 in our case
<geist>
and had to fix up clang to let us pick any of the callee saved ones
<moon-child>
oh cool, nice
<moon-child>
does it work for x86 too or just arm?
<geist>
i think it works up until the point that there's some hard coded purpose for a register, and that's for a lot of them in x86
<moon-child>
basically just rcx, rdx, and rax
<geist>
and rdi and rsi and rbp and rsp
<moon-child>
technically rdi/rsi for strings ops, and rbx for xlat
<moon-child>
but that doesn't really come up much
<moon-child>
strings sure
<geist>
but i suspect you could pssibly pin any of the callee saved ones >= r8
<moon-child>
anyway i wouldn't want to steal one of those
<geist>
you dont want to pin any that participate in argument passing either, sicne that'd mess up the ABI
<geist>
so it generally has to be a callee saved, or a pure temporary (the latter there's none in x86 ABI)
* moon-child
nods
<moon-child>
there is one temporary
<moon-child>
r10
<geist>
oh. not for args and not saved? good to know
<moon-child>
yes
<moon-child>
it's so plt can have a scratch register
<geist>
thaaaat is why r10 tends to be used for vaneer routines. are you sure it's not r11? i think i've seen that one used for that
<kazinsal>
geist: man I'm poking around at that godbolt you posted and that compiler is doing some absolutely ridiculous stuff
<kazinsal>
look at the -O0 output
<graphitemaster>
register asm never meant "reserve this register" and was never meant to be used for passing parameters to anything but extended inline asm with input and output operands
<geist>
moon-child: yeah you're right, r10 and r11 are not args, and not saved
<geist>
graphitemaster: it's more subtle than that. there's some blurb in the gcc manual
<graphitemaster>
Like this is documented in gcc man pages, it's funny that when clang actually implemented it how it was documented code stopped working XD
<moon-child>
oh right, there was another one where the intent was to be used for pascal or something
<geist>
but basically local scope register stuff is for passing in args, yes
<moon-child>
which doesn't really make sense, but I can understand why, at the time, they thought it might be interesting to provide that
<geist>
sadly *that* is what clang doesn't do. so aside from x86 where you can specify registers for input args, you're kinda hosed on arches like arm and riscv
<geist>
the global scope thing i think gcc documents that
<graphitemaster>
I didn't even know you could use register asm in the global scope
<bslsk05>
gcc.gnu.org: Global Register Variables (Using the GNU Compiler Collection (GCC))
<geist>
right. there it is
<graphitemaster>
This is insane lmao
<graphitemaster>
What is the intended purpose of this
<zid>
task struct is the main user
<zid>
lots and lots of OSs pin it to a reg
<geist>
i can giv eyou a very good reason: kernels and reserving a regster to point at the current thread or current cpu
<geist>
ie, x18, x20. this is what we do in zircon
<geist>
for riscv GP and TP are great registers for this purpose
<geist>
but really you could pick any of the S registers as long as they're not used for something else (ie, not s0 because that's the frame pointer)
<moon-child>
I would like to use it to store the global state pointer for the j interpreter
<geist>
for x86? probably not that useful. could pin r15 i guess
<moon-child>
in contexts where you can't use segregs
<moon-child>
(outside of x86 is obvious. On x86, macos won't let you set segregs)
<geist>
yah and that's why i fyou pick a callee saved register to store your module's global state you're fairly safe interworking with other code: they'll save it and restore it if you call one of their routines
<geist>
though calling 'through' one of their functions would probably not work
<moon-child>
you need care regardless of whether is callee saved or caller saved
<geist>
obviously
<moon-child>
question is where
<moon-child>
for something that wants to own the world to the point that it reserves registers globally, it's likely to have few callers
<moon-child>
but might call some library functions anyway
<geist>
anyway. kernels this is very useful. we pin the current cpu state in x20 on zircon for example, and use -ffixed-register=x20 and the global reg thing
<moon-child>
so I agree callee saved makes sense
<moon-child>
but this is mostly a point of convenience
<geist>
yah, x20 was the first available one that clang would free up. x19 was curiously not available (though it's the first saved reg) because clang has some hard coded idioms that use it
<moon-child>
wat
<moon-child>
why
<geist>
i forget. it was probably worth fixing
<geist>
it was just some code sequence where it always picks the first saved reg and does something with it (which x19 is). i think some function prologe/epilogue thing
<geist>
it should be smarter and use the first one that isn't otherwise fixed, but a case where that logic wasnt plumbed down
<moon-child>
why can't it just say 'hey register allocator, gimme a register'
* geist
shrugs
<geist>
it was a bug, for sure. haven't thought about it in years. probably fixed now
<graphitemaster>
I might be the only person left on this planet that wishes all CPU registers were memory mapped conceptually. Just do some magic in the CPU to pin some memory addresses as aliases for the registers. Then you can solve this issue with a linker script.
<geist>
ah i think i see it. sometimes (possible alloca style stuff) it uses x19 has the 'base register' for the frame
<kazinsal>
graphitemaster: so, a TMS9900
<geist>
again, does it need to have it hard coded like that? no. but it is sort of an exceptional case
<graphitemaster>
Most microcontrollers still work this way.
<geist>
hmm, yeah, clang still seems to not honor ffixed-x19
<moon-child>
I think this is good for ~10% on a particular sorting algorithm
<moon-child>
but only gcc supports it
<graphitemaster>
Just write every function in your entire kernel / OS as taking the task structure as a pointer :P
<graphitemaster>
And pass it around explicitly
<moon-child>
that's slower
<geist>
bug is there on riscv too. sigh
<geist>
x3 should be the 'gp' register, but since it considers it callee saved, it'll see that you're writing to it and emit code to spill and restore it
<graphitemaster>
Was going to say, another option would be to just use thread local and just implement the ABI in your kernel to support TLS.
<geist>
indeed. the TP register is used for that
<geist>
but GP register is great for per cpu stuff
<geist>
since it really has no terribly good value otherwise
<graphitemaster>
Was going to say you could also use the frame pointer register if you don't need it for actual frame pointer stuff
<moon-child>
if you don't have a frame pointer, shame on you
<moon-child>
better yet would be split call/data stacks
<moon-child>
then you can sample the call stack very quickly, with no pointer chasing
<moon-child>
but no one implements that abi yet
<geist>
also to note, architectures that have a lot of registers like arm64 or riscv it's really no big loss to pin one or two
<geist>
most functions dont really use most of them anyway
<graphitemaster>
Or just pin the task structure at a fixed address and forget having a pointer for it, just load it from a constant address.
<graphitemaster>
No one said your kernel code cannot be self modifying.
<geist>
have fun writing a SMP kernel that way
<moon-child>
per thread code /s'
<moon-child>
err
<moon-child>
per core
<kazinsal>
I wonder if anyone ever built an SMP 8086 system
<geist>
note on x86 you'd generally use gs: for the per cpu anchor
<graphitemaster>
How exactly does code determine which thread it's on on a core anyways?
<graphitemaster>
In the case of SMP
<moon-child>
there's some msr or something iirc
<geist>
in what context on what architecture? it tends to be arch specific
<kazinsal>
black magic
<geist>
this is basiaclly what we're talking about, in the kernel on an SMP system it has to keep at least one 'anchor' to be bacl to get back to current cpu and/or current thread data
<geist>
depending on the arch you can use any numbr of mechanisms
<geist>
generally speaking reading the current cpu number is not the fast way to do it, and not all arches even have a way to do it (riscv comes to mind)
<moon-child>
I assumed they meant initial discovery
<geist>
yeah *initially* it's arch specific
<moon-child>
as once you have _any_ way--even a slow one--to find out what core you're on, you can make a fast one
<moon-child>
yes
<geist>
rigjt. you use the slow mechaniosm to set up the anchor so you dont have to use it anymore
<geist>
from then on out you can get to the current cpu # with something like get_current_cpu()->num
<geist>
where get_current_cpu does the black magic
<geist>
on x86 this may be something like `mov gp:4, rax`
<graphitemaster>
To me the per-physical-core (like actual CPU, not hyper threading) structure ought to be easy to do with pinning memory, you can just allocate an array of length N at a fixed address, as long as your CPU knows it's index it can read from $fixed+N easily, the thing that seems hard to me is a) knowing what N is and b) dealing with hyper threading
<geist>
right, knowing what N is is exactly what yo uuse this structure to know
<geist>
so it's recursive
<moon-child>
why not hyperthreading?
<geist>
and hyperthreading has zero bearing on this. a hyperthread looks just like another cpu
<graphitemaster>
Ah okay
<moon-child>
whether a given core hyperthreads with another or not should be purely _heuristic_ information given to the scheduler
<graphitemaster>
So basically the hard part is how does a CPU know it's CPU N :P
<graphitemaster>
Seems insane to me to dedicate a register to that
<moon-child>
the register doesn't contain n
<graphitemaster>
Sure, it contains the address to the actual structure.
<moon-child>
the register points to all the per-cpu informatin you might be interested in
<geist>
and the structure has a lot of other stuff but N
<moon-child>
and the fact that you're interested it means you're probably going to access it a lot, and so want to have a pointer to it anyway
<geist>
pointer to the current TSS, for example, on x86. so you can patch it
<geist>
or, the current thead
<geist>
pointer to the current IO bitmap
<geist>
pointer to a place where yo generally allocate per cpu variables, used for efficiency purposes
<graphitemaster>
However I'm thinking it could just be a simple index if you had a fixed address for the per-cpu information array, since most architectures can do a load at addr+n easily, the rest is just a matter of patching the kernel code during cpu bring up with the constant n (I assume you'd store a copy of the kernel .text per virtual cpu to avoid icache pollution in the case of hyper threading)
<graphitemaster>
So you'd copy .text, find all load/store at $CONSTANT_ADDR + $CONSTANT_N (this is easy to do in most archs), then replace them with the right N or something like that.
<moon-child>
you still pollute your l3. And how does that 'avoid icache pollution in the case of hyperthreading'?
<moon-child>
and how do you cope with the fact that your function pointers have all blown up by n times (for n the number of cores)?
<Griwes>
That seems like a terrific way to actually murder your higher level caches, by having the same thing in memory a gazillion times
<moon-child>
like I said :P
<Griwes>
You were too gentle in saying it :P
<moon-child>
fair enough
<graphitemaster>
I was under the impression that sharing the .text segment of the kernel on CPUs with hyper-threading is extremely bad because each thread is highly divergent in terms of which instruction it's executing that it constantly trashes icache. I remember reading this somewhere that the NT kernel stores a copy of itself per physical CPU to avoid this icache pollution on Intel.
<moon-child>
that does not sound right at all
<Griwes>
Anyway what geist said earlier - just hide things behind get_current_core() and then do the architecturally appropriate thing in the arch abstraction part of the kernel
<Griwes>
For amd64 I just have gs_base point into the core array entry for the current core
<Griwes>
And then the base operation is actually getting the current thread, because that happens to be what's needed most frequently, at least so far
<graphitemaster>
Er sorry, not per core, but like in the case of SMT2, NT allegedly copies the text segment of the kernel because icaches are shared and allegedly the execution flow while in the kernel is too divergent to be useful?
<graphitemaster>
Like too divergent between each thread on the core
amit has joined #osdev
amit is now known as dayimproper
Brnocrist has joined #osdev
<moon-child>
I understood what you meant, and again, that does not sound right at all. How could having two copies of the same data possibly cause _less_ i$ pollution? It is monotonically worse
<mrvn>
adding 2MB holes between sections is also stupid
<ilovethinking>
how do i align them
<mrvn>
RTFM
<ilovethinking>
right
<ilovethinking>
by what do i align it
<ilovethinking>
my brain isn't braining
<ilovethinking>
4 or 8
<mrvn>
page size
<ilovethinking>
ok so 4
<ilovethinking>
0x1000 is 1 page
<ilovethinking>
yeah defo 4
<mrvn>
not sure how you get from 0x1000 to 4 or 8
<ilovethinking>
can i just do align(0x1000)
<ilovethinking>
ALIGN(0x1000)
<ilovethinking>
ill try it
<ilovethinking>
so i should align all sections?
<ilovethinking>
.text : ALIGN(0x1000){*(.text*)}
<ilovethinking>
oh wow linker allowed it
<ilovethinking>
the CR2 is still 0x2 below RSP
<ilovethinking>
so that didn;t change anything
<ilovethinking>
cr2 = ffffffff8000c078
<ilovethinking>
rsp = ffffffff8000c080
<ilovethinking>
wish i could see where BSS start is but i can't print anything
<napcat>
objdump?
heat_ has joined #osdev
heat has quit [Ping timeout: 246 seconds]
<gorgonical>
C Compound literals are lvalues? What the fuck?
<mrvn>
like what?
<gorgonical>
((struct Foo){}).x = 4
<gorgonical>
This is legal C
<gorgonical>
Forgot the semicolon
<mrvn>
that's a temporary. Not const or anything. sure you can assign to it
<gorgonical>
Apparently doing this creates an unnamed variable in local scope. But what could this be useful for in a situation where you have the bare, unnamed compound literal on the lhs?
<mrvn>
(haven't read it but the description on google looks good)
<mrvn>
I would postulate that if you know ARMv6 assembly then you can easily read AArch64 assembler. But not necessarily write it.
<graphitemaster>
Was curious if there was a subset of armv6 instructions that were also in aarch64 and could mostly translate without changes
<graphitemaster>
it looks like for the most part that is the case
<mrvn>
it is. The pudding is in the details.
<graphitemaster>
curious why aarch64 has signed/unsigned multiplication
<mrvn>
graphitemaster: because the flags differ
<mrvn>
32768 * 32768 is an overflow if signed but not unsigned for example.
<graphitemaster>
slide 39 there in your link is what i wanted
<graphitemaster>
when it says all 32-bits or 64-bits, does that mean you cannot mix them?
<mrvn>
as said, haven't read it
<geist>
yah arm64 is more like a new 64bit ISA that takes inspiration from arm32
<geist>
in general arm32 has more fancy instructions, more ciscy, arm64 generally removes the fancy bits and has a more basic base ISA
<geist>
(and then a bunch of extra instructions on top of that)
<graphitemaster>
link does not describe what aapcs64 is
<graphitemaster>
but mentions it many times xd
<geist>
gosh if only there was a way to search for it
<mrvn>
You can run 32bit code on an ARMv8 but you can't mix them. Switching is complex like on x86/x86_64.
<geist>
i guess you'll just never know
<graphitemaster>
rip me
<graphitemaster>
oh arm defines a procedure call abi
<graphitemaster>
neato
<geist>
so anyway things like push/pop are not there anymore but arm64 does have a curious double word push/pop, with any two registers in the slot
<geist>
that's how you're supposed to push pop things on the stack in arm64, since it lets you maintain 16 byte alignment at all times
<geist>
ldp and stp
<graphitemaster>
so it always pushes 16 bytes, what if i don't need all 16 bytes :/
<gog>
¯\_(ツ)_/¯
<gog>
it's only 16
<geist>
it's always 16 bytes
<geist>
arm64 has a requirement in the ABI (enforced in hardware if you enable it) that forces the SP to always be 16 byte aligned
<graphitemaster>
is there still a zero register i can throw in there to be like "this is what I want, push zero for everything else"
<gog>
i would love that enforcement in amd64
<mrvn>
graphitemaster: you push a dummy register
<geist>
loading anything that has the bottom 3 bits not 0 fauls
ilovethinking has joined #osdev
<geist>
xzr register, yes
<graphitemaster>
alright
<ilovethinking>
hello
<geist>
that actually is new to arm64. arm32 didn't have a zero register
<ilovethinking>
mrvn: you didnt finish what else was wrong with my linker
<ilovethinking>
i added alignment
<geist>
x31 specifically
<ilovethinking>
oh hey geist
<mrvn>
ilovethinking: no ctor, no init_array, no relocations, lots of stuff not discarded
<geist>
oh gosh ilovethinking you do *not* want to fuck with a linker script
<geist>
but this is eactly why i stopped being dragged into the conversation yesterday
<mrvn>
ilovethinking: multiboot signature not at the start of the file
<geist>
because others, mrvn in particular, were insistent on trying to make you deal with it
<geist>
i was out
<ilovethinking>
geist but i need it
bgs has quit [Remote host closed the connection]
<geist>
all that alignment stuff you do not
<ilovethinking>
???
<geist>
you dont. i was trying to tell you this but there were too many cooks and you weren't listening to me
<ilovethinking>
i have a very stupid error that must be an alignment issue
<mrvn>
geist: he needs it if he ignores your suggestion to just map everything RWX like he does
<geist>
yes. i'm saying just map everything RXW
<ilovethinking>
i do
<geist>
and move on. can fix it ater. this is *not* what they should be messing with right now
<ilovethinking>
gotcha
<mrvn>
ilovethinking: apparently not since you have huge pages in there that aren't rwx
<geist>
this is like fiddling with some sort of trim on the wheel well when the car doesn't have any tires or an engine
<ilovethinking>
this is the limine stack
<ilovethinking>
which sits at bss
<ilovethinking>
mapped
<ilovethinking>
since i map bss
<geist>
anyway, honestly i just dont have time to deal with this toda. sorry
<ilovethinking>
:bruh:
<geist>
i have other stuff i gotta get done
<ilovethinking>
aight
<ilovethinking>
anyways i get a pagefault and cr2 is 0x2 less than rsp
<graphitemaster>
does qemu still have binary / syscall emulation so I can run arm executables presumably
<ilovethinking>
i <3 osdev
<geist>
graphitemaster: oh the -user mode? yah, but i honestly dont know how to set that up
<mrvn>
graphitemaster: greatest thing to cross compile for arm
<mrvn>
geist: Nothing to setup, simply: qemu-aarch64 /chroot7aarch64/bin/ls
<geist>
well that's the setup. the whole chroot thing
<mrvn>
+-user somewhere in there.
<ilovethinking>
yeah addb pagefaults... my stack is FUCKd...
<geist>
if you want it to transparently run binaries on your system, you need a bunch of parallel libs
<graphitemaster>
Well this is free standing bins, no dependencies on libs, just a static elf with direct sys calls
<ilovethinking>
lea rsp, [stack + 0x2000] this is the right way to set the sp right?
<mrvn>
geist: yes, then you need binfmt-misc config so it automatically recognises arm binaries and have the libs in your library path and such.
<geist>
i think there's an apt-get for debian/ubuntu based systems that sets it up transparently
<geist>
i noticed it once when i accidentally ran an x86 binary on an arm64 ubuntu machine and it worked
<mrvn>
geist: dpkg --add-architecture arm
<geist>
i think it already had x86 arch installed and a qemu behind the scenes
<ilovethinking>
what if i just rewrite the fucking os
<ilovethinking>
because it's full of junk tbh
<ilovethinking>
and i'll do it without limine this time because
<ilovethinking>
well
<ilovethinking>
limine
<geist>
ilovethinking: as long as you learn. if you do it because you're frurstrated and dont learn anything then it was a waste of time
<gog>
i have a second job
<geist>
if you take what went wrong here and apply it to the next thing, sure
<geist>
follow less tutorials next time
<geist>
gog: woot?
<ilovethinking>
geist: the thing is that i wrote this os with 60% not the code i wrote
<gog>
i'm my wife's social media manager now it's totaly unpaid :P
<ilovethinking>
geist: i wrote it without a tutorial, just rewriting some code from others
<geist>
then start over and do it from scratch
<ilovethinking>
yup good idea
<lav>
gog: relationship goals
<ilovethinking>
geist: is the osdev barebones a good start?
<geist>
i thought you were going to do it from scratch?
<geist>
i have no idea if it's a good idea. i started writing oses long before any of these tutorials existed
<ilovethinking>
well at least the barebones
<ilovethinking>
oh what
<geist>
i only know of the old, hard way
<ilovethinking>
so how did you
<ilovethinking>
boot up the os
<geist>
write a floppy disk, stick it in a computer, turn it on, repeat
<ilovethinking>
but where did you learn everything
<geist>
the hard way. from books, from existing source code (BSD, linux, etc)
<ilovethinking>
i couldn't start without a barebones tbh
<ilovethinking>
lol
bauen1 has joined #osdev
<ilovethinking>
idk where to start at all
<ilovethinking>
and that's probably a bad sign
<geist>
anyway, again i'm not going to get pulled into this today
<geist>
as much as i'd like to help you it'sa gigantic time sink and i can't keep spending it here
<ilovethinking>
"pulled"?
<ilovethinking>
well okay i guess
<ilovethinking>
thanks
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<geist>
keep in mind you need to really show that you're willing to do some more work on your own
<geist>
if you start getting too leechy folks will stop helping you
<graphitemaster>
geist knitted a blanket out of the pages of all volumes of the Intel software developer manual and slept with it until he absorbed all knowledge from osmosis. That's how it was done before wikis.
<geist>
also if you just show that you abandon the project when it gets too hard, folks will stop helping you. so you have to plan a route that involves taking a lot of initiative
<geist>
graphitemaster: kinda, yes actualy
<geist>
i used to fall asleep reading the intel manual
<graphitemaster>
The OS in osdev is short for osmosis
<graphitemaster>
See
<ilovethinking>
no i just think that the kernel i have is a mess because i don't understand everything as i should
<geist>
ilovethinking: then you understand the basic problem. try to solve that problem by understanding everything
<geist>
that involves a lot of hard work, reading. learning
<gog>
i've gotten a lot of help from the osdev community over the years but it's also taken a huge amount of research and just tinkering with things
<gog>
you'll get there, but we can only do so much for you
<graphitemaster>
The best way to learn anything is to fail until you succeed.
<gog>
basically yeah
<gog>
you're gonna get stuck and frustrated
<geist>
what you've stumbled into a bit here is the fundamental problem with these tutorials
<geist>
they let people get fairly far without understanding, and without hard work to actually fail, and thus dont learn
<geist>
they're not all bad, but there's a point where you should be filling in the details, undesranding what you're copying. and that's hard when you first get started beause you dont know where to start
<gog>
maybe i should write a tutorail that's broken in various small ways and inform the reader of such
<gog>
and that it's their job to learn and fix it
<geist>
but, the tutorial is probably telling you something: it gives you a framework of things you should go learn. ie, 'why does the tutorial do this?' go figure that out, repeat
<graphitemaster>
Well all the tutorials are broken, they just don't inform you they are XD
<gog>
true
<gog>
like the task switching tutorial! i still don't know how i got it to work but it does
<geist>
in the old days the 'tutorial' wa basically somethingl ike the BSD kernel. so it was harder, but you still had kinda the same thing: a bunch of working existing code that you spent time trying to understand
<geist>
and over time you start to piece things together and get a clearer and clearer picture
<geist>
i started 2 or 3 times before i got a kernel that 'stuck'
<gog>
the one i'm workiong on right now is like the 10th time i started over
<ilovethinking>
geist, could you recommend any books?
<geist>
let me see
<geist>
i have a book list
<gog>
but it's also the one i've gotten the most out of
<geist>
(because people ask me this over and over again)
<bslsk05>
docs.google.com: Computer Books - Google Docs
danilogondolfo has quit [Remote host closed the connection]
<geist>
by no means is this exhaustive, or even up to date but it's simply books i found useful
<zid>
man, clicking something on drive F: on this machine takes like 10 seconds and I don't know why
SpikeHeron has joined #osdev
<zid>
oh! maybe my heads are being parked! I always had that off!
<graphitemaster>
To be fair, the Intel has a full multi-tasking kernel written for intel 64 and ia-32 in their gems repo too, so it's not like you're flying blind here
<gog>
zid: is it spinning down
<gog>
ope
<ilovethinking>
geist: you link the amazon links as if anyone is gonna buy the book :kekw:
<geist>
hmm?
<zid>
computersleep never, hard disk off: never
<zid>
there
<ilovethinking>
idk if im the only one but i just use pdfs out of whereber
<ilovethinking>
wherever
<gog>
i mean you know where to find them
<gog>
so
<geist>
ah i see, so i'm encourging you to pirate these books.good to know
<geist>
i'd have preferred you simply not mention that next time
<ilovethinking>
no you are discouraging me
<ilovethinking>
your are encouraging me to buy them
<ilovethinking>
since you linked them
<geist>
wtf are you talking about
<geist>
well okay you keked it so i guess you're just joking
<ilovethinking>
yes
<gog>
i really have an itch to acquire a retro computer
<gog>
an amiga of some kind is really interesting to me
<mrvn>
giving the above question of comparing armv6 and aarch64 now I'm wondering if I can write boot.S so that it will work for both armv6 and aarch64.
<geist>
ancient icelandic machine in the cave of ice
<gog>
yes
<geist>
mrvn: dont even bother, wayyy too different
<gog>
i will dig it out
<geist>
for all practical purposes the arches in supervisor mode are totally different
<graphitemaster>
Did you know they make computers out of sand, crazy right
<mrvn>
geist: well, in the verry simplest case it's set SP, clear .bss, jump to C code.
<lav>
opinber kyrrstöðu tóm aðal ()
<ilovethinking>
you know it's just that i feel like i don't know where to find info for topics, i had trouble especially for the vmm, i couldn't write it without copying code at some point
<geist>
mrvn: yes, but by that token you could do that with *any* architecture, except the details matter and you really cant
<geist>
ie, it looks like you could until you sit down to do it
<ilovethinking>
idk if i'm just bad at finding information
<gog>
ég fá gömlutöulva
<mrvn>
geist: I only want the same source, not the same binary.
<ilovethinking>
facts
<geist>
mrvn: but not to discourage you! i encourage you to step into the bold new(ish) world of arm64!
<lav>
gog: an old table?
<geist>
if nothing right off the bat you have a problem: arm64 calls the regissters 'x' and 'w' and arm32 calls them 'r'
<gog>
fyrirgefið, gömlutölva *
<nikolar>
geist: re llvm-mos pretty neat huh
<geist>
nikolar: yeah will have to figure out how to build/get that and play with
<geist>
especially if i get a commander x16 when they're released
<mrvn>
geist: that is a problem indeed
<nikolar>
You can at least start out in the compiler explorer
<nikolar>
Quite interesting to see the code it generates
<mrvn>
geist: they both have pseudo registers like "sp" though
<geist>
mrvn: you could start tyring to hide it under a layer of macros i guess, but i dont think it's worth it in the end
<ilovethinking>
gog: spitting straight facts
<mrvn>
nah, macros that have to "#ifdef ARM64" would be violating the spirit of the exercise
<graphitemaster>
run sed s/r/x on the boot.S when compiling for aarch64 xd
<geist>
anyway good luck. going off line here for a bit to focus
<geist>
also might lose power anyway, high wind and the power is flickering
<gog>
oh yay i fixed my own linker script woes
<mrvn>
don't you hate it when the turbines turn off before being overloaded?
<nikolar>
geist: hope everything is fine
mctpyt has joined #osdev
<graphitemaster>
geist don't you hate it when the power goes out and then you have to resort to digging holes in the ground to store your meat and collect rain water
<zid>
well, real systems, I assume qemu is also doing it but in reverse
<gog>
i never really looked why my computers built-in input is
<zid>
actually it may just be properly doing it
<gog>
i assume usb
mctpyt has quit [Ping timeout: 264 seconds]
<zid>
not sure if qemu connects the keyboard via usb or not
<zid>
if it does it's probably also got an smm path thingy in seabios, but that seems overly complicated compared to just connecting a ps/2 keyboard
<gog>
huh my touchpad is i2c
<gog>
my keyboard is ps/2
<gog>
or at least it claims to be
<gog>
i never looked at what the firmware config is
<zid>
yea i2c for the touchpad gubbins is super normal
<gog>
i saw the intel version of my computer on clearance sale yesterday
<gog>
it doesn't even have a type C usb
<gog>
sadge
<zid>
can you still do current negotiations and shit over usb A
<zid>
as long as it's a 3.0 port or whatever
robem has joined #osdev
<zid>
or do you *need* usb-c on the host end
<gog>
i mean
<gog>
not really
<gog>
frankly the type C port i have is useless because it doesn't support any alt mode
<zid>
nice
<gog>
i don't even use it
<gog>
be cooler if it had HDMI
<zid>
I have one A->C and one A->microB cable
<zid>
good enough for the girls I go out with
<zid>
The C charges my mouse, the B charges my electric lighter and plugs my xbox controller in :P
<gog>
i no longer have any micro B devices since getting rid of my vep
<gog>
vape
<zid>
bep
<gog>
and i'm 18 days nicotine free
<nikolar>
Just keep that going
<lav>
gog: yay
<lav>
:3
<gog>
as long as i don't go out drinking
<nikolar>
Not like you're missing out on much ¯\_(ツ)_/¯
<gog>
yeah
<gog>
all the bars here suck anyway
<zid>
smoking is a dirty costly habit that makes you look totally badass and masculine, so it's like anti-socks
<gog>
smoking makes you look masculine? ugh i will never again
<zid>
unless you use a ciagrette holder and silk gloves, yes
<gog>
oh shit holly golightly aesthetic
<gog>
it's snowing in new orleans
<nikolar>
Well isn't that something
<gog>
:D
<zid>
so there's a point opposite new orleans where it is also snowing, on a hairy ball, that is turned inside out
<gog>
i'm glad somebody got that reference
<zid>
if I remember my mathematics
<mrvn>
You know how people changed from cigaretts to vaps because the chemicals in cigarets cause cancer? Guess what, the chemicals in vaps cause cancer, too.
<gog>
yeahhhh
<gog>
also you get wayyyy more nicotine
<mrvn>
gog: are you saying male identifying girls should smoke?
<gog>
uh
<mrvn>
+zid
<nikolar>
smoking bad
<ilovethinking>
is it the right thing to do to iterate through bss and map it every 0x1000? because in bss something is skipped which causes a pf
<ilovethinking>
why can toyu just n++
<gog>
you can't simply "map it"
<ilovethinking>
for (uintptr_t n = (uintptr_t) BSS_START; n < (uintptr_t) BSS_END; n += PAGESIZE) {
<gog>
you have to allocate pages to map to the place it says it is
<ilovethinking>
why += 0x1000
<ilovethinking>
not +=1
<gog>
¯\_(ツ)_/¯
<ilovethinking>
because it pagefaults on an address somewhere in bss which is not mapped and off by 0x4 or some shit
<ilovethinking>
off by 0x4 from the rsp which is also in the bss
<zid>
I loop over max memsize filesz or whatever, then decide if there are still bytes of file left on that iter
<zid>
or if that iter allocates instead
<gog>
mrvn: idk they're complaining about pgae faults in the bss
<mrvn>
ilovethinking: ignore them. yes, you have to map everything between BSS_START and BSS_END (assuming you don't follow geist suggestion simply map everything rwx)
<zid>
by just decrementing filesize each iter
heat has quit [Read error: Connection reset by peer]
<mrvn>
gog: kernels do have .bss too
<ilovethinking>
mrvn: i do it but still there is a non-present page somewhere in the middle of bss and it's getting to me
<gog>
mrvn: i know mine does :P
<ilovethinking>
i can't figure it out
<ilovethinking>
i swear it's been 6 hours
<mrvn>
ilovethinking: if it's not present then you didn't map everything between start and end
<zid>
should I change it to MIN(p->p_filesz, 4096);
<zid>
and move that macro to #define MIN
<zid>
everybody loves 800 copies of #define MIN in their repo
<mrvn>
zid: you should forget about #define fn(x) existing.
<zid>
anyway, bookworm time, eated my sosig
wootehfoot has quit [Quit: Leaving]
<mrvn>
zid: can't you do "while (p->p_filesz > 0)?
<ilovethinking>
mrvn, i removed the 2mb spaces between sections
<ilovethinking>
couldve that fucked it up
<mrvn>
ilovethinking: unlikely.
<ilovethinking>
then i have no clue. genuinely.
<mrvn>
ilovethinking: unless you still have that huge page mapping
<ilovethinking>
it appears from nowhere and i have no clue why
<mrvn>
ilovethinking: so instead of fixing that you try to do 6 impossible things before breakfast?
<ilovethinking>
ok yeah i should probably
<ilovethinking>
do that
<ilovethinking>
thing is random address appears
<ilovethinking>
they are random
<ilovethinking>
fff80fff
<ilovethinking>
????
<ilovethinking>
where does that come from
<ilovethinking>
i don't have that anywhere
<mrvn>
didn't you want to start fresh without limine?
<ilovethinking>
i do want to but im emotionally attached to this kernel
<ilovethinking>
plus idk where to start
<ilovethinking>
limine spoiled me
<ilovethinking>
by giving me everything
<ilovethinking>
should i start off with a tutorial or smth? idk i can set up all of the things by myself, linking, building and everything
bitterlollipop has quit [Quit: system sleep - ZZZzzz...]
<ilovethinking>
yeah i think i should
<ilovethinking>
mrvn one last question and i go to sleep
<ilovethinking>
is it ok if i start off with a barebones
<mrvn>
if it works in the first place
<lav>
no you will go to jail
<ilovethinking>
gotcha
<ilovethinking>
goodnight
ilovethinking has quit [Quit: i probably locked my mac and i got disconnected]
Gooberpatrol66 has quit [Quit: Leaving]
Gooberpatrol66 has joined #osdev
fedorafansuper has joined #osdev
terminalpusher has quit [Remote host closed the connection]
<heat_>
<gog> i really have an itch to acquire a retro computer <---------------------- ITANIUUUUUUUUUUUUUM
<nikolar>
Like an itanium server just to serve files or something lol
<moon-child>
g/c?
<heat>
mjg would've made your itanium file serving slower
<heat>
he's seriously a disney villain for computer necrophiles itanium lovers
<heat>
moon-child, also what the hell is a vega 3?
<heat>
not the AMD GPU stuff right?
<mjg>
i learned that itanium can run i386 binaries
<mjg>
so i'm all for it now
<heat>
dude they had chipsets (internally) that could have an ia32 processor and an itanium processor in the same machine
<heat>
imagine that
<mjg>
but they did not have a sensible 64 bit chipset
<mjg>
hehe... he... don't hit me
<heat>
fuk u vax lover
<heat>
go back to UC berkeley and write software for the VAX
<heat>
i'll be here using IA64 and sparc
<heat>
hp-ux and solaris >>>>>>> BSD
<Ermine>
vax smells good actually
<geist>
moon-child: yeah i remember pseudo-interviewing at azul back in the day
<geist>
they had a neat thing
<geist>
glad i didn't take it since they pivoted like 3 or 4 years later to software only
<gog>
iapx432
<Ermine>
Want: server and colocation
<geist>
they will want: lots of your money
<heat>
gog, more like boringx432
<gog>
:<
<gog>
want: pets and foods
<geist>
i do remember back in the day (early-mid 2000s) it was pretty common for folks to join together, jointly buy a box and get it coloed
<Ermine>
geist: that's the thing
<geist>
might be say $200/mo at he.net, but split 4 or 5 ways it wasn't that bad
<geist>
now vitualization mostly makes that moot
<gog>
let's all get a colo
<gog>
i want to host a mastodon instance before mine gets defederated
<mrvn>
heat: if you spend all that money on an itanium server then why do you want to run x86 code on it?
<geist>
note ia64 machines ran x86 like butt
<heat>
shhhhhhhh
<heat>
hater
<geist>
it was more like it had a very slow, in order, front end that did the basics, enough to run firmware, etc but really not what you'd want
<Ermine>
geist: 2U is in that range from what I see now
<geist>
Ermine: yeah that sounds like right. of course it's higly dependent on the place you get it coloed, etc
<mrvn>
xfree86 had an x86 emulator too to run gfx card firmware on alpha
<heat>
you could also just get an amazon bare metal machine
<heat>
probably cheaper
<geist>
for a brief period there sun had the little Netra T1s i think. $1k ultrasparc 1U box. nice for simple coloing
<Ermine>
btw, gog: do you want to have pets or be petted?
<gog>
yes
<geist>
since it was pretty generally hard to get a server without paying a ton for it
* Ermine
pets gog
* gog
prr
<gog>
dang atnorth doesn't list their rates i need to get a quote
* Ermine
gives gog a fishie
<gog>
not worth it
<heat>
you want a quote?
<gog>
no
<mrvn>
Do you know what I find truely horrible? I have to run Android Studio in an x86 emulator on my phone to build apps for my phone.
<geist>
i remember a few years later building a 1U with a pentium 3 and getting it coloed at work. that was anther common thing that folks did in silicon valley. sweet talk their companies admin to dedicate a rack for personal boxes
<heat>
“Love is a serious mental disease.” - plato
<gog>
i ran android studio a long time ago in x86 and it was really bad
<geist>
was a simpler time
<gog>
very slow
<mrvn>
gog: it is
<mrvn>
gog: but it's the only way to build android apps
<gog>
gross
<gog>
now i know why people write web pages and just use a browser view to show them as an app
<heat>
have you noticed that gog with an extra o = goog
<heat>
are you alphabet inc
<gog>
i am
<geist>
or an infinity symbol
<mrvn>
gog: doesn't really matter if you run java(script) as App or in browser.
<geist>
g∞g
<heat>
give me stock gog
<mrvn>
what do you call a little gog? google
* gog
pours soup base into heat's hands
<geist>
g•g g·g
* lav
puts on some goggles
* gog
acquires lav
<heat>
omg google glass moment
<geist>
gøg
<gog>
why are y'all gogging me rn
<heat>
omg google glass is still a thing
<lav>
omg
<gog>
omgog
<geist>
ømg
<heat>
it's like the biggest what if in tech
<heat>
computer, but in your glasses
* lav
:3
<klange>
stupidest public backlash to a tech product in recent memory
<gog>
colon threeeeee
<lav>
guess they weren't in a gog of getting rid of google glass after all
<heat>
well obviously you naturally have some privacy concerns
<nikolar>
*some*
<geist>
the exact same concerns that folks freaked out for when cell phones first got cameras
<heat>
which is why they never should include a camera
<gog>
as if we don't already with phones whose microphones and cameras aren't already recording continuously anyway
<geist>
right, that was a freak out that then just got steamrolled, because whatcha gonna do
<gog>
¯\_(ツ)_/¯
<heat>
i don't think that's the main concern
<heat>
at least not for me
<geist>
no, but it was part of the stupid public backlash
<heat>
i'd be concerned with just random weirdos using it to creep around
<lav>
nini char o/
<geist>
which they do with cell phones now
<gog>
yeh
<nikolar>
It's even worse for glasses because it's kind of their whole thing
<heat>
yeah but it's much harder to take a concealed pic and all
<geist>
exactly, so in that regard it's sort of more obvious because its strapped to your face
<geist>
vs all the other ways you can try to hide a pic on your phone
<klange>
back in my day, we just hid a camera in a bag and no one would notice!
<heat>
how's it more obvious?
<gog>
most people have thier phones out pointing random directions anyway, a creep taking a creepshot with a phone isn't guaranteed to get anybody's immediate attention
<heat>
only if you did something like a mandated flash or something
<gog>
but a google glass on your fasce is very uncommon
<geist>
i think the main issue with google glass is it was just kinda dumb. you could't really do anything with it and it stuck out
<geist>
you could wear it around silicon valley and folks would have been interested because tech
<gog>
i just don't wanna wear the computer display on my face
<gog>
that's me
<geist>
but a lot of places there was some amount of social engineering you'd have to do to normalize it
<klange>
It was fantastic for bicycling - maps right there in my field of view.
<geist>
and that's the sort of thing apple can pull off because it's fashion
<geist>
theu'd normalize wearing white earbuds, or red headsets of whatnot, because apple
<gog>
i wear white earbuds now :|
<heat>
Users have been derisively referred to as "Glassholes".[121]
<heat>
hahahaha
<geist>
and they go right after the fashion as a status symbol. like all the early ipod commericals where they were making it cool to carry this white thing that sticks out with the wire
<heat>
gog, i also wear white earbuds now, but samsung ones
<gog>
mine are uhh
<gog>
i forgot the brand
<gog>
urbanista
<heat>
because apple bad, other apple good
<geist>
in the era before that it was all about the white wires down to the ipod, because that was status
<heat>
i did consider the actual airpods but man, these things are all so incompatible with one another
<heat>
i'm fairly sure I'd miss all the good stuff if I used the samsung ones on apple devices or maybe even another android OEM
<heat>
something something e c o s y s t e m
<geist>
FWIW the google ones are pretty good and should be pretty compatible with anything android
<geist>
and i have paired them with a mac and ipad and they work fine too
<heat>
even noise reduction, ambient mode, etc?
<gog>
mine have noise reduction and ambient mode
<Ermine>
Can confirm, airpods work best only with apple tech
<gog>
they're cheapies too
<gog>
i like them a lot actually
<klange>
I prefer over-ear headphones _or_ bone-conduction.
<heat>
the annoying bit about anything google hw is that they don't actually sell here
<klange>
In-ear stuff feels weird and uncomfortable.
<heat>
so I can't get it directly from google
<Ermine>
They show battery level and can be configured. On android you need third party apps
<heat>
Ermine, yeah, i dunno if the samsung wearable app can be installed on !samsung but that contains most of the goodies
<heat>
also firmware updates, etc
<nikolar>
heat: what do you have against e c o s y s t e m
<FireFly>
bone conduction's interesting
<heat>
i assume apple has the same problem
<nikolar>
It's clearly for the benefit of the user
<mrvn>
klange: you want some pretty pictures obscuring your field of vision when cycling down a busy street next to cars?
<klange>
I want to be able to look forward and see the cars while also knowing where my turn is instead of looking down at a phone in a mount.
<mrvn>
My phone has front and back cameras but what it's missing is a top camera so that when I walk while looking at my phone I can use split screen and see where I'm going. :)
<gog>
:)
<klange>
Give me a carplay/android auto projection into Glass instead of the normal Glass stuff and I'd be back to using it constantly.
<mrvn>
klange: Since you aren't allowed to wear headphones in taffic and looking at the phone in a mount is distracting too a friend of mine build some force feedback thingies into his handlebars. So when you have to take a right turn the right side vibrates.
<klange>
Not being allowed to wear headphones on a bicycle is why I got into bone conduction headsets.
<mrvn>
Another thing I saw recently was a camera/projector setup that projected the outside view on the inside of the car between the front and side window making it transparent.
Turn_Left has joined #osdev
<gog>
hmm
<gog>
sysretq
<gog>
it sends me to oblivion
<gog>
wait wait
<gog>
maybe the return address is getting clobbed
<Ermine>
syscallq
<bnchs>
i like when i fuck up the stack and try to return
<gog>
aha
<mrvn>
so print the register content and stack frame before you return.
<gog>
i need to push rcx before doing anything else
Left_Turn has quit [Ping timeout: 246 seconds]
<heat>
im making my IO stack do fully async IO
<mrvn>
heat: congrats
<gog>
i'm gonna do tha ttoo
<Ermine>
heat: is it io_uring kind of stuff?
<gog>
i'm gonna write a full windowing system and gui toolkit too
<gog>
in COM
<heat>
Ermine, no
<heat>
io_uring is just an API
<mrvn>
Ermine: io_uring is just a transport method. you can do that for sync IO too
<heat>
my kernel ATM does fully synchronous IO i.e make a request and wait for it
<heat>
so it can't do useful things while waiting
<heat>
i'm migrating drivers to a more natural way to do things - you have an IO queue, you queue requests, when they finish you queue the next one, etc
<mrvn>
heat: why wait? do you have flush and barrier things for the queue?