im definitely not supporting aarch32 since that is absolutely wild
#uACPI - a portable and easy-to-integrate ACPI implementation
fiery turtle
and i686 seems useless as well
i might support compat mode for fun tho
for userspace
also maybe i should make a thread as to not pollute uacpi
which will also make me more embarrassed to abandon it
jaunty fox
which will also make me more embarrassed to abandon it
great idea
left orbit
it is kinda pointless to support non-64-bit x86 as a platform, since realistically anything nowadays supports 64-bit x86, even the shitty notebook CPUs
compatibility mode is kinda cool though, i think i've see only one (hobby) kernel support it
fiery turtle
I think pmos supports it
left orbit
yes yes exactly
fiery turtle
Dunno of other
left orbit
i couldn't recall the name lol
fiery turtle
great idea
Thanks for your support
frank canopy
yeah compat mode seems neat
frank canopy
also maybe i should make a thread as to not pollute uacpi
yeah probs
jaunty fox
it is kinda pointless to support non-64-bit x86 as a platform, since realistical...
but x86 is a legacy arch, don't you know, and next year everyone will run riscv
mortal yoke
yeah compat mode seems neat
on the other hand its nice as you can run old stuff but then there is also the non-nice thing about it which is that it allows new apps to be published as 32-bit binaries (which sucks because on eg. linux you need a ton of redundant 32-bit libraries along with 64-bit ones for eg. steam)
I'd much prefer if it was not a thing and instead if you want to run old apps you would use an emulator
slim panther
but x86 is a legacy arch, don't you know, and next year everyone will run riscv
sure bro
flat badge
My take on this is that 32 bit archs with <= 1gib of memory make some sense
flat badge
I mean, native 64bit support has its uses apart from pointers
Hm?
vast kestrel
Like, even if you have less than 1gb memory having native 64bit regs is still useful
hollow elm
i think the point is more that 32-bit targets with>1GB of ram make little sense to target
kind mantle
Because only a few of those targets will exist... When you get to that amount of RAM it makes no sense to limit yourself to 32-bit for any reason other than backwards compatibility... Which isn't exactly something x86 struggles with.
kind mantle
but x86 is a legacy arch, don't you know, and next year everyone will run riscv
As much as I'd love the idea, RISC-V isn't as mature and has not reached the levels of performance and efficiency necessary yet.
frank canopy
on the other hand its nice as you can run old stuff but then there is also the n...
i meant like neat technically. i agree with you on the general issues lol
kind mantle
FWIW this is why BadgerOS doesn't bother supporting 32-bit at all: If you're going to have an MMU in 2025, you might as well make it 64-bit.
frank canopy
i dont plan to support compat mode or 32-bit stuff on imaginarium either
lilac knoll
FWIW this is why BadgerOS doesn't bother supporting 32-bit at all: If you're goi...
on devices with low amount of ram, 64-bit is a fair bit of memory wasted from pointers
kind mantle
Yes
But consider also: MMUs are physically huge
Because they consist basically mostly out of a kind of cache called the TLB
Any chip that can afford an MMU by this definition will already be aiming for higher amounts of memory.
At least nowadays
lilac knoll
Because they consist basically mostly out of a kind of cache called the TLB
I mean you would size the TLB roughly.according to the amount of ram you have
kind mantle
You could
kind mantle
But you need to keep in mind that new chips being made get an MMU if they're made for running a modern OS, and don't get one if they're for microcontrollers
lilac knoll
there's a middle ground between microcontrollers and full desktop/server capable hardware
kind mantle
Nobody (relevant) is making chips with an MMU that don't have at least a GiB of RAM because an MMU only adds value if you want to run a paging operating system on it, which, in turn, is only useful if you can't properly or cleanly achieve your goal without such an operating system.
And while Linux lets you run with shockingly small amounts of RAM, relatively few such configurations are actually used that do have an MMU.
lilac knoll
well that's just not true 😉
jaunty fox
Nobody (relevant) is making chips with an MMU that don't have at least a GiB of ...
i can immediately name one this is untrue of
retrobsd (2.11bsd which has paged vm) was ported to several such microcontrollers, one of which something in the microchip pic32 series
lilac knoll
Nobody (relevant) is making chips with an MMU that don't have at least a GiB of ...
smart watches for example typically have 500mb-2gb ram or so and invariably run full blown operating systems, sometimes in 32-bit
kind mantle
smart watches for example typically have 500mb-2gb ram or so and invariably run ...
Yeah but microcontrollers with 512KiB of RAM are never gonna have page-based virtual memory
Wait WTF no I'm wrong
But how does a PIC32 with 512KiB of RAM need an MMU?
Granted it's not a big TLB
lilac knoll
Yeah but microcontrollers with 512KiB of RAM are never gonna have page-based vir...
was that in reply.to me
kind mantle
Both
And then I found a PIC32 with page-based virtual memory
Though it doesn't seem to be entirely a normal TLB from how I read the datasheet?
jaunty fox
Though it doesn't seem to be entirely a normal TLB from how I read the datasheet...
they're mips, it'll be software refileld
jaunty fox
no catch, it's a legitimate and peaceful approach
lilac knoll
half a GiB is still in the ballpark though
in what ballpark?
my point was that it's a device where you have virtual memory and low ram, so 32-bit ptrs are desireable
jaunty fox
motorola coldfire also doing this
kind mantle
Well it is a catch for a TLB with merely 16 entries. You're not getting away with a lot of fragmented virtual memory regions like Linux would make eventually if your TLB has 16 entries.
Not that Linux runs on 512KiB in the first place
kind mantle
in what ballpark?
my point was that it's a device where you have virtual memory...
Ngl I keep forgetting about the existance of smart watches and all those stupid smart home devices because I just hate them
lilac knoll
yeah fair
jaunty fox
by comparison the 486 had 32 tlb entries
lilac knoll
honestly
jaunty fox
it's certainly a squeeze
kind mantle
Why does my lamp need to connect to a network cmon
kind mantle
by comparison the 486 had 32 tlb entries
Yes but that has hardware refill
I guess hobby os for smartwatch confirmed? 
hollow elm
i mean with mips parts of the va space don't go through the tlb
kseg0/1 are just directly mapped to phys mem
free hhdm
kind mantle
I like how this STM32 datasheet says "fuck it" and marks the entire low 2GiB as reserved in the virtual memory map
Every day I learn more how cursed computers are
Anyway I'm off to speedrun Celeste now
hollow elm
they're mips, it'll be software refileld
also TIL pic32 is mips, i thought it was a custom arch
kind mantle
I thought it was ARM for some reason
jaunty fox
also TIL pic32 is mips, i thought it was a custom arch
i wouldn't have known but for retrobsd making the news a while ago
calm latch
it is kinda pointless to support non-64-bit x86 as a platform, since realistical...
but it's not hard to support?
slim panther
still pointless
calm latch
and there is a factor of it being cool and getting to run your os on old hardware
and being a sanity check for 64 bit code
left orbit
32 bit kernels should be banned by the eu
slim panther
i'm 22
calm latch
i'm 23
slim panther
i had my first pc at 9 yo
calm latch
i think me too
slim panther
and that was an amd bulldozer
left orbit
i think the earliest machine i had was a c2d one
calm latch
32 bit kernels should be banned by the eu
if it's the only arch
calm latch
compatibility mode is kinda cool though, i think i've see only one (hobby) kerne...
why does nobody support it?
like it's just a 32 bit code segment in GDT, and a couple of if statements to limit virtual memory to 4GB and to get syscall arguments differently
fiery turtle
probably because it's difficult to propagate the 4gb limit everywhere
calm latch
how so?
left orbit
also probably because not many people want it
compat mode is pretty useless unless you want to run wine
calm latch
it was convenient when I was porting my kernel to 32 bit mode
but I guess nobody does it in that order?
frank canopy
tbh i think most people just dont support 32 bit kernel mode
moreso than not doing it in that order
keen shard
tbh i think most people just dont support 32 bit kernel mode
Me when my kernel is only 32 bit 
frank canopy
i did say most not all lol
frank canopy
mood
dense steppe
qemu log and printk log or it didn't happen
trim frost
[00:00:00.05977] [ info ] uacpi: FACS 0x000000007FBDD000 00000040
EXCEPTION: PAGE FAULT
Accessed Address: 0x7FB7B000
Error Code: PageFaultErrorCode(0x0)
InterruptStackFrame {
instruction_pointer: VirtAddr(
0xffffffff800d858c,
),
code_segment: SegmentSelector {
index: 1,
rpl: Ring0,
},
cpu_flags: RFlags(
RESUME_FLAG | INTERRUPT_FLAG | PARITY_FLAG | 0x2,
),
stack_pointer: VirtAddr(
0xffff80007e8c9790,
),
stack_segment: SegmentSelector {
index: 2,
rpl: Ring0,
},
}
.=- -*+-
**+=-: :+++=.
:++**+ .=++= :+***.
:*+++*++:+***= .:::++*+-===-. -++- -++++:
++***+++**= .=**++#%#%%#*+*%%#*-. +***- :=****:
.+*+++****: :*%%*==++#%%%*++++*#%%#+. -**+-*+++***
:*++*++**: .*%%*=+***##########*+#%%%%= -*++***++**-
-****+++ :#%#%##%%*=--::::-=+#%%%%%#%%* -++******+:
-+***= .#%#%%%%#-::::::::::::=#%%%%%#%* -****+:
... *%#%%#%*:::::::::::::::-#%%%%%#%- ..
#%%%%%*::::.:::::::.::::-%%%%%#%+
#%%%%#-:::::........:::::+%%%%#%+
*%#%%=::::..:=++*+-:.:::::*%#%#%-
:%###-::::-*#%%%%%%#+:::::=%%#%#
=##+:::-*%%%######%%#=::::####.
:#*--=#%%#%%%%%%%%#%%+-:-##+.
=%%#####%%%%%%%%%%##%###%%
.::+#%%%%%%%%%%%%%%#*=--:
.:=+*##%%%##*+=:
~~~~~~~~~~~~~~~~~~~~~~~~~ Kernel Panic ~~~~~~~~~~~~~~~~~~~~~~~~~
~
~ ERROR: panicked at src/arch/interrupts.rs:96:5 with message: page faulted
~
~ frame 0: rip = 0xffffffff800fba5f
~ frame 1: rip = 0xffffffff800118ca
~ frame 2: rip = 0x7fb7b000
~ frame 3: rip = 0xffffffff800d85d1
~ frame 4: rip = 0xffffffff800d8949
~ frame 5: rip = 0xffffffff800d9561
~ frame 6: rip = 0xffffffff800d93fd
~ frame 7: rip = 0xffffffff800d9677
~ frame 8: rip = 0xffffffff800d97a1
~ frame 9: rip = 0xffffffff800dd031
~ frame 10: rip = 0xffffffff8004161a
~ frame 11: rip = 0xffffffff80017d14
~ frame 12: rip = 0x0
~ stopping code execution and dumping registers
~
~ r15: 0x0000000000000000 - rsi: 0x000000000000001B
~ r14: 0x0000000000000000 - rdx: 0xFFFFFFFF80116648
~ r13: 0x0000000000000000 - rcx: 0xFFFF80007E8C8C58
~ r12: 0x0000000000000000 - rbx: 0x0000000000000000
~ r11: 0xFFFFFFFF800045CA - rax: 0xFFFF80007E8C8F78
~ r10: 0xFFFFFFFF80116648 - rip: 0xFFFFFFFF800045CA
~ r9: 0x000000000000001B - cs: 0x0000000000000008
~ r8: 0xFFFFFFFF80116648 - rflags: 0x0000000000000096
~ rbp: 0xFFFF80007E8C8C58 - rsp: 0xFFFF80007E8C8B28
~ rdi: 0xFFFF80007E8C8F78 - ss: 0x0000000000000010
~ cr2: 0x000000007FB7B000 - cr3: 0x000000007FF3E000
~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damn your kernel panic is very cool looking
trim frost
Damn your kernel panic is very cool looking
thx, i wish it solved the problem though
fiery turtle
info mem in qemu
trim frost
`info mem` in qemu
fiery turtle
so no its not mapped
trim frost
but then uacpi is not mapping it
fiery turtle
do u think its a qemu bug
fiery turtle
do u think its a uacpi bug
trim frost
no
fiery turtle
i would first add a tracing function that prints everything uacpi tries to map and what you return to it
trim frost
this is without if i dont do anything in uacpi_kernel_map
so it is mapping things
just not everything
fiery turtle
yes, see my message above
trim frost
after (temporarily) changing the pagesize to 2mb instead of 4kb now the code hangs at uacpi_namespace_initialize()
and i get these errors because i left pci as unimplemented
fiery turtle
u can set the log level to debug if u wanna see where it hangs
trim frost
how? in uacpi_initialize()?
fiery turtle
uacpi_context_set_log_level
trim frost
i dont think uacpi-rs bindings have that lol
fiery turtle
you're probably using a very old version of uacpi as well
are u using the rewrite branch?
fiery turtle
maybe it still using the old version where uacpi_initialize takes in a log level
fiery turtle
then it should have that function
at least in C
maybe its not exposed to rust
only @rustic compass knows
or just use addr2line or whatever
trim frost
in which file is that function? maybe its not included in the bindgen sources
fiery turtle
context.h
fiery turtle
alternatively u can change the default log level in sources
i think config.h has it
trim frost
yeah this is available - uacpi_set_resources
fiery turtle
what
trim frost
nvm
fiery turtle
trim frost
does debug log every single instruction?
fiery turtle
every aml op
fiery turtle
depends on how fast your logger is
fiery turtle
the last thing it logged
trim frost
[00:00:44.87663] [ dbug ] uacpi: trying to acquire the global lock from firmware... (attempt 1)
[00:00:44.87853] [ dbug ] uacpi: global lock is owned by firmware, waiting for a release notification...
spinlock?
fiery turtle
ah ok its a bug in your kernel api
either spinlock api, or mutex api, or get_thread_id
trim frost
all of those are set to 1 haha
fiery turtle
set to 1?
trim frost
fiery turtle
i dont see a get_thread_id in there
fiery turtle
its not in the file u posted
trim frost
bruh i didnt copy the entire thing
fiery turtle
yeah nvm
its because u return 1 for all mutexes
handles collide
anyway just implement it properly
or at least return an incrementing number each time
torpid root
lol
trim frost
ok that will probably fix the hang but am i supposed to always use 2mb page sizes in the mapping?
4kb pagefaults
fiery turtle
no, your page mapper is just bugged
like i said trace everything uacpi asks to map and the address you return, then compare with the resulting info mem
trim frost
fixed the mapper
fiery turtle
What was the issue?
trim frost
nothing anymore, thanks
fiery turtle
Lol np
torpid root
dumass forgot a loop and was mapping a single page
fiery turtle
Lmfao
trim frost
how good is 2408331 ops/s
torpid root
how good is 2408331 ops/s
trim frost
so im getting better results than people that have a better cpu than me
calm latch
which CPU do you have?
trim frost
i5 12400f
calm latch
it's not that slow...
trim frost
never said it was,
fiery turtle
how good is 2408331 ops/s
Its pretty decent
trim frost
2681214/s now
weirdly enough setting the opt-level to anything other than z or s on release profile makes the os bootloop
tired temple
how good is 2408331 ops/s
Something like 12cm. 
slim panther
weirdly enough setting the opt-level to anything other than z or s on release pr...
works for me on opt level 3
kind mantle
Optimizes your os out
FPGA MFs when they forget to add outputs to their design
trim frost
what does it mean if im getting UACPI_STATUS_INIT_LEVEL_MISMATCH from this?
nvm i figured it out
i was initing hpet before uacpi
left orbit
can't wait for the ultra kernel progress thread
fiery turtle
when theres at least something to show lol
kind mantle
when theres at least something to show lol
do it now
Many threads, including BadgerOS', start as basically nothing
left orbit
fiery turtle
i will make one soon
zinc roost
dense steppe
when theres at least something to show lol
I would recommend setting an explicit goal, as in "progress report thread when XYZ thing is accomplished" (e.g. userspace)
fiery turtle
When I make a good log ring
vast kestrel
I would recommend setting an explicit goal, as in "progress report thread when X...
me when I always rewrite before reaching the goal I set to myself for creating a thread 
dense steppe
the double fault is caused by some "normal" fault handler (e.g. GP or PF) not being installed.
aka give QEMU log
fiery turtle
rip is uACPI/source/opregion.c:568
What's at that line?
trim frost
dense steppe
the double fault is caused by some "normal" fault handler (e.g. GP or PF) not be...
or not being installed correctly, or something being wrong with the stack
trim frost
its not a GP or PF, both are installed correctly and work
fiery turtle
Then its probably a push to a bogus rsp or something
dense steppe
gib qemu log !!
sharp lichen
Holy sgit alnost 50k messages, this project is big as heck
dense steppe
qemu log or it didn't happen
dense steppe
Holy sgit alnost 50k messages, this project is big as heck
yes but also no, this is just lounge-2
fiery turtle
By that measure nyaux is a bigger project
vast kestrel
enable qemu interrupt logging and check exactly what exception is being thrown before the double fault
maybe your stack is too small and it can't push the exception?
trim frost
enable qemu interrupt logging and check exactly what exception is being thrown b...
that doesnt work with kvm
and without kvm the double fault doesnt happen
fiery turtle
Use bochs
vast kestrel
try to give all the exceptions a specialized stack
trim frost
hmm ive increased the stack size to 8kb and no more double fault
vast kestrel
I would put a stack guard, so you can ensure you never run out of stack accidently
trim frost
im gonna set it to 16kb to be safe
vast kestrel
I think linux pushed it to 32k as more rust code enters the kernel
fiery turtle
If your entire kernel is rust maybe consider 64 or even 128
torpid root
If your entire kernel is rust maybe consider 64 or even 128
unrelated to the current conversation but my issue with fixed events causing a page fault was due to my shitty implementation of std::function
trim frost
now pf here, what could this be caused by?
fiery turtle
unrelated to the current conversation but my issue with fixed events causing a p...
Lol
fiery turtle
now pf here, what could this be caused by?
Bad mapper or any other corruption
torpid root
also I don't think this is how time works
trim frost
now pf here, what could this be caused by?
THIS IS SO WEIRD
fiery turtle
also I don't think this is how time works
Seems to increase monotonically, ship it
vast kestrel
man, it sounds like there is something really wrong with your code lol
trim frost
64kb works
vast kestrel
for your own good, put a guard page for your stack and check if that is actually related
vast kestrel
maybe your allocator is cooked
vast kestrel
maybe its your page allocator
trim frost
that part might actually be cooked
vast kestrel
and again, stack guards are a life saver when it comes to these stuff
torpid root
Seems to increase monotonically, ship it
it adds extra 5 seconds every 5 seconds
frank canopy
is there any sort of alignment guarantee on uacpi_resource?
frank canopy
anyway imaginarium and zuacpi now can do all resource types that showed up in qemu. will finish and polish this bit up and then push in a few days
fiery turtle
is there any sort of alignment guarantee on `uacpi_resource`?
Yeah
fiery turtle
<:nooo:750466870993223750> <:nooo:750466870993223750>
hows your os going btw
slim panther
:(
fiery turtle
wdym
left orbit
thats why i started working on stuff in managarm
slim panther
depressing
left orbit
i am incapable of creating a project and working on it for extended periods of time
slim panther
you are a great help to me tho
left orbit
yep
fiery turtle
you are a great help to me tho
same
slim panther
at this point, any second set of eyes is a win in my book
so i don't produce utter garbage code
left orbit
it’s easier when working on someone else’s code, you don’t have to think about the entire codebase usually
slim panther
merge yours with mine :)
left orbit
doesn’t work, mine isn’t written in rust
and i don’t really have a vision for mine but i don’t want to introduce a bunch on shit code lol
i don’t really know what i’m doing is the problem
slim panther
pretends that i do
i have 0 clue past the surface level
i'm just making shit up as i encounter it
left orbit
same, but so far it has worked for you, unlike me :^)
slim panther
luck
left orbit
fiery turtle
<:doubt:1158157054117159012>
Impostor syndrome
fiery turtle
you just need to be willing to read linux sources and other crap for hours
at least thats what i do
slim panther
i despise doing that
how do you make an abstraction layer this annoying to work with
fiery turtle
im kinda used to it, at this point its relatively easy to navigate
fiery turtle
yes i kinda hate it as well lol
calm latch
doesn’t work, mine isn’t written in rust
mine isn't either
left orbit
yeah but now i don't have anything that would be worth contributing to your kernel
- you use gitlab, ew
frank canopy
yeah I was just trying to figure out what the alignment was lol
cause otherwise im having to aligncast
fiery turtle
uacpi tries to be sane where possible
frank canopy
my zig code was using align(1) aka c packed just to be as general as possible until I figured it out lol
fiery turtle
lol
frank canopy
also zig packed is completely different and I keep having to remind myself that c packed isn't the same when talking with c people lol
fiery turtle
yeah GCC packed means remove padding AND assume misaligned
left orbit
and zig packed means bit packed
frank canopy
yup
anyway i can remove a bunch of code in one spot and change a 1 to a @alignOf(usize) in another now and have zuacpi still work at least which is nice
love removing code
trim frost
can you guys test my kernel on a high end cpu? i wanna see how much points it can get, most i could get was 3.3m on my i5 12400f
RUST_PROFILE="smol" make run (this has the most optimization)
trim frost
without ovmfs its slower
zinc roost
doesnt compile for me
trim frost
why?
zinc roost
Updating crates.io index
error: failed to get `flanterm-sys` as a dependency of package `chronos v0.1.0 (/home/cat/prob/chronos/kernel)`
Caused by:
failed to load source for dependency `flanterm-sys`
Caused by:
Unable to update /home/cat/prob/chronos/bindings/flanterm-sys
Caused by:
failed to read `/home/cat/prob/chronos/bindings/flanterm-sys/Cargo.toml`
Caused by:
No such file or directory (os error 2)
make[1]: *** [GNUmakefile:30: all] Error 101
make[1]: Leaving directory '/home/cat/prob/chronos/kernel'
make: *** [GNUmakefile:70: kernel] Error 2
did you clone it recursively?
zinc roost
oh
trim frost
also you will get pci unimplemented errors which cover the screen so you will have to check the terminal debugcon prints for the points
i implemented pci now but haven't pushed it yet
zinc roost
rust-lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
warning: `chronos` (bin "chronos") generated 1 warning
error: could not compile `chronos` (bin "chronos") due to 1 previous error; 1 warning emitted
can you show rust-lld errors?
zinc roost
trim frost
hm thats wewird
are you using nightly rust?
that shouldnt matter for linking but
jic
zinc roost
i just ran make run, and it asked me to add nightly so i did
trim frost
what distro are you using?
zinc roost
fedora
trim frost
im not sure why this is happening...
@torpid root can u test it?
left orbit
i like how u start pinging random people to test it for you while i offered to test it for you, you still haven't provided the image and a command line
zinc roost
yeah that is much easier
trim frost
i like how u start pinging random people to test it for you while i offered to t...
he's not random, I know him and he runs fedora
i'll provide the iso and commandline in a sec
left orbit
well, yeah, random as in out of nowhere
that's what i seemed like from my point of view
trim frost
qemu-system-x86_64 -M q35 -cpu host -debugcon stdio -boot order=d,menu=on,splash-time=0 -cdrom chronos-x86_64.iso -enable-kvm -m 2G
trim frost
drop the iso instead
^
torpid root
you don't compile your dependencies with the same code model as your kernel
add -mcmodel=kernel
trim frost
i fixed it btw, you can clone again
flat badge
and i don’t really have a vision for mine but i don’t want to introduce a bunch ...
hel syscall compat kernel 
No that's not a good idea lol
left orbit
`qemu-system-x86_64 -M q35 -cpu host -debugcon stdio -boot order=d,menu=on,splas...
[iretq@raptor ~]$ qemu-system-x86_64 -M q35 -cpu host -debugcon stdio -boot order=d,menu=on,splash-time=0 -cdrom chronos-x86_64.iso -enable-kvm -m 2G | grep -a '\(avg'
[00:00:00.00428] [ info ] uacpi: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 3837030/s)
[00:00:00.00364] [ info ] uacpi: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 3837160/s)
[00:00:00.00299] [ info ] uacpi: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 3864224/s)
[00:00:00.00323] [ info ] uacpi: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 3421413/s)
[00:00:00.00305] [ info ] uacpi: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 3519520/s)
[00:00:00.00307] [ info ] uacpi: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 3814513/s)
[00:00:00.00338] [ info ] uacpi: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 3823307/s)```13700K
trim frost
```
[iretq@raptor ~]$ qemu-system-x86_64 -M q35 -cpu host -debugcon stdio -boot ...
nice
thanks
fiery turtle
```
[iretq@raptor ~]$ qemu-system-x86_64 -M q35 -cpu host -debugcon stdio -boot ...
didnt you have a python auto-launcher
left orbit
idk lmao
maybe
i do vividly remember making something like that
yeahhh right, we were debating on how to make it get the most cpu time possible
fiery turtle
yeah
trim frost
i define this function in rust the same way as the kernel api functions
what am i doing wrong?
fiery turtle
how is C supposed to know what chronos_memcpy is
trim frost
how does it know with kernel api functions?
fiery turtle
it includes the header where they are declared
also just call this function memcpy and it will be picked up by uacpi automatically
because it uses __builtin_memcpy
mortal yoke
and you also get memcpy from rust compiler builtins so you likely don't need to make one
slim panther
use bindgen;
use cc;
fn main() {
let mut b = cc::Build::new();
b.files([
"uacpi/source/default_handlers.c",
"uacpi/source/event.c",
"uacpi/source/interpreter.c",
"uacpi/source/io.c",
"uacpi/source/mutex.c",
"uacpi/source/namespace.c",
"uacpi/source/notify.c",
"uacpi/source/opcodes.c",
"uacpi/source/opregion.c",
"uacpi/source/osi.c",
"uacpi/source/registers.c",
"uacpi/source/resources.c",
"uacpi/source/shareable.c",
"uacpi/source/stdlib.c",
"uacpi/source/tables.c",
"uacpi/source/types.c",
"uacpi/source/uacpi.c",
"uacpi/source/utilities.c",
])
.includes(["src/"])
.includes(["uacpi/include/"])
.define("UACPI_SIZED_FREES", None)
.define("UACPI_OVERRIDE_LIBC", None)
.pic(true)
.flag("-ffreestanding")
.flag("-nostdlib");
if std::env::var("CARGO_CFG_TARGET_ARCH").unwrap() == "x86_64" {
b.flag("-mgeneral-regs-only");
b.flag("-mno-red-zone");
}
b.compile("uacpi");
let bindings = bindgen::builder()
.use_core()
.wrap_unsafe_ops(true)
.derive_default(true)
.derive_debug(true)
.header("src/wrapper.h")
.clang_arg("-Iuacpi/include/")
.generate()
.expect("Unable to generate bindings!");
let out_path = std::path::PathBuf::from(std::env::var("OUT_DIR").unwrap());
bindings
.write_to_file(out_path.join("bindings.rs"))
.expect("Unable to write bindings!");
}
this is my bindgen
fiery turtle
do you really need sized frees with rust?
fiery turtle
hm ok
trim frost
```rs
use bindgen;
use cc;
fn main() {
let mut b = cc::Build::new();
b....
and what do you do with the UACPI_OVERRIDE_LIBC
slim panther
slim panther
bruh
trim frost
and where is that file?
slim panther
make it yourself, but infy said it's redundant
fiery turtle
#ifndef __smp_store_release
#define __smp_store_release(p, v) \
do { \
compiletime_assert_atomic_type(*p); \
__smp_mb(); \
WRITE_ONCE(*p, v); \
} while (0)
#endif
#ifndef __smp_load_acquire
#define __smp_load_acquire(p) \
({ \
__unqual_scalar_typeof(*p) ___p1 = READ_ONCE(*p); \
compiletime_assert_atomic_type(*p); \
__smp_mb(); \
(typeof(*p))___p1; \
})
#endif
@flat badge any idea why linux uses a full barrier for both of these instead of smp_rb() for one and smp_wb() for another?
i looked at the commit that introduced this but no one asked this question
trim frost
it will automatically call these already
so what should the default name be? just memcpy or uacpi_memcpy
trim frost
oh
rustic compass
```rs
use bindgen;
use cc;
fn main() {
let mut b = cc::Build::new();
b....
i might steal this
slim panther
trim frost
mine is better
flat badge
```c
#ifndef __smp_store_release
#define __smp_store_release(p, v) ...
i guess this is a generic impl that is overriden by archs?
fiery turtle
yes
flat badge
yeah on x86 it compiles to a compiler barrier
flat badge
ah the question was not why is it not a acquire/release barrier but why is it not smp_rmb / smp_wmb
fiery turtle
yea
fiery turtle
i dont think they even have that
flat badge
that's why they use the strong full memory barrier ;D
fiery turtle
so in linux terms smp_rb means no reads can be reordered with this read?
but not writes
flat badge
but compare for example on RISC-V where linux lowers smp_rmb() to RISCV_FENCE(r, r)
but acquire to RISCV_FENCE(r, rw)
fiery turtle
so the C model is stricter, it doesnt even have a way to express an smp_rb or smp_wb
flat badge
a read-read barrier is not strong enough because that'd make it possible to reorder
mutex.acquire()
x = 42
mutex.release()
to
x = 42
mutex.acquire()
mutex.release()
yeah makes sense, so with smp_rb, stores can be reordered in any way
fiery turtle
a read-read barrier is not strong enough because that'd make it possible to reor...
so with stdatomic you could really only express smp_rb_readwrite(), not smp_rb{_read} like linux
flat badge
the C model is different not finer/coarser
fiery turtle
seems coarser to me
flat badge
a read-rw barrier is not equivalent to acquire either
fiery turtle
you just cant express this
flat badge
read-rw is stronger than acquire
fiery turtle
why?
flat badge
because acquire only synchronizes with release barriers on other CPUs
and not with random relaxed accesses
fiery turtle
well if we talk about a std::atomic_thread_fence
with ACQUIRE
it would mean the same
flat badge
no
fiery turtle
how
fiery turtle
i dont understand the difference
flat badge
the Linux model is phrased in terms of what accesses before a barrier can be reordered with what accesses after a barrier
fiery turtle
right
flat badge
the C11 model is phrased in terms of when one access on one CPU happens before another access on a different CPU
fiery turtle
same thing just a different angle?
happens-before/sequenced-before is just lawyer speak for the exact same thing if i understand this correctly
doesnt this basically say they can't be reordered just using a more abstract/formal language?
fiery turtle
the C11 model is phrased in terms of when one access on one CPU happens before a...
btw im also watching a talk by Paolo Bonzini and he had this
flat badge
okay, i think you're right that in the case of fences, r-rw is equivalent to acquire
and rw-w is equivalent to release
fiery turtle
btw im also watching a talk by Paolo Bonzini and he had this
I read this probably 100 times
and still dont understand what this is trying to say
flat badge
but there is no way to emulate r-rw with smp_rmb() and smp_wmb()
fiery turtle
yeah, u must use smp_mb
fiery turtle
and rw-w is equivalent to release
why rw-w and not w-rw?
flat badge
otherwise you can again come up with a silly mutex example
otherwise
mutex.acquire()
*x
mutex.release()
can be reordered to
mutex.acquire()
mutex.release()
*x
wait what do u encode in the order of these letters exactly
flat badge
rw-w = no read/write before the barrier can be reordered with a write after the barrier
fiery turtle
okay and r-rw means no read/write after the barrier can be reordered with this read?
flat badge
r-rw = no read before the barrier can be reordered with a read/write after the barrier
fiery turtle
because this sounds kind of inverse from what you're saying
flat badge
that's exactly what i'm saying?
except that i'm talking about linux style barriers while that paragraph talks about acq/rel load/store
fiery turtle
nvm ill have to re-read this probably 50 times to parse it completely
fiery turtle
btw im also watching a talk by Paolo Bonzini and he had this
did u understand this part?
jaunty fox
btw im also watching a talk by Paolo Bonzini and he had this
bonzini based
flat badge
yes, what is your question here?
jaunty fox
i knew him from the smalltalk community long before i encountered him elsewhere
fiery turtle
bonzini based
he is, still one the most active qemu maintainers
fiery turtle
btw im also watching a talk by Paolo Bonzini and he had this
i think its trying to say that code before release cannot be reoredered with code after acquire or whatever
flat badge
it means that if
thread 1:
x.store(42)
thread 2:
x.load()
and thread 2 loads the 42 written by thread 1, then everything that was ordered before the store in thread 1 is also visible to thread 2 after the load
fiery turtle
yeah makes sense when you put it like that
https://www.youtube.com/watch?v=NE73iPMpzj4 its this by the way
pretty good talk
trim frost
when does uacpi_kernel_uninstall_interrupt_handler get called?
fiery turtle
uacpi_state_reset
fiery turtle
@flat badge in this example, why is acquire_release on the load()'s not enough? Wouldnt it guarantee that stores before cant be reordered after this one
or is the idea that there isnt a synchronization point between them
like this makes no sense, because surely if x was a normal variable then it would be guaranteed to be false after an acq_rel load, no?
like its this sentence i dont understand
if this was the case, then
// t1
foo.store(123, relaxed);
bar.store(321, release);
// t2
bar.load(acquire);
assert(foo.load(relaxed) == 123); // can fail beacause not seq_cst??
why wouldn't bar's release be enough here
fiery turtle
rw-w = no read/write before the barrier can be reordered with a write after the ...
actually if this is true then they arent equivalent
because the c++ page simply says "no reads or writes in the current thread can be reordered before this load", it doesnt say anything about reordering with a write specifically
fiery turtle
<@358943271151468555> in this example, why is acquire_release on the load()'s no...
or e.g. why a thread_fence(ACQ_REL) wouldnt be enough between each load and store, they could even be relaxed
gentle peak
if this was the case, then
```cpp
// t1
foo.store(123, relaxed);
bar.store(321, ...
iirc the happens-before relation that acq rel creates only applies to non atomic vars
foo is atomic, so its store doesn't happen before bar's
fiery turtle
hm so my example can literally fail?
gentle peak
yeah
fiery turtle
lol
fiery turtle
iirc the happens-before relation that acq rel creates only applies to non atomic...
if this is the answer then i understand why u need seq_cst, but i hope its not true
gentle peak
it also means that mutex acquires need to be acq rel instead of just acq since otherwise lock(a); lock(b); can be observed as lock(b); lock(a); on other threads
flat badge
if this was the case, then
```cpp
// t1
foo.store(123, relaxed);
bar.store(321, ...
this can't fail
fiery turtle
I guess monkuous is wrong then
flat badge
<@358943271151468555> in this example, why is acquire_release on the load()'s no...
but in this snippet there is no such synchronization
thread 2 doesn't load acquire any value written by thread 1 (or vice versa)
that's why you need seq_cst
fiery turtle
yeah but what if i add an acq_rel barrier in the middle for example
flat badge
x.store()
fence(acq_rel) <--- does nothing here
y.load()
acquire prevents reordering earlier loads
fiery turtle
the store cannot be reordered after the fence
flat badge
there is no earlier load
fiery turtle
the load cannot be reordered before
flat badge
release prevents reordering future stores
and there is also no future store
so acq_rel does nothing here
fiery turtle
well the docs dont say that
no reads or writes in the current thread can be reordered before this load
and no reads or writes in the current thread can be reordered after this store
it mentions both
flat badge
by "this load" this summary means "an earlier load" (or the in the case of a load-acquire instead of a fence, the load done by the load-acquire)
fiery turtle
A load operation with this memory order performs the acquire operation on the affected memory location: no reads or writes in the current thread can be reordered before this load.
this is the entire text
pretty sure this load means the load itself
flat badge
there is no load acquire here
fiery turtle
for acq_rel it says No memory reads or writes in the current thread can be reordered before the load, nor after the store.
flat badge
acq_rel is equivalent to acquire + release
fiery turtle
rw-w = no read/write before the barrier can be reordered with a write after the ...
but this is still different from what the cppref page says, no?
yours seems lighter as it allows reads to be reordered with reads
flat badge
if you make it
T1:
x.store(false, release)
a = y.load(acquire)
T2:
y.store(false, release)
b = x.load(acquire)
you can still get a = true, b = true
there is simply no synchronization at all here
fiery turtle
i agree with this one, since the store is before the acquire
acquire means nothing below can be reordered above
flat badge
and
T1:
x.store(false)
fence(acq_rel)
a = y.load()
T2:
y.store(false)
fence(acq_rel)
b = x.load()
is equivalent to the above
fiery turtle
are these relaxed?
fiery turtle
is equivalent to the above
so what you're saying is that the fence is a no-op for some reason
but why
would it also be a no-op if load and store were in a different order?
fiery turtle
ok i see what u were going for
flat badge
well, if you change the order in one of the two threads
fiery turtle
but this is still different from what the cppref page says, no?
what about this tho?
i think your definition is lighter still
what you're saying is
foo.load(acquire);
print(x); // may be reordered above the load
if i understood you correctly
but cppref seems to disagree
fiery turtle
but cppref seems to disagree
linux docs agree with cppref
gentle peak
release prevents reordering _future stores_
isn't it the other way around? acq prevents reordering future loads to before the acq, rel prevents reordering past stores to after the rel
fiery turtle
it is, but it's both loads and stores
i think what you're describing is the equivalent of smp_{rb,wb} which are not acquire/release
gentle peak
I'm pretty sure the cppref summary is incorrect here and the formal model doesn't care about stores wrt acq and loads wrt rel
flat badge
no
what makes you think that I stated that?
that is not the situation of the snippet that you posted above
where the load is after the store, not before the store
flat badge
I'm pretty sure the cppref summary is incorrect here and the formal model doesn'...
yes it does
otherwise stuff could be moved out of a mutex
fiery turtle
what makes you think that I stated that?
r-rw = no read before the barrier can be reordered with a read/write after the barrier
wait wrong one
rw-w = no read/write before the barrier can be reordered with a write after the barrier
this implies a read inside the barrier can be reordered with anything
flat badge
r-rw (i.e. acquire) prevents #1217009725711847465 message
fiery turtle
then it implies that stuff inside the barrier can be reordered with a read after
flat badge
the load before the barrier (foo.load) cannot be reordered with anything (the print) after the barrier
fiery turtle
which doesnt make sense
flat badge
are you aware that if you want to replace load-acquire with a fence, the fence has to be after the load?
fiery turtle
what you said is "reads/writes before the barrier can be reoredered with reads after the barrier"
flat badge
and likewise if you replace store-release with a fence, the fence has to be before the store?
fiery turtle
are you aware that if you want to replace load-acquire with a fence, the fence h...
well yeah
that i understand
flat badge
if you write this #1217009725711847465 message in terms of fences, it is
foo.load(relaxed);
fence(acquire)
print(x);
and the r-rw fence prevents reordering
fiery turtle
yeah, so it cant be reordered
fiery turtle
ok so r-rw = no read before the barrier can be reordered with a read/write after the barrier AKA for the acquire barrier, you said that writes before the barrier can be reordered with anything after the barrier
correct?
flat badge
yes
fiery turtle
nvm
flat badge
there is no write before the barrier here
flat badge
the semantics are literally what i wrote though lol
No, i meant literally what i wrote
and not anything else
fiery turtle
then your semantics are actually stricter
because cppref doesnt mention anything about the operations before the barrier
it only mentions that operations after cant be reordered
flat badge
that doesn't make any sense
ordering is always before barrier vs. after barrier
you can't say something about the ordering on one side only
fiery turtle
what
flat badge
and cppref also says something about both sides
fiery turtle
it says stuff after cannot be ordered before
flat badge
what does "before" mean?
fiery turtle
it doesnt mention what can happen to operations before the barrier
because its not relevant for the acquire barrier i guess
flat badge
there is no such thing as a "nothing-r" or "nothing-rw" or "nothing-w" barrier
because it would be a no-op
fiery turtle
well thats not true
operations before the acquire barrier can happen after the barrier
the only limitation is operations after barrier must appear to happen after the barrier
fiery turtle
stuff before the barrier is not synchronized in any way tho, why is it important to define it
flat badge
(1) that's not how it works in the C11 model and (2) that wouldn't make any sense
fiery turtle
thats literally how its spelled out A load operation with this memory order performs the acquire operation on the affected memory location: no reads or writes in the current thread can be reordered before this load.
mentions absolutely nothing about before the barrier operations
flat badge
can be reordered before this load
that's "before"
if you leave out this sentence, the CPU can delay the barrier indefinitely
fiery turtle
yes, but its talking about the operations after the barrier
flat badge
yes, but its talking about the operations after the barrier
No!
fiery turtle
ok, why?
flat badge
~~until the heat death of the universe~~
actually that's not true, it could take the barrier immediately upon program start
it could move it into the past, not into the future
then everything after the barrier stays after the barrier and there are no memory accesses at all before the barrier
fiery turtle
they're there, we just dont talk about them
flat badge
the "until the heat death of the universe" scenario applies to barriers with empty "after" side
Barriers where one side is empty are meaningless in any case
gentle peak
ok, why?
fences aren't loads or stores, they effectively raise the ordering of other loads or stores (depending on the order of the fence)
fiery turtle
by your definition, a program that starts with an acquire barrier instruction isnt allowed to exist
because there isnt anything before it
flat badge
bullshit
fiery turtle
fences aren't loads or stores, they effectively raise the ordering of other load...
yeah i get that
what im saying is for the purposes of the acquire barrier, the only loads or stores that matter to us, are those that happen after the barrier
i've yet to understand why thats not the case
flat badge
any read before the acquire fence (this set is empty if the acquire is at program start) cannot be reordered with any read or write after the acquire fence (the entire program)
fiery turtle
why read specifically?
flat badge
because that's the freaking definition
fiery turtle
where
gentle peak
what im saying is for the purposes of the acquire barrier, the only loads or sto...
an acquire fence raises the ordering of all prior atomic loads to acquire. that's all it does
flat badge
you cited it 10x already from the cppref summary
no reads or writes in the current thread can be reordered before this load
fiery turtle
"this load" mentions no prior loads?
flat badge
this load refers to
- the load done by the load-acquire
- in case of fences: to all previous loads
fiery turtle
so then "any read" in your definition means "this read" for a single atomic (non-fence) load?
flat badge
the cppref summary is imprecise because it doesn't distinguish fences and load-acquire
acquire fences are stronger than load-acquire
fiery turtle
yeah i think this is where we misunderstood each other
flat badge
because acquire fences apply to all previous loads while load-acquire applies to exactly one load, the one done by the load-acquire
likewise, release fences apply to all future stores while store-release applies to exactly one store, the one done by the store-release
fiery turtle
so then
any read before the acquire fence (this set is empty if the acquire is at program start) cannot be reordered with any read or write after the acquire fence (the entire program)
for one load-acquire can be transformed into
an acquire load cannot be reordered with any read or write after the acquire load
correct?
flat badge
yes
fiery turtle
lmfao
yeah sorry i misunderstood what u were trying to say
this is what i meant this whole time as well
because fence vs load confusion
fiery turtle
yes
btw by "any read before the acquire fence" do u mean only atomic reads, or do non-atomic ones also get promoted to acquire
fiery turtle
so basically non-atomic reads before an acquire fence can be reordered after the fence?
gentle peak
if they're after the last atomic load the fence applied to, sure
fiery turtle
ah right, if they're before that still works fine
gentle peak
or well acquire doesn't prevent reordering things before it to past it so any read can be reordered to after an acquire fence
but the same would be true if you replaced the fence with an acquire load
but yeah C's fences are only useful for lifting relaxed loads/stores into acquire/release ones
fiery turtle
but yeah C's fences are only useful for lifting relaxed loads/stores into acquir...
so they're basically a bulk convert previous atomic op ordering into something else
or well, following for release i guess
gentle peak
yep
vast kestrel
Tbf that's how fences are usually implemented in CPUs
vast kestrel
x86 is a bit different, because the default semantics are already read acquire store release (or well, technically stronger but still)
And cmpxchng is basically seq_cst
Or well, the locked version
fiery turtle
hm
vast kestrel
Mfence is used for seq_cst operations
And I think sfence and lfence are only useful for the non-temporal moves
Since those bypass tso
fiery turtle
but yeah C's fences are only useful for lifting relaxed loads/stores into acquir...
i guess linuxes ones actually guarantee that this applies to all previous operations, not just the atomic ones
(3) Read (or load) memory barriers.
A read barrier is an address-dependency barrier plus a guarantee that all
the LOAD operations specified before the barrier will appear to happen
before all the LOAD operations specified after the barrier with respect to
the other components of the system.
A read barrier is a partial ordering on loads only; it is not required to
have any effect on stores.
Read memory barriers imply address-dependency barriers, and so can
substitute for them.
[!] Note that read barriers should normally be paired with write barriers;
see the "SMP barrier pairing" subsection.
If you really wanna have fun I think aarch64 has a format memory model definition, including litmus tests and all the fun stuff
fiery turtle
If you really wanna have fun I think aarch64 has a format memory model definitio...
How do you test that stuff
trim frost
`qemu-system-x86_64 -M q35 -cpu host -debugcon stdio -boot order=d,menu=on,splas...
updated and is about ~100k-200k faster on my pc
may i request to be put on the leaderboards?
vast kestrel
How do you test that stuff
There are ways to formalize the memory model semantics and then write a test to check if that condition can happen under that memory model
Lemme find the aarch64 one
fiery turtle
updated and is about ~100k-200k faster on my pc
may i request to be put on the l...
Yes, just give me a link, short description, and the CPU
fiery turtle
Lemme find the aarch64 one
Thanks
vast kestrel
I am not gonna pretend like I ever looked at it too deeply, but I just think it's pretty cool
trim frost
Yes, just give me a link, short description, and the CPU
https://github.com/BUGO07/chronos
another x86_64 kernel held together by duct tape, made in rust
~3M points on i5 12400F
~3.7-3.8M points on i7 13700K (should be ~4M now)
fiery turtle
https://github.com/BUGO07/chronos
another x86_64 kernel held together by duct ta...
Can you give the full number
vast kestrel
What's cool about this is that once they defined all the semantics they want, they can test them against the models of arches that also have their semantics formalized, so they can ensure that they use the correct instructions to implement their barriers to keep the Linux semantics correct
fiery turtle
What's cool about this is that once they defined all the semantics they want, th...
Yeah
fiery turtle
https://github.com/herd/herdtools7/tree/master/catalogue/aarch64-VMSA
Thx, ill take a look
trim frost
Can you give the full number
3864224 on i7 13700K
im the only one with 3.xxM on the leaderboards
slim panther
https://github.com/BUGO07/chronos
another x86_64 kernel held together by duct ta...
i see you're using talc, how do you do page allocations with that?
left orbit
updated and is about ~100k-200k faster on my pc
may i request to be put on the l...
3892685/s
basically the same
calm latch
It's about 2kk on 5900X
trim frost
i see you're using talc, how do you do page allocations with that?
check memory/vmm.rs
zinc roost
i fixed it btw, you can clone again
I sleeb
trim frost
check memory/vmm.rs
Or don't, I get an overflow error when booting on my laptop on debug builds
torpid root
i see you're using talc, how do you do page allocations with that?
I don't think he does
slim panther
does what?
torpid root
page allocations
flat badge
only atomic ones
You're right that this affects only atomic ones, but that's more an artifact of how C works
For non atomic vars, C doesn't even guarantee that they are written by a single CPU operation
So it can't make any synchronization claims about them
I also don't think that linux's memory model does
Linux has READ_ONCE for this purpose
On existing ISAs, properly aligned single instructions accesses are always relaxed atomics
loud ice
except that a normal C load is not because it is subject to optimizations ofc
do acquire fences even apply to normal reads and writes?
flat badge
Depends on what you mean by apply
loud ice
have any impact on them
#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
this definition of read_once is somewhat unsound aiui
flat badge
yeah the linux memory model is a mess in general
loud ice
better than nothing for sure
flat badge
and it makes a lot of assumptions about what GCC does
loud ice
but its invalid regardless
the VERY fun thing is that while a volatile read occuring is a side effect
the value of it is not a program input (afaik)
flat badge
have any impact on them
essentially you need a atomic var for the synchronization, but the fence still orders the non-atomic accesses around it
otherwise, non-atomic accesses could be moved out of mutexes etc
loud ice
essentially you need a atomic var for the synchronization, but the fence still o...
the fence there only works together with an atomic write
i.e. it attaches to a surrounding atomic
flat badge
if you have
b.load(relaxed)
fence(acquire)
a.load(non_atomic)
then the acquire fence can potentially make the load of b synchronize with a store release
fiery turtle
So it can't make any synchronization claims about them
So in the C memory model, how would you even synchronize something like:
atomic_load(x, acquire);
// unrelated data
memcpy(...);
// reload to make sure the state is the same
atomic_load(x, acquire);
With this memcpy can be reordered to after the load since its not an atomic store
loud ice
So in the C memory model, how would you even synchronize something like:
atomi...
atomic_load(x, acquire); doesnt prevent writes from going below it
only from reads and writes coming above it
fiery turtle
Read the question
fiery turtle
the answer is that you need an atomic store aiui
Yeah that's the only solution I guess
Have an unrelated atomic store
flat badge
So in the C memory model, how would you even synchronize something like:
atomi...
acquire is not strong enough
you need sequentially consistent fences here
fiery turtle
you need sequentially consistent fences here
Would a seq cst fence be enough to prevent memcpy reorder?
fiery turtle
Lol
loud ice
no nvm i think it would so long as that second atomic load is present maybe?
fiery turtle
And do u actually need a fence or is it enough to keep seq cst on both loads
fiery turtle
no nvm i think it would so long as that second atomic load is present maybe?
Yeah no idea
loud ice
the answer is "ask a model checker"
fiery turtle
Too skill issued
flat badge
So in the C memory model, how would you even synchronize something like:
atomi...
this doesn't even work if you replace the memcpy by relaxed atomics
btw
flat badge
the last load-acquire doesn't gurantee anything
fiery turtle
Well it guarantees synchronization with a previous store, but doesn't prevent reordering with memcpy that's true
flat badge
even if you treat the memcpy as atomic accesses, the final load acquire would only guarantee that following loads are more recent than the value loaded by the load-acquire
fiery turtle
Linux code used two smp_rb barriers with relaxed loads here btw
loud ice
what does smp_rb do?
flat badge
it's a read-read barrier
loud ice
ah
fiery turtle
Prevents read recorders yeah
loud ice
so dmb ish on arm
and a compiler fence on x86
based on webkit headers: https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/Atomics.h
fiery turtle
even if you treat the memcpy as atomic accesses, the final load acquire would on...
Yeah so u would have to release store for each byte lmfao
C memory model is not less stupid that Linux tbh
loud ice
at least it maps somewhat better to hw
flat badge
the linux memory model is stupid beyond imagination
it's also only held up by hopes and dreams that GCC doesn't change its behavior
fiery turtle
Lol
left orbit
they probably won't because of linux
fiery turtle
Well they have a .cat file
loud ice
it's also only held up by hopes and dreams that GCC doesn't change its behavior
and then clang comes along
lol
flat badge
clang already handles volatile access differently than GCC
fiery turtle
it's not modeled after any real architecture
Btw you suggested a seq cst barrier initially, but aren't these barriers basically used to elevate the ordering of surrounding atomic operations? Like what would be the difference of a pair of seq cst barriers vs just marking both loads seq cst
And iirc seq cst doesn't play nice with non seq cst stores from other places or whatever
There was some weird interaction there
So would all stores/loads to that var have be seq cst
slim panther
even if you treat the memcpy as atomic accesses, the final load acquire would on...
?????
that's stupid
flat badge
the correct way to do a seqlock is:
left orbit
doesn't seq-cst mean no reads or writes before can be moved after that operation and no moves after can be moved before that operation?
fiery turtle
?????
Well acquire only prevents the following stuff to be reordered with the atomic acquire
That's just how it works
left orbit
why is atomic stuff so complicated to reason about all of a sudden
slim panther
real
flat badge
seq.load(acquire)
if (dirty)
retry
data1.load(relaxed)
data2.load(relaxed)
data3.load(relaxed)
fence(acquire)
seq.load(relaxed)
if (mistatch)
retry
Because modern hw is hard 💀
slim panther
hw was a mistake
left orbit
Because modern hw is hard 💀
it's not like any of it applies to x86
it's just compiler optimizations here
flat badge
well you posted a seqlock
trim frost
why is atomic stuff so complicated to reason about all of a sudden
It's not, rust docs explain it perfectly
gentle peak
```
seq.load(acquire)
if (dirty)
retry
data1.load(relaxed)
data2.load(relaxe...
how does this prevent data1..3 loads being reordered to after the last seq.load?
loud ice
it does not
flat badge
the acquire fence guarantees that the last seq.load is at least as new as all the data reads
loud ice
It's not, rust docs explain it perfectly
yes it is
fiery turtle
lol
gentle peak
ahh i see
loud ice
thats like the point
fiery turtle
why have we spent 5 hours talking about atomics here
if we could just read the rust docs
trim frost
if we could just read the rust docs
Ikr
loud ice
ahh yes nothing like rust
gentle peak
It's not, rust docs explain it perfectly
the rust docs have an extremely oversimplified summary of it
left orbit
i feel like atomics are one of those "if you think you understand it, think again" things
fiery turtle
thats like the point
can u elaborate
loud ice
can u elaborate
the entire reason for this convo is that they are very complicated
fiery turtle
it does not
i was refering to this
left orbit
i'm sooo glad i don't understand any of it, i simply don't have to worry about it :^)
fiery turtle
well you posted a seqlock
how would you synchronize the above code with the C model
fiery turtle
i think ill never understand atomics
gentle peak
how would you synchronize the above code with the C model
if you want a pure standards-compliant version: use an atomic_memcpy where every byte load is a relaxed atomic load and put an acquire fence between the atomic_memcpy and the last load
fiery turtle
```
seq.load(acquire)
if (dirty)
retry
data1.load(relaxed)
data2.load(relaxe...
Is the reason this works because data load reordering past the check doesnt matter?
loud ice
it does i think
fiery turtle
if you want a pure standards-compliant version: use an atomic_memcpy where every...
atomic_memcpy is not a thing tho i think?
loud ice
my understanding is that this code is invalid
fiery turtle
atomic_store(dst[i], src[i], release)?
gentle peak
relaxed
fiery turtle
and a release barrier after?
gentle peak
and more like dst[i] = atomic_load(src[i], relaxed)
loud ice
or alternatively
gentle peak
then atomic_fence(acquire) and another load
the acquire fence will prevent the load after it from being reordered before any of the relaxed loads in the memcpy
fiery turtle
hm
loud ice
__attribute__((naked)) void atomic_memcpy(char* dst, const char* src, size_t len) {
// don't tell clang
asm("jmp memcpy");
}
lmao
fiery turtle
but clang would have to be able to see the atomic loads lol
loud ice
but clang would have to be able to see the atomic loads lol
no it doesnt
fiery turtle
otherwise it cant prove anything
flat badge
write side:
s = seq.load(acquire)
seq.store(s + 1, relaxed)
fence(release)
data1.store(relaxed)
data2.store(relaxed)
data2.store(relaxed)
seq.store(s + 2, release)
clang has to assume that inline asm performs an unknown sequence of AM operations
gentle peak
otherwise it cant prove anything
with this it's like atomic_memcpy was implemented in another TU and there's no LTO involved
loud ice
which can include an atomic memcpy
gentle peak
it doesn't know anything about what it does, so it has to assume the "worst"
which in this case works in our favor
fiery turtle
just attribute(alias_of)
flat badge
actually the first load can be relaxed i guess
gentle peak
or .globl atomic_memcpy; .set atomic_memcpy, memcpy
actually idk if that works across shared objects
fiery turtle
actually the first load can be `relaxed` i guess
dont think so? otherwise there isnt a happens-before with the release
loud ice
just attribute(alias_of)
that could be reasoned about
flat badge
with which release?
loud ice
asm cannot be
fiery turtle
with which release?
the last seq release by the previous writer
flat badge
the acquire synchronizes with the last update of the seqlock
but if that's not needed because the entire contents are overwritten anyway, it can be relaxed
depends on what exactly you do with data1 etc
if you rmw it, it needs to be acquire
fiery turtle
what does seq have to do with the contents
flat badge
if you just store independent data, it can be relaxed
fiery turtle
then stores can be reordered to before the release
flat badge
no, stores can not be reordered before release barriers, that's the point of release
loud ice
```
seq.load(acquire)
if (dirty)
retry
data1.load(relaxed)
data2.load(relaxe...
An atomic operation A that is a release operation on an atomic object M synchronizes with an
acquire fence B if there exists some atomic operation X on M such that X is sequenced before B
and reads the value written by A or a value written by any side effect in the release sequence headed
by A.
this doesnt seem like it supports this being correct
fiery turtle
no, stores can not be reordered before release barriers, that's the point of rel...
thats not how that works tho
data1.store() can be reordered, a release above doesnt protect it
flat badge
> An atomic operation A that is a release operation on an atomic object M synchr...
what exactly are you concerned about?
flat badge
data1.store() can be reordered, a release above doesnt protect it
reordered to where?
fiery turtle
to after the relaxed load
flat badge
a preceeding release fence prevents reordering, yes
flat badge
it's not clear to me what you mean, can you post the whole listing?
where can what be reordered to?
fiery turtle
s = seq.load(relaxed)
seq.store(s + 1, relaxed)
fence(release)
data1.store(relaxed)
can be reordered to
s = seq.load(relaxed)
data1.store(relaxed)
seq.store(s + 1, relaxed)
fence(release)
the fence turns data1.store into a released store
flat badge
yeah this can't happen
gentle peak
seq is a memory access before a released store
so seq cannot be reordered to after data1
loud ice
what exactly are you concerned about?
that the data loads can be moved past the fence
and then the seq load can be moved before them
flat badge
the only reorderings that are possible are reorders of the data1 vs data2 vs data3 stores
fiery turtle
wait I always forget whether these fences apply to previous or next operations
gentle peak
release applies to next, acquire to prev
fiery turtle
whats the intuition here?
loud ice
if that program was in fact correct, then this would not panic: ```rs
fn thread1() {
loop {
let data = sh.data.0.load(Ordering::Relaxed);
fence(Ordering::Acquire);
let seq = sh.seq.0.load(Ordering::Relaxed);
assert!(data <= seq);
}
}
fn thread2() {
let mut n = 0;
loop {
sh.data.0.store(n, Ordering::Relaxed);
fence(Ordering::Release);
sh.seq.0.store(n, Ordering::Relaxed);
n += 1;
}
}
and it does panic
flat badge
if that program was in fact correct, then this would not panic: ```rs
fn thread1...
that is not what the program does
loud ice
that is not what the program does
hmm
is it not?
am i missing fences?
ah wait yeah i am
okay
gentle peak
whats the intuition here?
a release fence makes all future stores release stores, and thus any previous memory ops cannot be reordered past the first atomic store after the fence
an acquire fence makes all past loads acquire loads, and thus any future memory ops cannot be reordered to before the last atomic load before the fence
loud ice
that is not what the program does
std::thread::Builder::new()
.spawn(move || loop {
let seq1 = sh.seq.0.load(Ordering::Acquire);
let data = sh.data.0.load(Ordering::Relaxed);
fence(Ordering::Acquire);
let seq2 = sh.seq.0.load(Ordering::Relaxed);
if seq1 == seq2 {
assert!(data == seq1);
}
})
.unwrap();
let mut s = 0;
loop {
sh.seq.0.store(s, Ordering::Relaxed);
fence(Ordering::Release);
sh.data.0.store(s, Ordering::Relaxed);
sh.seq.0.store(s + 1, Ordering::Release);
s += 2;
}
is this better?
this still panics, btw
loading a number lower than seq1
flat badge
the write side is still wrong
loud ice
ah
flat badge
you want to store s + 1, then s + 2
loud ice
i am
std::thread::Builder::new()
.spawn(move || loop {
let seq1 = sh.seq.0.load(Ordering::Acquire);
let data = sh.data.0.load(Ordering::Relaxed);
fence(Ordering::Acquire);
let seq2 = sh.seq.0.load(Ordering::Relaxed);
if seq1 == seq2 {
assert!(data == seq1, "loaded {seq1} vs {data} vs {seq2}");
}
})
.unwrap();
loop {
let s = sh.seq.0.load(Ordering::Relaxed);
sh.seq.0.store(s + 1, Ordering::Relaxed);
fence(Ordering::Release);
sh.data.0.store(s, Ordering::Relaxed);
sh.seq.0.store(s + 2, Ordering::Release);
}
``` better?same result
because the program is equivalent lol
flat badge
sh.data.0.store(s, Ordering::Relaxed); <--
loud ice
you want to store s + 1, then s + 2
i just have s cached because there is onlt one writer
oh wait
yeah
nvm
std::thread::Builder::new()
.spawn(move || loop {
let seq1 = sh.seq.0.load(Ordering::Acquire);
let data = sh.data.0.load(Ordering::Relaxed);
fence(Ordering::Acquire);
let seq2 = sh.seq.0.load(Ordering::Relaxed);
if seq1 == seq2 {
assert!(data >= seq1, "loaded {seq1} vs {data} vs {seq2}");
}
})
.unwrap();
loop {
let s = sh.seq.0.load(Ordering::Relaxed);
sh.seq.0.store(s + 1, Ordering::Relaxed);
fence(Ordering::Release);
sh.data.0.store(s, Ordering::Relaxed);
sh.seq.0.store(s + 2, Ordering::Release);
}
ah wait nvm
flat badge
try to convert my pseudocode to a working program challenge (impossible)
loud ice
lol
i mean yeah your code is broken so like (/j)
std::thread::Builder::new()
.spawn(move || loop {
let seq1 = sh.seq.0.load(Ordering::Acquire);
let data = sh.data.0.load(Ordering::Relaxed);
fence(Ordering::Acquire);
let seq2 = sh.seq.0.load(Ordering::Relaxed);
if seq1 == seq2 {
assert!(data == seq1, "loaded {seq1} vs {data} vs {seq2}");
}
})
.unwrap();
loop {
let s = sh.seq.0.load(Ordering::Relaxed);
sh.seq.0.store(s + 1, Ordering::Relaxed);
fence(Ordering::Release);
sh.data.0.store(s + 2, Ordering::Relaxed);
sh.seq.0.store(s + 2, Ordering::Release);
/*unsafe {
core::arch::asm!("dc cvau, {}", in(reg) &sh.data);
}*/
}
i tried adding a dc cvau to try making it hit more but it didnt help
flat badge
so, does it work now?
loud ice
no
it loads a value of data higher than both seq1 and seq2
or lower if i mess with the dc cvau
fiery turtle
a release fence makes all future stores release stores, and thus any previous me...
Thanks
fiery turtle
```rs
std::thread::Builder::new()
.spawn(move || loop {
...
Why would you even need fences here, just use acquire directly
Well and release
loud ice
Why would you even need fences here, just use acquire directly
because thats the point of what im trying to show
acquire would fix it
lol
flat badge
the test is still incorrect
and doesn't match my pseudocode
because seq1 == seq2 is not the right test ;D
fiery turtle
Pitust do u know what seqlock does 
flat badge
you're missing if seq1 & 1 { continue }
loud ice
okay yea works now
fiery turtle
It makes concurrent reads and writes to data larger than a pointer possible by making readers retry
If seqnum is odd or changed from the initial
flat badge
okay yea works now
see, my code was correct :^)
fiery turtle
What does your code look like now
loud ice
std::thread::Builder::new()
.spawn(move || loop {
let seq1 = sh.seq.0.load(Ordering::Acquire);
if seq1 & 1 != 0 {
continue;
}
let data = sh.data.0.load(Ordering::Relaxed);
fence(Ordering::Acquire);
dmb();
let seq2 = sh.seq.0.load(Ordering::Relaxed);
if seq1 == seq2 {
assert!(data == seq1, "loaded {seq1} vs {data} vs {seq2}");
}
})
.unwrap();
loop {
let s = sh.seq.0.load(Ordering::Relaxed);
sh.seq.0.store(s + 1, Ordering::Relaxed);
fence(Ordering::Release);
sh.data.0.store(s + 2, Ordering::Relaxed);
sh.seq.0.store(s + 2, Ordering::Release);
}