#EvalynOS
1 messages · Page 29 of 1
amdgpu drivers 💀?
If you ever get a new machine try out Linux a bit because you know you wana wipe the OEM parition anyways
but im lazy and id rather just leave the windows that came on this laptop on it lmao
Yes actually that's an ongoing project lmfao
Hell naw
unlikely to happen soon unless i luck into enough money to get a fred machine lmao
Put me behind 3 lead doors away from that bullshit 💀
i might see if my dad has any old laptops he doesnt need tho, if he does im taking one and putting arch on it and then not using arch on it most of the time anyway because itll be an osdev test bed
Well when it's finished it will be portable and maybe integrated into lil
Idk if @haughty acorn would wana work on it though
It will be C++ or C I think?
Probably C++
i had enough in c++ in 2012 and then kept working on that project until like 2014 lmao
Though some of the external tooling could be in zig
Since we are working on some other helpers for disassembly and other shit
if any of you know MultiMC, you can find a link to my twitter in the about menu of that program
because i worked on it
most of what i do nowadays for multimc is get pinged as part of the moderator role when people ignore the multimc discord's rule about not asking for help for forks lmao
lmfaoooooo
yup thats me
how hard is it to read 
i also get pinged when people start using slurs or trying to sell scams lmao and thats far more common
apparently harder than you or i thought lmao
mhm
but yeah trying to get Qt5 and mingw and whatever editor i was using before clion or vscode existed all working together to work on multimc is a part of why i have such cranky old woman yells at cloud energy sometimes lmao
that and constantly watching modding people fighting each other
i used to do MC modding
i made some of the most hacky shit that should have never worked
i have had some plans to get back into it
but large backlog of ideas lol
wanted to make one for a pack that used immersive portals to make an infinitly tall world you can fall though, and every vertical segment shuffles its self as you go through it
so as you explore the world shifts behind you
nice
i used to be more involved in mc modding (albeit from the multimc side and the user side moreso than making mods) but i saw so many fights and community trying to rip itself apart so often that i just got. melancholy about it. and stopped
I hate the fragmentation with mod loaders
Neo forge and fabric is plenty
Then there is like 5 other random loaders that pop in and out for no reason
thats not a new problem lmao
Mmmm yes let's needlessly fragment the modding ecosystem more for no reason and make it worse for everyone
goes back to flowerchild
Yeah but it was getting better at some points
Alot probably was due to forge and lexmanos being kind of a dick iirc?
I never interacted with him that much
And wasn't a hugeee scale moder but
neoforge exists because they tried to put a woman on the forge team and lex was such a dick the woman went to quit, and then cpw came out of retirement and did a hostile takeover of the forge discord server to yeet lex from things lmao
yeah
hes always been a dick
the first unnecessary modloader split happened in late may-early june 2013 btw
its just that forge had such a monopoly that until fabric happened all of the splits were people going off on their own to do no-modloader stuff after being in fights and getting pushed away
the way i describe my feelings on mc modding stuff nowadays is its like a veteran walking out on an old battlefield they fought on and getting flashbacks to how things went down and friends were lost
I wish I was ever ingrained enough into a large community to witness stuff like that
I've had a few things happen but nothing to large extents
Like the Xbox server doing stupid shit to a good mod and then covering up the entire thing
🥀
watching communities fall apart like that isnt fun. being in a community is nice though, so its usually worth that risk
Yeah the falling apart isn't fun but sotimes smaller dramas can be Entertaining
I do quite like this community though
Everyone here is cool
I wouldn't want anything to happen here

ive watched the mc modding community tearing itself apart again and again for over a decade now. theres a different community that i literally had to take sides in a massive fight. and now im simultaneously scared to get invested in communities again but also cherish the ones i can be a part of

Why cant the dramas be stupid and funny
And not ruining the entire thing
I am very young tho so I'm yet to get into things very big™
mhm
one of the guys i always liked in the mc modding community recently got a terraria dev armor set so at least chicken bones is goin in a good direction lol
Oooo that's cool
I should try and get back into playing modded Minecraft
But it's lost its spark for me sadly

I should start making dinner though and going to sleep
Might take a break from working on it tomorrow
And then work on refactors if I'm feeling up to it
I Wana sleep before 1:30 because I slept at 4am yesterday

Gtnh scratches the same itch on my brain as osdev
gregtech... now that's a name I've not heard in a long time... a long time...
you know you've been in a community too long when you start unironically doing that obi wan gif lmao
I've build a fusion reactor on a 1.6.4 server, but then they wiped it while I was on a school trip (which I didn't want to go to) 
Funnily enough I did try and play gtnh
Couldn't get into it fully

I probably would like to try again
But I'd need good friends to do it with
hmmm
today i shall do that refactor perhaps

arch/{arch}/arch among other things
arch/generic wont need an extra arch subfolder though as its meant to be included by other things anywhere
though i wonder if i can just phase it out
and add a misc folder for some things under utils?
whuch i alr do have
i can put the panic boilerplate there
i also am consering doing my riscv port a bit earlier perhaps
after LA64 paging and irqs maybe?
will then need to refactor 3 paging codes though

since il have to rework them once i have PFNDB and better OOM handling
Fuck it we ball
Im going to port riscv before the other refactors
Since it won't be that bad since alot of the paging code can just be reused when I refactor it after regardless
why not make the root platform instead of arch? feels just as reasonable esp if there'll be stuff outside the arch subfolders and makes the paths look less weird not having the word arch twice
Yeah I could do it that way
Then it's #include paging/whatever
Then what should I do for things I want in the root level there though?
Like panic I probably want to be able to do #include arch/panic.h
And not just panic
Also instead of including arch/generic/whatever the arch specific header will include the required generic header for you
So you just do #include arch/paging/paging.h
And that includes the generic paging header too
Maybe?
Idk that sounds worse
I just have arch/paging.{h,hpp} for the arch-specific paging stuff like page flags + an arch/paging_internals.{h,hpp} for some internal stuff the generic paging impl uses (like the level count, size of a level + some other misc things like that)
i think i can do this. arch spesific things will shadow generic includes.
then the arch specific implementation pulls in the generic header which will contain the generic interfaces & other defines?
-I src/arch/${ARCH}
-I src/arch/generic
wait no i think ive got it
-I src/arch/ \
-I src/arch/${ARCH} \
Then code does include generic/paging/paging.h
But that solves nothing really

The other option I guess is making the generic files ifdef every architecture and including the architecture backend for them :/
Which would only need to be done for like a few of them tbf
Just the ones that have inline assembly
the only files like that are
interrupts.h
halt.h
mmio.h
il do it like this
merge interrupts.h and halt.h into intrin.h
put that and mmio and panic into arch/generic/lib/
and then intrin.h and mmio.h have to get updated for any arch port to ifdef && include the right backend header
Other things won't be static inline in headers so they won't need ifdef soup
And relegating ifdef soup such a pattern it ends up working
stop overthinking it and start writing 
i think ive solved it

#define STRINGIFY_IMPL(x) #x
#define STRINGIFY(x) STRINGIFY_IMPL(x)
#include STRINGIFY(arch/ARCH/lib/mmio.h)
Then arch just gets passed as a -DARCH =
Then the generic headers can just do that bullshit
Bruh
What 
It works
but why, this seems way more cursed than just having arch/<arch>/include/arch/paging.h + -Iarch/<arch>/include
- less refactoring work
- the directory names look nicer
- I don't really want an include folder
It is very fucking cursed though
i dont understand overengineering
does any of that matter if you have like 3 arch specific headers used from generic code?
Well people get mad at me with whatever option I pick. I talked to wux about just hard coding the ifdefs for the few headers and they said that wasnt good so 
This one at least automates that work with some macro BS and lets me keep everything which ticks all the boxes on this refactor
Bruh
and since this is pissing everyone off it makes me want to keep it too /hj
just -I the architecture and include based on a known path smh
Keep over engineering
I have considered this but it has other downsides
like what?
Most programmers stop right before it’s perfect
Makes the folder paths look ugly
Who cares
arch/arch name/arch
I CARE
I am the one who asked
All of this stems from you using Kate btw
thats why i suggested platform/something/arch
If you used a decent editor this wouldn’t be a problem :p
Wait this is what you meant
yeah?
I thought you meant it the other way 😭
platform/archname/arch is just arch/archname/arch but fancy
didnt realise it was unclear but i woke up sick to my stomach so i was struggling to communicate
How would that work?
and also doesnt include the word arch twice which helps
Ah same thing but fancy lol
I guess
You know
At this point
Just hash all the folder names
Who needs them
You still have a folder with one child though which KATE does collace
Sourcehut actually doesn't collace that lmao
it’s 1 extra click oh no
Which is another reason I want to avoid that
youd put other stuff in the arch's main folder, like arch-specific peripherals and shit
at the cost of insane over engineering
ye
the arch subfolder would be more like the asm subfolder name linux uses for everything and be the stuff that generic needs to include
Yeah see this is fine
yeah
include folder in src is questionable but fine
So platform/x86_64/arch has the generic headers
And then it can have other things there etc not under arch
i havent used a language with headers since 2015 and multimc puts headers next to cpp files instead of in a separate include folder lol, cant speak to that part
yeah
That could work but then I loose the generic folder and other things.
I'm probably either talking myself into the cursed macro solution but I guess I dislike the other ways of doing things. My brain likes having it this way tbh 
I guess private headers maybe? But imo it’s just ugly as fuck
(at the end of the day do what you like, just dont be surprised if other people dont want to work with the codebase when doing that macro shit)
Headers suck so much
multimc is an executable only with zero public api so it worked for us
None of this would of been a problem if you used rust :^)
or zig
Fair fair
Or hell fucking javascript does it better
I just wanted to keep it inside the arch-specific folder and the separate folder means that I don't have to add the main arch dir to the include path (+ it doesn't look as ugly as having arch/x86_64/arch folder to me)
Fair enough, it’s all preference anyway
I tend to not even notice arch/x86_64/arch
literally the important thing is to have a system and stick to it
Yeah
whats the system? idk i aint you. but make one and stick to it
Pure vibes “yeah this feels like it belongs here”
my os has hal/arch/%ARCH%/ for the path to arch specific stuff
and not-arch-specific code for stuff like interrupts etc lives in hal/
Welp whatever works for you I guess
solution: stop using the C preprocessor and write your own
stop using C, write rust /j
in my thing of "pick a system and stick to it" you could take "stick to it" as the same as commit to the bit lol
so if you do this then commit to the bit
Well then I have the same retarded system but worse
Because I have my own pre processor
To me it seems like you're overthinking it
So I might aswell work within it
I quite like where I ended up personally
Oh 100%
But I think I'm finnaly content with this solution
i think ive also killed two birds with one stone
arch/intrin/* contains the fucky headers that auto redirect to the arch folder coresponding in arch/${ARCH}/intrin
and then arch/${ARCH}/intrin can addininaly have arch spesific intrinsics like CPUID portio MSRs/CSRS etc
And that feels like a much nicer place to put them
Because they basically are just intrinsics / wrappers around raw instructions
The only one that's borderline is CPUID on x86 since I do some more advanced wrappings but eh
Panic may? Just continue to stay at the top level though. Or I shove it into a panic subdir
oh this is an excellent solution
Thank you ^^
Only took me two weeks to think of this properly 😭
At least it was worth it

I also wonder if I should document my kernel and the public API functions and other architecture stuff

Maybe after I get it to the MVP state I'm working to?
I'd probably start with the utils folder for that stuff
Since that's the most important stuff to document as it has alot of the data structures and locks etc
maybe generic panic can be moved there too?
i think il only move portio into the intrins since its basically just that
the other files have some other stuff that may not fit
and then arch/cpu looks really empty otherewise
it may end up with cpulocal being the only thing there
if/when i move smp to its own folder
actually CPU local may be an intrinsic type thing
since its a pointer de reference on a spesific register in many archetectures
eg la64 has one
and x86 is similar but fancy
other arhctectures would have to define thier own macros that do so similar crap

when i do cpu local stuff then i will probally the other things into intrin with it
In any case I think stuff is proper for these refactors enough
Il clean this up and get it commited tomorrow
Then work on getting the bare bones of the riscv port working
And then exception handling on both
And the refactor with those after that
Since I wanted to move thoes arround a little
But I need them more complete on non x86 platforms for that
cc: @wraith star
The sourcehut repo is out of date
But the main home server should be fine to apply these on
okay,lemme compile this
You can probably skip the jinx steps if you just put the limine and OVMF shit in the right place btw
The make file for the kernel build skips jinx by default
how do i do that?
i see its validating and retrieving some stuff
i ran make bootstrap
then you dont need any manual steps
make bootstrap just takes ages lol
Eventually it will properly build the entire distro tho™
does it do that yet?
Nope it just compiles limine and pulls down ovmf
Just mentioned as of now you can skip it if you want to
after pressing enter
oh wait nvm

its using clang
let me update my system
god i hate cuda 
every time i have to update i have to download 4gb of cuda garbage
This is why I uninstall the ROCM shit if I haven't used it in a while
It's so annoying
Not that ROCM works anyways but

That and SMRRs help Prevents cache poisoning
Are you going to implement something for evalynos?
They're reporting a bug
Ah
Well i think this is more bizarre than a simple bug
i have also suffered from smp bugs
My kernel has had so many bizarre random ass fucking bugs

most commonly its forgetting to set some cr4 bit
I've had these
or some assumption about the segment registers
this is so random 🥀
I do have a nice way to set registers via an assembly macro though and a bit field for what things need diddling
If that does happen to be the case
That's every single major evalynOS bug
It's never something simple
Maybe I'll test it in my machine too
I have a bios system iirc
Go my minions
So it crashes when you do i440fx + seabios?
give iso
Or are you trying something cursed like q35 seabios 💀
That is what atie had it crash ob
it crashes on that too tbf
Huh
Of course not
Well after looking at the code a few times it seems to me like it is
Seabios's code
seems to die somwhere here??
what qemu args cause it to die?
mov eax, [x86_ap_trampoline_cr3 - x86_ap_trampoline + ebx]
mov cr3, eax
Maybe the cr3 is bad
qemu-system-x86_64 -enable-kvm -cdrom evalynOS.iso -m 1G -smp 2 -cpu host -chardev stdio,id=debugcon -device isa-debugcon,chardev=debugcon -d int,cpu_reset -no-reboot -no-shutdown -D qemu_log.txt
does it die without the patches?
why would that only happen on this platform?
Probably because you rely on some cpu features being pre enabled like nx
EBX is ending up zero here
Which they aren't on APs
evalyn
dw, the problem was that the limine version i copied was too old
istg
well paging isnt enabled there for one. and i already solved that issue a while back
Oh
did I not tell you already to fix that
or is it something else?
What about the global bit

EBX is zero
oh shit
that requires something?
Yes
do i even use the global bit is the queston??
cr4 bit probably
Well do u even set the global bit on pts
iirc yes
Do u use the limine ap thing
yeah I use global
iirc I mostly nuke all cr flags
well , enabling those bits is not enoigh apparently
anyways, i gtg eat, if you dont solve the problem by then ill look harder
which isnt good

is this with kvm enabled?
yes
other registers are filled?
those are the register values after reset
in kvm when a cpu triple faults qemu sees it as if it reset
with tcg this does not happen
tbf is that EDX value
It is
then it's probably flags bullshit
It's technically something like initial CPUID
Should be what you get from cpuid[1].eax iirc
Like atie said though I wouldn’t trust this triple fault message lol
yes
BUT
thats where it dies

mov eax, [x86_ap_trampoline_cr3 - x86_ap_trampoline + ebx]
Gdb
weko that will be annoying with relocated code but yeah
What’s the GDT descriptor values at that time
oh the cpu just ignores the global bit on ptes if it's not set
:P
How do you know the base is correct
Have you tried hardcoding the base aswell instead of calculating it on the fly
well my breakpoint isntworking :p
it calculates it on the BSP
use hardware breakpoints
oh gg
I AM USING HARDWARE BREAKPOINTD
jesus okay chill
and the base is zero
I mean in your AP code
????
Because that’s the first time you touch ebx right
Fairs
and it is picking a proper space to relocate to
being the second free lomem page

this should be fine aswell
????
In what address do you start your AP trampoline
i allocate it on demand and patch on the BSP
Because if you're doing so in like 0x00000 that doesn't sounds very good to me
There's the IVT still there when you start
nah i avoid the first page alltogether
And since you're in real mode at that point it still matters
i allocate via this bullshit 
Ah
Also would it if you don't get any interrupts?
Since that would kill me regardless
And it dies in protected mode
For some god forsaken reason
what happens if i skip prot mode?
Maybe it's just some random NMI bullshit
Weird
what does it die on
mov eax, [x86_ap_trampoline_cr3 - x86_ap_trampoline + ebx]
how does it die
Triple faults
ok but what exception
can u paste qemu log
truke

qemu-system-x86_64 -enable-kvm -cdrom evalynOS.iso -m 1G -smp 2 -cpu host -chardev stdio,id=debugcon -device isa-debugcon,chardev=debugcon -d int,cpu_reset -no-reboot -no-shutdown -D qemu_log.txt
I mean with kvm u wouldnt get the exception in log anyway
well it died on real hardware as well :P
is this with kvm?
Yes this only happens in KVM
And only with SEABIOS
if issue still persists, in an hour or two when I am home, I can debug
Well GDB time it seems
GDB hardware breakpoint isn't even working
🥀
That address is where it gets relocated to
Maybe it's because it's never actually getting there
Are you sure that's actually a HW breakpoint
Because QEMU could very much just pretend
hbreak does a hw breakpoint iirc
I doubt it
; setup CR3
mov eax, [x86_ap_trampoline_cr3 - x86_ap_trampoline + ebx]
this is where it faults
but setting the breakpoint on that insn doesn't work?
It's relocated to a place in physical memory and a breakpoint was set to the start of the trampoline where it gets relocated to on that config
No dice
The fact that it is the AP startup is probably fucking with the breakpoint
I wouldn't be surprised if the virtual AP init had bugs that means breakpoints are broken in KVM
bruh
ds is 0x00
you did not reload segment registers
now it goes all the way up to the far jump to long mode
Isn't that technically not required 
yes it is

Damn I striped that code out for code size
Because it worked on everything I tested it on
WTF
suprisingly using 0x10 as data segment index works
Stop overoptimizing early
when at that offset you gave 64 bit code
I thought the other segments were ignored 
Especially for size when you're only saving INDIVIDUAL BYTES!!!!
Completely counterproductive
pls bring back the 32 bit data register lol
and usei t
dq 0 ; Null entry
dq 0x00cf9b000000ffff ; 32-bit code
dq 0x00cf93000000ffff ; 32-bit data
dq 0x00af9b000000ffff ; 64-bit code
dq 0x00cf93000000ffff ; 64-bit data
Let me put it simply: Do Not Optimize before you clearly have a problem and identified where it is
its literally the same value lol
i know, i see lmao
unless you set the long mode bit which is ignored on everything except the code segment
Long live the GDT, possibly the ugliest cruft left over from segmentation
no shit sherlock
no need to be rude :p
you were basically just hoping whatever the reset value was was correct before
also
well sorry that i wanted to spend some time hyper optimizing something when i wasnt feeling well and was bored and diddnt catch this crash in a BIOS path lmao 
in the trampoline, is the hhdm mapped?
esp when bios crap had other issues
yes
also it works now
this was the extent of the bugs

i can probally skip loading es/fs/gs but then il get yelled at 
@wraith star @tender mantle @vocal estuary
thaks for all the help
this should patch it
I’ll check on that pc later
It worked on like the 3 real machines I tested it on

And tcg and OVMF kvm
Maybe I should add a BIOS target to my make file
So I can do extra testings on thoes paths
yes
I think after I get all ts committed
I'm gonna work on some LA64 stuff
Then work on CPU local for both architectures

On LA64 it will be a CSR that holds the base that needs to get reloaded on any context switch change
To the thread pointer
Privilege change*
Or thread migration?
Idk when exactly I need to reload the register

@hushed oracle how do you handle this on LA64 and riscv? I know there is a special ABI register for this along with one of the scratch registers.
But my brain is blanking on how to properly do it 
I don't switch it 
It has my per-CPU struct where I change the current running thread pointer to the TCB because 1 stack per CPU
But it's a scratch register which you can change, yes
I mean for when I should reload the GPR
The scratch registers has that CPUs point of truth yes
And the csrwr instruction has a bad name, and it actually swaps the GPR and CSR
So you can use it as a scratch register
And their NMIs have separate entry point...
Issue is it's probably slow right? So I want to keep it in the unused elf ABI GPR or whatever
Until I'm at a stage I don't know it's valid
You only reload it on task switching
Userspace doesn't have access to CSRs
And their TLS pointer is one of the GPRs
So you don't have to do anything special or swapgs like on x86
Not the CSR the GPR. Which I guess would be the same? Load that CSR into a GPR on every task switch
You can do that, yeah
and because running tasks can't migrate it should just work??
Then when you return from an interrupt, it just restores all GPRs
I guess
Since whenever you switch it loads properly
The compilers don't touch that register
I'd also have to load it at interrupt entry from userspace
Yeah which is why I'd wana use it right? And I can also have a similar thing with gp on riscv
There is only 1 entry point
I think GP is only a thing on RISC-V
TP is exactly the same between two
Yeah but isn't it a similar concept to this given on la64 it's just unused?
And interrupt handling is also basically the same, just with slightly different CSRs
You don't have to do anything special for it in kernel
I just am trying to make sure I know how CPU local works on RISCs
Since GS: is really nice
It's just a GPR
Yeah exactly, and then I just reload the GPR on certain spots eg task switch and syscall/interrupt entry etc
yeah, i.e. you don't do anything special
I mean if you mean for kernel, you can also probably just tread it as a saved register (I think it is a saved register actually per ABI)
I meant more so for making sure that the register dosnt explode on task switches and when they migrate cores and other things
I probably want to avoid it ever being touched by things like that?
And it getting re loaded after a task switch completes on the new stack
I don't know, it depends on your kernel's design

Fair
I guess il deal with the millions of bugs when I do this

And struggle hard
Idk I haven't had task switching bugs for like 3 years now 
I feel like it's only a problem when you don't know what you're doing
RV/LA are much simplier
Like x86 has a bunch of weird bs that you have to deal with
Though on x86 I get single cycle cpu local stuff and it's in a permanent register I don't have to worry about too bad 
By abusing the address calculations shit
On RV/LA it's a GPR, so basically the same but with less limitations
Like no need to do gs:0 weirdness or whatever
Yeah so it should be mostly the same except instead of a swapgs is a rdcsr ig?
yeah
or rather wrcsr
You do wrcsr of tp to the scratch csr (idr its name), then you can save it from there (if you don't want to clobber any registers)
But also the ABI gives you a scratch register which you can clobber as a kernel
Which you can't use as userspace
Yeah that was me plan
Which also makes nested interrupts easier
yeah
Crap true
Userspace may be using that
Like it's on you if you use it as userspace
I don't like the idea of it since you can then know when you've been preempted and stuff, but like it's probably totally fine
I know it wants fs
No, noone can use it
Hm?
How would I handle it with the wrcsr case
The only valid place to store cpulocal on RISC-V is sscratch
Again, it's the only place that makes sense because of how RISC-V exceptions work
It is explicitly intended to be used for this
Yes of course, but isn't there some GPR it has to go into when you use it? Or in every case you use it you have to do a CSR operation to get the value and then use it
LA is basically the same but with different names
No it's a CSR operation you can read it into literally any register you want
RISC-V never assumes a specific register
I mean on every single CPU local operation do you have to load it from the CSR?
At most the compressed instructions assume regs 0-15
Isnt that slow / serializing etc?
Not necessarily
Never
There is NO guarantee about serializing on CSR ops
With the sole exception of writing to satp of pmp*
So when do I need to load from the scratch registers
When you enter the kernel
When you want to access the CPU-local data
But you can just use tp
Once you load it once
Still has to be in sscratch while in usermode
Yes
But yes you can cache it there if you don't use tp already
so I could on every entry into kernel space load it into tp. Which should work across thread migrations etc? Since tp either won't get touched there or it has to re enter into kernel space on the new core when it does???
And I can cache it in gp on riscv too ig? Or tp too
Don't put it in GP
TP is fine
What even is gp? Also I presume I don't really even need tls on my kernel because CPU local does most of that job anyways
My opinion is just use relaxation relative to GP because they must've added that for a reason
Again, it's the address of the __global_pointer$ symbol, to which there could be implicit references
(Unless you do -mno-relax)
Just put it in TP though, especially if you weren't using TP yet already
I still have no idea what tf relaxation is
Yeah that works out
Idk if I'd even really want tls regardless in general
Stuff close to __global_pointer$ needs only 12-bit signed offset
it just puts symbols near __global_pointer$ so they can be accessed via the gp register (I assume)
Whereas most symbols use either an absolute or PC-relative or GOT/PLT address
like how -2gb on x86 has optimizations for access afaik
Idea is that things likely to be accessed more often (and that are small) go into .sdata, .srodata or .sbss, sections which are near __global_pointer$, so that you need one less instruction to access them
And since you were over-optimizing your x86 shit, why disable this?
Yeah exactly
But you can disable it and then gp would be unused
I can just use tp for this
And then on la64 its the reserved register
And I reload it on any kernel entry via a swap of the CSR
Though don't I need to check if it's already been swapped before?
Yeah so LA64 has basically the same thing
You can't permanently swap this
You do that only temporarily to have somewhere to put that register you have to save while loading the CPU-local data
That's why I have scratch space here:
/// Architecture-specific CPU-local data.
#[repr(C)]
#[derive(Default)]
pub struct ArchCpuLocal {
/// Stack pointer to use for interrupts; NULL to use current stack ptr.
pub irq_stack: *mut (),
/// Scratch space used by the trap and interrupt handlers.
pub scratch: [usize; 3],
}
So how's that helpful for not clobbering tp?
I'm sorry for not understanding any of this 
See this:
riscv_exception_asm:
.cfi_return_column 64
.cfi_signal_frame
.cfi_register 64, sepc
# Get the cpulocal ptr.
csrrw t0, sscratch, t0
# Normal save of T1.
sd t1, 24(t0)
# Restore sscratch to be cpulocal ptr again.
csrrw t1, sscratch, t0
# T1 used to save old value of T0.
sd t1, 16(t0)
I am saving t0 to sscratch temporarily, saving t1 to ArchCpuLocal::scratch, then swapping back and moving the old value of t0 into there too.
Now I have the old t0 and t1 preserved, the CPUlocal in t0 and t1 usable as scratch
Later on these are copied back onto the stack, but the stack has not been loaded here yet
A simpler sequence happens in reverse to load the context before doing sret:
# Restore the last regs.
ld sp, 8(t0)
ld t1, 24(t0)
ld t0, 16(t0)
# All done, return from exception handler.
sret
But what happens in the case of an NMI where then scratch is in a middle state with invalid data?
Ah that's interesting
Otherwise you have the RNMI extension, which gives you a different vector than the standard stvec
I think LA64 HAS NMIs though similar to that extension???
IMO NMIs have no place in modern CPUs
Unless they're fatal
For example, a machine check on x86 when trying to access vacant physical memory right?
On RISC-V you get an access (not page!) fault instead
Which is synchronous instead of being an NMI
You also have these for other failures
Okay but yeah the scratch registers stuff should work out in other cases
Which are, again, synchronous
NMI can go through stvec but unless you have the RNMI extension there is no standard how how NMIs work
And again, it's only supposed to be for fatal things, so chances are the firmware catches it and resets the machine
Oh
S-mode can't catch NMIs anyway
So don't worry about them
It's always into M-mode
Ah so I don't have to deal with them myself ever
Good
Now about them on LA64 @hushed oracle 
If that works all properly then I should be good to go
ugh
Being with the proper handling on exception entry and task switching it should all work
nah drop x86
And don't do another rewrite for the love of god
If you do that you are helping me with my riscv port :p
And la64 one too
the great part about it being my kernel is you have no control over that
tho if I was to support another arch
idk what it would be
anything but aarch64 :^)
I have basically the same thing
It's a separate entry point, which also disables paging (since you can't refill tlb)
I don't handle them 
But idk you handle them as normal?
I guess you can even enable paging and stuff and jump to a normal entry point, if you really want that
(after you normalize the CSRs)
Issue is
How the fuck can you get a stack
Or like
Do anything properly
I guess you can use one of the secondary scratch registers
And have that as for NMI
They're not secondary, you get a scratch register per entry point
One for interrupts, one for tlb refill, one for NMIs
see thankfully I'm not evalyn so I don't give a fuck about handling nmis or mces lol
🙏
Same
(she's gonna force me one day)

dont think you are being spared from this too

okay yeah you have MERRSAVE
see
which can be the exat same as SAVE1
the good thing about evalyn forcing me to do it
is that I can just beg her to implement it
You still aren't safe from the helping me debug it part
Only because you asked nicely
I don't use ai in my kernel tyvm
luna and claude sitting in a tree
you're so lucky this isn't osdev3
Thank you @hushed oracle and @urban mulch
I should be able to handle this properly on RV and LA64 now 
the perfect crime
(it will)
Il probably store a physical pointer in the machine error thing
Haven't had issues with it 
You're writing a microkernel so there is less surface for bugs 
Saving like 10 bytes btw 🥀🥀🥀
And an extra 8 for the GDT entry
the most premature of optimization
Think about it tho
With those extra 18 bytes
You can store a whole 1.7 page structs
Assuming your page struct is small as shit
I get 1/4th a page struct
Because I align them to a cache line
Bouta test now
Same

This computer is 1GB of RAM
For my kernel it’s like 24 bytes of data and the rest is padding lol
I’m certain I could shrink it as well
Mine is exactly 32 bytes
Aligning it for cache line purposes for locking it cleanly
dd
hmmm
The ISO supports both bios and UEFI boot
Most OSes do that
Seems like it's not even getting into limine
Could be an issue on my end
I think older hardware needs a custom limine without certain things?
I've seen this happen on older machines
With ISOs I give
You need to make your own ISO / USB with limine on it
same
windows page struct is an odd 48 bytes for some fuckin reason lmao
Idk if this is just my issue
Every ISO and image I’ve flashed has failed
A2 Oberon, EvalynOS (actually has the USB get detected, unlike others), Haiku, Windows XP Home, FreeDOS. All failed
I'm gonna try running it tomorrow, I got a better USB
inorder to properly compete with 16bit shrekOS evalynOS is now capable of printing out shrek
someone give evalyn 604849 upvotes!!!
(I'm taking a break today and I just shoved this into a PNG to ascii converter similar to the ralsei art on panic)
send to me shrek ascii art
idc
I wonder if I should post this on #showing-off

post it to reddit
with title
shrekos with fred
meoww
that has ze ascii art
have you tested it?
i'm at school, and I really wanna test it because if I'm unable to in the next 4 hours I'ma crash out
school in summer
Nope... school hasn't even ended yet 😭
Yeah we do
lucky
ended up getting heavily side tracked

i think? this is finished
for riscv exception handling
im probally gonna setup the riscv port soon
and add in that
and then work on the LA64 version

i will also have to work on cpu local and shit
but for RV i can just shim it enough 
since il only be on one hart
and it can use the static copy in the BSS for the BSP's cpu local
Didn't get anything with this new USB.
question
what happens if you manually install limine on it?
I'ma try that
and not use an ISO
Have you tried a different bootloader?
Da hell
The part in which you save and restore registers is so long lol
well there are 32 GPRs
and two of the temps i have to regrab from the cpu local when saving
the newer version only uses 2 temps vs 3 aswell
I don't get what's your obsession with overoptimizing ts
😭
1 more load or store ain't gonna make a difference
The one register being saved took like 4 seconds to be clear
I just had to move one thing somewhere else
To reuse another temp
And I'm stopping myself from more optimizations that have to do with instruction ordering
Think of the saved nano seconds tho

Ts ain't that code i used on an Arduino to have high speed bidirectional transfers via a parallel port 💔🥀
😭
Fair
In other news though
42 stars
The number of the life the universe and eveything
Debatable
we don't know, actually
Lame
Don't worry I ruined that for you
😭
if you were low IQ you wouldn't have been able to get a bachelor's in physics
I really hate to see it when you think low of yourself lukflug
You're right, I'm sorry
Lukflug deserves more love
its okay 
luvflug
gemini decided to straight up lie
lmao
oh, it mentions kvm in the third paragraph


I just need to wire in the exception handling shit I was working on the other day
And then work on CPU local some sched shit
Maybe some paging shit
But things are coming together
Oh and loongarch64 exception handling since they were both super similar besides slightly different CSR sementics
at least you are making more progress than I am with my own kernels
I just keep on rewriting and then getting tired of writing the gdt/idt/paging/mm/sched/lapic/hpet/acpi/other basic stuff a billion times (and not being able to decide what I actually want the kernel to be compatible with)
