uACPI - a portable and easy-to-integrate ACPI implementation

[fiery turtle]

what the fuck

[mortal yoke]

its a result of the limine template globbing (and uacpi being inside the src dir)

[vocal geyser]

qemu-system-x86_64 -cdrom orange.iso -M q35 -enable-kvm -m 1G

i dont getting errors when compiling

[vocal geyser]

wtf

[mortal yoke]

I also get basically the same score

[vocal geyser]

interesting

[fiery turtle]

did u commit the allocator fixes

[vocal geyser]

try this iso

[vocal geyser]

with this arguments

[vocal geyser]

now i need to think

[jaunty fox]

i got a much better result

[vocal geyser]

why we getting another results

[jaunty fox]

i see an iso so i ran it

[vocal geyser]

like why they getting 60k but you and me getting 2mln

[jaunty fox]

what CPU do you have?

i have a ryzen 5800x

[vocal geyser]

ryzen 5 3600

[fiery turtle]

code unoptimized for intel

[vocal geyser]

intel discrimination

git submodule skill issue

[mortal yoke]

more like glob skill issue lol

[vocal geyser]

for now just delete tests folder ✅

[mortal yoke]

why not just move it out of the src folder and either add the uacpi sources manually or do a different glob with only c files in the uacpi dir

[vocal geyser]

maybe i can just remove a tests folder in makefile

although this is also a normal solution

[north holly]

could someone (with a fast cpu) test this iso 🥺
qemu-system-x86_64 -M q35 -enable-kvm -cpu host -debugcon stdio

and send me the score afterward

@left orbit test iso pls 🥺

[left orbit]

on it

[north holly]

ty

[left orbit]

[uACPI][INFO]: successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1144648/s)
[uACPI][INFO]: successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1108243/s)
[uACPI][INFO]: successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1132732/s)
[uACPI][INFO]: successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1119295/s)```

seems kinda low

[north holly]

what

oh

[mortal yoke]

2167942/s is what I got

[north holly]

what

proof

[left orbit]

yeah wsl moment

[north holly]

can you send screenshot?

[mortal yoke]

it varies a little but its around there

[north holly]

what a fast cpu can do to a kernel

@fiery turtle I got a new score for you

for obos

[uACPI][INFO]: successfully loaded 1 AML blob, 1705 ops in 1ms (avg 2141179/s)```

[fiery turtle]

which cpu

[north holly]

whatever qwinci's cpu is

@mortal yoke

[left orbit]

14600k?

[mortal yoke]

i5 13600k

[left orbit]

ah not ev en close lol

[fiery turtle]

lol

[dense steppe]

@mortal yoke would you mind testing this image?

[fiery turtle]

qwinci do I add your kernel?

[north holly]

slowly but surely I will take over the leaderboard

[fiery turtle]

if so, do i literally call it crescent 2

[mortal yoke]

~6.1M but it varies like streaks said too

[dense steppe]

yeah, that is kinda expected tbh

I have to improve my debugging tools so I can profile and get a good score on AMD CPUs too

[vale isle]

i need to fix nixpkgs nooooo

[mortal yoke]

idk lol, the description that I posted is kinda weird at least (and the name is what it is but ig it doesn't really matter even if it would be called crescent2 for now and be renamed later™️)

[dense steppe]

(maybe start by actually implementing some debugging tools)

[fiery turtle]

the description seems fine

sure np

i didnt see that u edited it as a full entry

[mortal yoke]

ah yeah I added the score

[fiery turtle]

i mean it looked like a placeholder before

yeah

[north holly]

infy is uacpi_kernel_install_interrupt_handler only called during namespace init, and not in load

[fiery turtle]

idr

[median crest]

@fiery turtle if you do update the scores this is my submission for now until I can coerce someone with an even better cpu to run it

[mortal yoke]

its only called in uacpi_initialize

[north holly]

qwinfy

qwinci+infy

[mortal yoke]

or actually looks like namespace load too

[fiery turtle]

Updated leaderboard: https://github.com/uACPI/uACPI/tree/misc-assortment?tab=readme-ov-file#notable-projects-using-uacpi--performance-leaderboards

[fiery turtle]

i think load only(?)

it should be calld during event init

[mortal yoke]

yeah I accidentally looked at the wrong function lol

[fiery turtle]

crescent just took over 2nd lol

[north holly]

what would happen if "notable projects using uacpi" was changed to actually only include notable projects

like ones that actually use uacpi API, and don't just have it for the lulz

[fiery turtle]

lol

[north holly]

I'd bet half the kernels on there would be gone

[fiery turtle]

some of these might get abandoned and then ill remove them

[north holly]

like astral

[fiery turtle]

astral is kinda back

[mortal yoke]

I don't use uacpi api 💀

[torpid root]

didn't leo said he wouldn't eat or sleep and try to get more points if managarm was surpassed

[north holly]

so you just have it for the lulz

[mortal yoke]

though I do intend on using it after acpi.sys becames a thing

to implement acpi ioctl api

[fiery turtle]

that was back when 1M was considered insane

[torpid root]

good ol' times

[north holly]

I should make a time machine using obos

then go back in time

and tell old me how to optimize stuff to the brim

in obos

[torpid root]

it'll crash mid-travel and you'll end up with dinosaurs

[north holly]

shi you're right

[vale isle]

use NT acpi.sys maybe

for funs

[left orbit]

use the uacpi acpi.sys from ros (once it becomes upstream)

[mortal yoke]

could be fun, would have to figure out what kind of interface it has tho

[kind mantle]

I still think everyone should test on the same HW and I still offer my services to do so.

[jaunty fox]

what do you have?

[kind mantle]

Not @ my desktop right now but I will be again soon

Ryzen 5 3600

[vale isle]

we should have an osdev performance test server

[kindred beacon]

I used to run a lot of the benchmarks on my 14700K, not a new idea

[vale isle]

like how browsers have wpt.fun or whatever it was (web platform tests)

[jaunty fox]

we are all in favour of establishing a clearinghouse for benchmarks

the question is who will get it set up

[vale isle]

i am down to help developing it

but I don't have any hosting experience of any kind

[kind mantle]

I don't have something that can be up all the time

[jaunty fox]

if you do it manually that's also acceptable i suppose

just a bit of an onerous demand on someone

[kind mantle]

Manually is fine by me as long as it's not like 10 a day

[left orbit]

i am testing a lot too already so

[vale isle]

I want to run hydra for my OS (to build the entirety of nixpkgs)

[vale isle]

then I can give a % of working nix pkgs

[kind mantle]

Should we make a poll of whoms't becomes the tester™️?

[jaunty fox]

an auto runner is not an absurd idea it's just that realistically whoever owns it will want to be careful who he lets use it, because it'd be a lot more work to make it robust for public exposure

[fiery turtle]

take a look at yesterdays discussion

[dire owl]

OSDev test lab

[fiery turtle]

im totally down but it shouldnt be a willy nilly "ill test lol"

[vale isle]

I think it's fine for like tagged releases

[left orbit]

my idea was to have it running as a systemd service so basically whenever my pc is on i can test in the background lmao

[north holly]

I actually have a computer that can probably be on like 24/7

and host something like that

although it's not fast

[fiery turtle]

it has like a pentium 4 right

[north holly]

what

no

[vale isle]

if it's useful I have a pi5 for native aarch64

[fiery turtle]

lmfao

[left orbit]

i think we don't need like an actual 24/7 thing tho

[fiery turtle]

we dont

[jaunty fox]

that'll be nice

i'll only be competing with managarm there

[fiery turtle]

we just need to accumulate a few isos and test once in a while

[left orbit]

i have an m1 mac i don't use

[fiery turtle]

it would take half an hour tops

[north holly]

I use(d) it for mc servers

[left orbit]

but a pi would be nice

[left orbit]

fair enough, as many people i am also volunteering

i can reboot into linux for host consistency every few days

[fiery turtle]

first person to suggest and implement an actual infra for that gets selected

[north holly]

I also call this pc test subject 2 iirc

[left orbit]

so we want it to be automatic after all? 🤔

[fiery turtle]

like ideally it's:

• an automatic submission, at least for projects already on the board
• automatic batch PR for score changes

[north holly]

oh wait infy

you posted my new score on the leaderboard

[fiery turtle]

also would be nice to have isolcpus= and pin qemu there

[north holly]

but that code isn't upstream

[kind mantle]

Inb4 GitHub hooks that submit the new ISO to score

[left orbit]

you can do a pr using a github user token so

[fiery turtle]

yeah

[mortal yoke]

also automatic testing would require getting the score from smth like serial and also ideally doing an average because there are some very bad runs sometimes

[left orbit]

checkout master, make changes, commit and push to remote then open pr

like 30 lines of python code

[left orbit]

yeah we talked about that

[fiery turtle]

yep

hyperfine it

[north holly]

ok now it is upstream

[fiery turtle]

and of course pin on one cpu

[kind mantle]

I meant submitting to the server that scores them

[left orbit]

basically require anyone to provide it over debugcon or serial

[fiery turtle]

ye

[gentle peak]

and probably a timeout of like 10s

[vale isle]

uSpeedTest

uCI

[left orbit]

ok let me play around with it lol

[kind mantle]

uTournament

[dense steppe]

uci is a chess engine thing

[fiery turtle]

if anyone actually makes a proper thing we can put it on the uacpi project page as well for nice versioning

[dense steppe]

oops

wrong message

[vale isle]

i meant like

[north holly]

uEgoBooster

[dense steppe]

i meant to reply to this

[dense steppe]

that's kinda what it is lol

[vale isle]

ultraContIntegragitiion

[fiery turtle]

also imagine a separate application page for new projects to submit themselves

[vale isle]

i cna't tpyd

cool!!

[fiery turtle]

this could be really cool tbh

but effort needed

[left orbit]

hacker@raptor:~/uacpi-bench-runner$ ls /mnt/c/Users/hacker/Desktop/ | grep iso
Apartheid.Linux.Cyberwar.Edition.x64.iso
archlinux-2025.02.01-x86_64.iso
astral.iso
barebones (1).iso
barebones.iso
davix (1).iso
davix.iso
davix.iso.gz
debian-live-12.9.0-amd64-standard.iso
image-x86_64.iso
iso9660.iso
iso9660.isoasdads
iso9660.iso.zip
obos.iso
proxima (1).iso
proxima.iso
testbed.iso
Win11_24H2_English_x64.iso```

which one of these isos is most likely to do uacpi output over serial

Ignore the first one

😇

[north holly]

ugh I want to do TCP but at the same time I don't want to

I want to because it's fucking cool

[left orbit]

obos will do ⭐

[fiery turtle]

proxima should

[gentle peak]

I feel like this should be mostly manual to avoid malicious ISOs

[left orbit]

ok let me try proxima obos was kinda slow

[north holly]

I don't want to because it fucking sucks

[gentle peak]

recent proxima builds do debugcon

[fiery turtle]

the review process is manual ofc

[left orbit]

yep my proxima iso does debugcon

[fiery turtle]

and existing users can auth via github to re-submit or smth

[left orbit]

epiccc

[north holly]

have you ever heard of ls *.iso

[left orbit]

nope

effort

[fiery turtle]

the classic <any command that can probably grep itself> | grep

[north holly]

cat foo.txt | grep bar

[fiery turtle]

cat /dev/nvme0n1p1 | grep

[left orbit]

any idea how i can capture both serial and debugcon to a file?

or two separate files, doesnt matter

idk how this whole chardev shit works

[north holly]

-debugcon file:shit.txt

[gentle peak]

one to stdio, one to file:/dev/stdout

[left orbit]

ah simple enough

ill do both to a file

consistency

[fiery turtle]

output to separate files

[left orbit]

yep

[fiery turtle]

you will be reading it from python anyway right

[north holly]

shell script

[left orbit]

python ftw

[fiery turtle]

u can also just open pipes via subprocess

[north holly]

so yeah what I usually do is write all my programs in C because I don't know any sort of scripting language properly

[left orbit]

but idk how to make qemu output serial to a pipe sooo

or debugcon for that matter

[median crest]

astral does debugcon

[fiery turtle]

yeah dont do that anyway, there are some memes with those pipes overflowing

[kind mantle]

Unix socket?

[median crest]

though Ig you need to enable it

nvm

[left orbit]

ohhh thats true

temp files are ok anyway

[north holly]

obos automatically enables debugcon if it detects it's on a hypervisor

[kind mantle]

BadgerOS does both debugcon and COM1

[median crest]

wouldn't qemu_system_x86_64 -serial stdio | command work

[fiery turtle]

wait until u find out about in(0xE9) == 0xE9

[frank canopy]

theres also pipe:some_pipe_name output for qemu

[north holly]

whoaaaaaaaaaaaaaaaaaaaaaaaa

[fiery turtle]

very anti pythonic way to capture output lmfao

[fiery turtle]

works in both bochs and qemu

[median crest]

you can still do -serial stdio and use the subprocess.run thing to pipe no?

[fiery turtle]

ye

[frank canopy]

i know for windows you can go pipe:\\.\pipe\<pipename> id assume theres similar for using a unix socket on *nix or something idk

[north holly]

named pipes?

[frank canopy]

yeah

[north holly]

yeah posix has those

[frank canopy]

(dont use that pipe bit for windbg btw it makes qemu die)

[north holly]

or wahtever the spec is called I forgor

posix unix linux

all the same to me

[frank canopy]

yeah i only know the windows ones lol

[north holly]

now I gtg implement TCP reception

https://cdn.discordapp.com/emojis/816178972672131083.gif?size=256

[frank canopy]

gl

[north holly]

thanks (I will need it)

so far I can uhh

check the checksum

anyway

[mortal yoke]

its not that bad

anyway not going to detail here in uacpi thread lol

[frank canopy]

im in oh god why does irl keep giving me things i need to do i just want to do nvme mode lol

for my os

[left orbit]

i think i might have to do unix sockets because i can just read from them from python and i can exit once i get the measurement

idk if i can just open the files and read until i get the measurements too

[north holly]

I will be implementing it based on the first TCP spec

hopefully TCP is backwards compatibile

[left orbit]

i need to write some async python code for this shit i think, i need the timeout but i also need to read lines from both of the files

[north holly]

idk if it's the first, but I'm doing it on RFC793

[left orbit]

@fiery turtle ur the python expert here, any idea how to do this properly?

[fiery turtle]

i kinda hate subprocess piping hmm

[left orbit]

well im just thinking of how to do the timeout + reading both files part

i will kill the process either after getting the measurement or after timeout

[frank canopy]

why not let the submission tell you which output it uses?

[fiery turtle]

why do u not like the idea of just

subprocess.run(qemu -debugcon <file1> -serial <file2>)

with open(<file1>) as f:
    e9_output = f.read()

with open(<file2>) as f:
    serial_output = f.read()

[left orbit]

because i dont know when the output comes in

so i might not read anything

i have to wait for the data to come in

but i also want a timeout

[fiery turtle]

subprocess run is synchrnonous

[left orbit]

i know

[fiery turtle]

u can set e.g. a 10 second timeout and just wait until it dies

run takes in a timeout right

[left orbit]

but i cant do anything until the timeout expires

and i dont want to do that

i want to exit as soon as the measurements are output by the kernel

[fiery turtle]

well

fair ig

[north holly]

it'd be funny if a ten second timeout isn't enough for some kernels

[left orbit]

i am gonna do some async memes and see if i can make it work

[north holly]

cuz of how slow they are

[fiery turtle]

lfg

[north holly]

say how you do plan on implementing this

[fiery turtle]

ns load used to take like 30 seconds on nyaux?

[median crest]

if output_measured: == True:
exit()

[north holly]

anyone can just kprintf("%d ops/s\n", rand() + 1000000 % 2000000)

no like

[gentle peak]

if you want to check the output as it comes in for early exit you should probably use Popen instead of run

[fiery turtle]

we dont run random shit tho, only verified projects should be able to auto submit

[north holly]

fair

[gentle peak]

I feel like assuming that submitted ISOs aren't cheating is fine

[north holly]

how do you know I won't

[mortal yoke]

decompile the binary

[north holly]

[uACPI][INFO]: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 154523545/s)
[uACPI][INFO]: namespace initialization done in 1ms: 36 devices, 0 thermal zones```

[mortal yoke]

if the score is sus

[north holly]

obos fastest kernel

[gentle peak]

imo submitted ISOs should be associated with a specific git commit

of a public repo

[fiery turtle]

we'll make it so the runner injects random aml salt that will be printed if your run is fair

it's easy to implement too

[vale isle]

Level1Techs has a SiFive P550 Premiere that they want to give remote access to apparently

if we make automated speedtest

we can probably ask them

[fiery turtle]

we could just inject an SSDT that invokes an undefined reference, which will be printed by uACPI in your kernel's stdout

the name of the ref will be printed

and it doenst incur any unfair score penalties either

[north holly]

also make the ref randomly generated for good measure

[gentle peak]

wouldn't that include logging performance in the benchmark?

[fiery turtle]

yeah thats what im saying

[fiery turtle]

hm ig

but kernel_log is also an API soo

[fiery turtle]

actually, no, if we make it an _INI method, then it will only get to run after the benchmark

if it gets run we'll also know the number of times u did init and if u did namespace_initialize at all

[north holly]

wait I just realized

[gentle peak]

well yeah but unlike mutexes and allocators performance varies wildly based simply on where the kernel logs to - serial is slower than debugcon, framebuffer might have to scroll, etc

[north holly]

it's been 1 year since the first port of uacpi to a kernel

[fiery turtle]

yeye scratch that

[gentle peak]

ah ok

[fiery turtle]

the ssdt can be literally

// no cost, one extra namespace node for all runs
Method (\_INI) {
   Debug = \RAND.OM.NAME.<HASH>
}

[north holly]

I just realized that uacpi didn't have an overridable stdlib.h header when I first ported it

[left orbit]

lol for some reason select returns readable all the time on the file handles

i think i need a unix socket or something

[calm latch]

Can't you send some sort of signal to qemu?

[fiery turtle]

then this code can be injected via -acpitable <file>

[calm latch]

To send power button event

[left orbit]

why would i

i dont care about shutting down the vm

i want to wait for measurements asynchronously

while also having a timeout

[fiery turtle]

we could require that for a "complete" impl tbh lol

[calm latch]

OS shutting down would be also a good way to know that the impl is working

[fiery turtle]

yeah true

[mortal yoke]

but then not all os's may want to shut down immediately on power button press

[fiery turtle]

true

[calm latch]

No, but like wouldn't it arrive once uACPI is loaded?

[frank canopy]

or have that implemented yet even with a lot of other acpi stuff implemented

[north holly]

also what if a kernel doesn't handle those events

power button events

[frank canopy]

yeah

[fiery turtle]

L kernel

[north holly]

or propagates them to userspace

[median crest]

astral propagates it to userspace

[fiery turtle]

propegates lol

[north holly]

obos' kernel literally ignores all events other than EC events and wake GPEs

and wake GPEs don't even get handled by the kernel

[frank canopy]

i dont really care about power button stuff atm for my kernel

focusing on getting it working and doing stuff while on lol

[north holly]

reading through old messages of me testing uacpi in its early days is always fun

when infy was surprised it could actually shutdown on real hw

[fiery turtle]

fun tims

i was testing on my shitty kernel on my laptops

[north holly]

real

[left orbit]

any idea how i can properly do the measurement part? like filter out any outliers and such

and then average out the good ones

[fiery turtle]

run it 100 times?

but ideally u isolate a host CPU

[left orbit]

yeah but like, you can still get outliers

yeah yeah i mean

it can be done by a wrapper script

easy enough to switch out qemu itself

for a wrapped version

[fiery turtle]

true

[left orbit]

but i am speaking about the statistics part

hmm ill see if i can cook on this one

[median crest]

now you test it on other people's shitty kernels

[fiery turtle]

lol

I guess this is the format i'm going with for the version printout

[calm latch]

But at least, out of 16, at least 1 should be working on any given hardware

[north holly]

maybe initializing uACPI, version x

is better

[fiery turtle]

now the question is, should this be printed out even for early table init, or only during uacpi_initialize

[north holly]

imo, call it on the first call of uacpi initialize or of early table init

[fiery turtle]

i can make like a PRINT_ONCE for it and stuff but still

[calm latch]

You can print the version next to the benchmark

[fiery turtle]

the benchmark is very late init

doesnt make sense to print it there

[north holly]

it might also help to print the uacpi in uacpi errors after uacpi init

for bug reports or smth

obos does that on panic

[fiery turtle]

i mean if it's printed on boot anyway

u can just paste the entire log

hmm yeah looks better at the very top

[north holly]

uOEMID lol

[left orbit]

ok i got the first version of this thing, basically running the iso 50 times and collecting the measurements from serial and debugcon lol

mean = statistics.mean(measurements)
stdev = statistics.stdev(measurements)
lower_bound = mean - stdev * 2
upper_bound = mean + stdev * 2
filtered = [x for x in measurements if lower_bound <= x <= upper_bound]
mean = statistics.mean(filtered)```

it also does this shit for some reason idk how this works

and it writes the statistics to a json file for further processing i guess

[fiery turtle]

damn u even got component decoupling

[left orbit]

davix.iso no debugcon or serial

sadge

[dense steppe]

honestly for printing the version, I would do something like uACPI version 1.0.1

[left orbit]

idk what that means

but yes! (maybe, if u say so)

[dense steppe]

you can git clone it and enable debugcon by creating user/config.h and adding #define CONFIG_DEBUGCON 1

[left orbit]

effort

[dense steppe]

yea lol

[left orbit]

now time for the cpu pinning memes

[dense steppe]

I should probably like, actually parse a kernel commandline and provide the option to enable both debugcon and serial through it

[dense steppe]

but effort

[left orbit]

@fiery turtle you said cgroups is the way?

[fiery turtle]

well no

run qemu with debugthreads=on or whatever, grep for the one with nameVCPU/0, pin it to the allocated core with taskset or similar

thats the simplest way

[left orbit]

huhhh

-cpu debugthreads=on?

[fiery turtle]

ideally u also pin the main thread there, or allocate a separate core for it

[left orbit]

well you don't want to run the benchmark script on the same cpu

ideally qemu should get majority of the cpu time there

[fiery turtle]

-name debug-threads=on i think?

[fiery turtle]

no no

like

when u start linux, offline a CPU, or offline it via a kernel command line via isolcpus

[left orbit]

oh what the fuck

[fiery turtle]

then pin qemu there so it gets literally the entire cpu to itself

thats the fairest way

[left orbit]

honestly i dont want to go too overboard with this whole thing

considering it's gonna be running on my personal system right

[fiery turtle]

true ig

[left orbit]

yes it is a good idea to make it as fair as possible

but i don't want to get into weird isolation stuff like that

[fiery turtle]

u can still pin it to some cpu, it will just be random whether it gets a lot of time

[left orbit]

not really that weird but yeha

[fiery turtle]

it's not weird, it just excludes it from the scheduler list of cpus to schedule on

[left orbit]

well it should, assuming there isn't much going on on the system

[left orbit]

only if there was a way to do it at runtime...

[fiery turtle]

hmm

[left orbit]

echo 0 > /sys/devices/system/cpu/cpu3/online

apparently

[fiery turtle]

that will halt it i think

[left orbit]

yeah i guess

[fiery turtle]

aka u wont be able to schedule on it

[left orbit]

after using isolcpus, you can apparently just use taskset to "pin" it

[fiery turtle]

yeah thats what im saying

[left orbit]

thats nice

[fiery turtle]

it's like a guarded area

but yeah im not finding any info about isolcpus at runtime

[left orbit]

cpuset is apparently also something worth looking into

[gentle peak]

you can also make qemu pause on startup and give it infinite timeslices (aka SCHED_FIFO with highest priority) before unpausing it

[left orbit]

is that enough to guarantee maximum cpu time though?

[gentle peak]

processes with sched_fifo do not have timeslices, and if they're also in the highest priority they don't get preempted

[left orbit]

hmmm

okay

[gentle peak]

so as soon as qemu gets a timeslice it'll keep running until it blocks for whatever reason

[left orbit]

so, now, how do i do the "SCHED_FIFO" thing and highest priority thing?

[gentle peak]

though with this especially you'll want to be careful to not run it on the same cpu as the runner script, otherwise the timeout may break

[gentle peak]

sched_setscheduler

[left orbit]

i have never touched the linux scheduler soooo idk

ah

[fiery turtle]

also yeah pin your script on some other cpu lol

[gentle peak]

whatever cpu affinity you give qemu, give yourself the inverse of it

[fiery turtle]

Since i'm making the register api public i've decided to add some comments, hopefully this is as clear as possible

[left orbit]

any idea how i can unpause qemu without any input..?

[fiery turtle]

cont

[gentle peak]

monitor

[fiery turtle]

ideally make it spawn a qmp socket and talk over that

[left orbit]

true

[fiery turtle]

ideally uacpi should have tests like that

with a real qemu integration for some kernel, testing shutdown, pci hotplug, hotunplug, resource parsing, etc

for that qmp events are a must

also added this notice lol

[left orbit]

okay i got the scheduling stuff done, now i need to figure out how to properly set the affinity for qemu and the python process

idk which cpu it should be pinned to tho lol

[fiery turtle]

0?

[left orbit]

isn't that like the worst cpu you can choose though

usually most interrupts are directed there

[fiery turtle]

maybe on a hobby kernel

[left orbit]

at least on wsl cpu 0 has the most irqs

[fiery turtle]

how did u check?

[left orbit]

and cpu 22 is a strong contender for that too

irqtop

[dense steppe]

I would avoid picking the BSP, which is usually (if not always) CPU0.

also, I doubt that isolcpus= would allow you to isolate the BSP

[left orbit]

i am not doing isolcpus, but yeah bsp is not the best choice

i think the cpu to pin is pretty machine specific

[dense steppe]

indeed

[fiery turtle]

if u have /sys/kernel/debug/u should have irq stuff there, which can show u how many vectors are allocated on each cpu and stuff

[dense steppe]

if you are running WSL, the interrupt stuff probably isn't very meaningful.

like, "it's a real Linux kernel" etc... but it doesn't actually interact with the real physical hardware

[left orbit]

yeah, no

[flat badge]

In my experience (and I've done a lot of benchmarking in my career), isolcpus and pinning doesn't make a difference for single threaded workloads, provided that you don't run anything else concurrently that consumes significant amounts of cpu time

isolcpus mostly makes a difference when you want to have low latency when reacting to a device interrupt

[left orbit]

yeah this feels like hyperoptimizing something that doesn't need that much thought put into it, i think SCHED_FIFO + nice -20 will be good enough

just to make sure it gets the most cpu time as possible

[dense steppe]

yup, probably.

[fiery turtle]

yeah especially if u run it many times

[flat badge]

And pinning does make a difference for parallel applications where you have many threads doing computations at the same time

I don't think nice values make a difference for SCHED_FIFO

[left orbit]

it's so it doesn't get preempted, or something

someone said that

[dense steppe]

how does the Linux scheduler's task migrator cope with a FIFO task eating 100% CPU time? will the FIFO task move around between CPUs, or will the other tasks be kicked off from the CPU? something to consider

(for our purposes, we would prefer the latter)

[left orbit]

i think that's how SCHED_FIFO works

[flat badge]

I don't think nice affects whether you get preempted or not

[left orbit]

SCHED_FIFO: First in-first out scheduling
    SCHED_FIFO can be used only with static priorities higher than 0,
    which means that when a SCHED_FIFO thread becomes runnable, it
    will always immediately preempt any currently running SCHED_OTHER,
    SCHED_BATCH, or SCHED_IDLE thread.  SCHED_FIFO is a simple
    scheduling algorithm without time slicing.  For threads scheduled
    under the SCHED_FIFO policy, the following rules apply:

    [...]

    No other events will move a thread scheduled under the SCHED_FIFO
    policy in the wait list of runnable threads with equal static
    priority.

    A SCHED_FIFO thread runs until either it is blocked by an I/O
    request, it is preempted by a higher priority thread, or it calls
    sched_yield(2).```

[flat badge]

Also, sched_fifo processes can't get preempted

[left orbit]

it definitely does

[dense steppe]

nice might affect if/how you preempt others when unblocking

[flat badge]

Nice affects how often a thread is scheduled, not how long it is scheduled

[left orbit]

read last sentence

idk

yes it doesn't have a time slice but it can still get preempted by a higher priority thread

idk how that works i am basically braindead but yeah

[flat badge]

Yes but there are no higher priority threads if you give it the highest priority

[left orbit]

i do that with renice... so yeah

nice -20 is the highest priority

SCHED_FIFO on it's own does not change the priority

right?

as i said, idfk how that works lmao

[flat badge]

Nice is not priority

[left orbit]

hm okay

[flat badge]

Priority is sched_priority in sched_param

I personally wouldn't bother with sched_fifo either

At least not without extensive testing

As it's way easier to make a mistake than it is to do it right

For example, if qemu's IO threads run with SCHED_FIFO, this may have a significant detrimental effect on perf

[left orbit]

proxima actually runs a bit faster without SCHED_FIFO

interesting

2.3-2.4 -> 2.5M

at least with a random iso i had on my desktop lol

[dense steppe]

wait wtf why is it so slow? doesn't it have the record at like 8M or something?

[left orbit]

intel moment

anyway, pmos times out because it has a 5 second limine timeout

[median crest]

lol astral has that too

[fiery turtle]

lol the iterative namespace walk api from ACPICA that Haiku uses doesn't check if a node is temporary

they forgor to add a check 💀

[left orbit]

pmos doesn't print uacpi logs to serial

[fiery turtle]

not surprising considering linux doesnt use it

[left orbit]

WAAAAAAAAAAAAAAAA

[calm latch]

Give me 10 mins

[dense steppe]

git clone https://github.com/dbstream/davix.git
cd davix
mkdir user
echo '#define CONFIG_DEBUGCON 1' > user/config.h
echo '#define CONFIG_UACPI 1' >> user/config.h
./run --limine

assuming I didn't typo anything (I typed this on a phone) and that any reasonable gcc and binutils is accessible as x86_64-elf-*, this should just work™️, and it will generate an ISO and place it in /tmp/bootable.iso

tbh I should change my buildsystem to autodetect gcc/binutils and use the system gcc/binutils as a fallback (printing a warning ofc)

[fiery turtle]

day 0 without finding a new crazy bug in ACPICA

[left orbit]

❌ any reasonable gcc and binutils is accessible as x86_64-elf-*

[fiery turtle]

anyway i reported it to the haiku people

[dense steppe]

you can just ln -s /usr:bin/gcc /usr/local/bin/x86_64-elf-gcc and do the same for ld

that's what I use on my machine for developing lol

but effort

[left orbit]

ew

its not a big deal i dont really need isos for testing atm

[dense steppe]

and I will probably unbork it tomorrow by actually, like, parsing the kernel command line

[left orbit]

"mean": 6907766.7272727275

when running simd proxima

kinda low

am i being wsl-d

[dense steppe]

wait wtf, 6.9M with SIMD??

you are being WSL'd

[left orbit]

i absolutely am

[dense steppe]

WS'd

[left orbit]

fuck arithmetic mean

[dense steppe]

was it a math skill issue?

[left orbit]

there are multiple sample points >11M but the 6-7M samples just kill them

it is a WSL moment

unfortunately

[calm latch]

wtf

[dense steppe]

it would be interesting to have, in addition to the mean, like 10/25/75/90th percentile

[calm latch]

wsl is working very well today

[left orbit]

if you provide me with the math, sure

[dense steppe]

what did you do?

[left orbit]

as i have already noted on multiple occasions: I am Brian dead

[calm latch]

I have no idea

[dense steppe]

• store results in a list.
• sort the list.

that's literally it

[left orbit]

well i already do that

[dense steppe]

because this is usually what happens when you remove a directory that is the cwd of a bash instance

bash does weird CWD things so eg. navigating upwards (..) from a symlink works as if there was no symlink

[calm latch]

Is ns16550 interrupt level triggered?

(I'm just gonna hardcode it for now...)

Although I guess ACPI should provide that

dumb question

[dense steppe]

I think that weird things can also happen if you rename a directory that is part of the path to CWD of a bash instance

[dense steppe]

for the Nth percentile, take (N * (num_measurements-1)) / 100 and use that to index into the list.

[left orbit]

{
  "raw_measurements": [
    6094335, 6682788, 6647536, 10104182, 6362320, 6744675, 6697042, 6834269,
    6716035, 6684596, 6671675, 6658829, 6124589, 10084878, 6827346, 6770144,
    6579531, 6770440, 6673503, 6790907, 6672510, 5999169, 10136802, 9916999,
    7033683, 10015154, 6815883, 6711515, 5204374, 10137224, 6557616, 10108915,
    10094730, 6221946, 6750496, 6744088, 6668622, 6289841, 6736707, 10111073,
    10059353, 6231565, 6947189, 4575105, 6642356, 6265111, 6745609, 6702281,
    6714686, 6115824
  ],
  "filtered_measurements": [
    6094335, 6682788, 6647536, 10104182, 6362320, 6744675, 6697042, 6834269,
    6716035, 6684596, 6671675, 6658829, 6124589, 10084878, 6827346, 6770144,
    6579531, 6770440, 6673503, 6790907, 6672510, 5999169, 10136802, 9916999,
    7033683, 10015154, 6815883, 6711515, 5204374, 10137224, 6557616, 10108915,
    10094730, 6221946, 6750496, 6744088, 6668622, 6289841, 6736707, 10111073,
    10059353, 6231565, 6947189, 4575105, 6642356, 6265111, 6745609, 6702281,
    6714686, 6115824
  ],
  "lower_bound": 4237969.691588384,
  "upper_bound": 10219872.148411617,
  "mean": 7228920.92,
  "stdev": 1495475.614205808,
  "p75": 6862499.0,
  "p90": 10103236.8,
  "p95": 10122651.05,
  "p97": 10137000.34,
  "p99": 10137430.78
}

simd proxima

[dense steppe]

if num_measurements is 101, this works out quite nicely

[left orbit]

i misread 11M, wasn't actually there so that's mb

u can see how bad the variance is on WSL, damn

4.2M-10.2M

[dense steppe]

yeah

that's just fkin terrible

[calm latch]

Will it handle a bunch of text correctly?

Like if it just printf the full initialization sequence

[left orbit]

i mean yeah, why not

it just looks for the specific log from uacpi

UACPI_AVG_OPS_REGEX = re.compile(
    r"successfully loaded \d+ AML blob, (\d+) ops in (\d+)ms \(avg (\d+)/s\)"
)```

no need for all the groups but yeah

[fiery turtle]

it prints blobs if there was more than one

trolled regex

[dense steppe]

on my AMD CPU (my kernel has AMD skill issues), I usually get like ~4.6M, but I sometimes get the occasional 3M. so that's understandable.

but here, there are lots of ~6M, ~7M, ~10M, a 5M and a 4M.

[left orbit]

-    r"successfully loaded \d+ AML blob, \d+ ops in \d+ms \(avg (\d+)/s\)"
+    r"successfully loaded \d+ AML blobs?, \d+ ops in \d+ms \(avg (\d+)/s\)"

fixed

but i dont expect multiple blobs with q35

[dense steppe]

successfully loaded 1 AML blobs?

[left orbit]

ok there's some weird shit going on with the math that i dont feel like figuring out at the moment cuz im tired as fuck

but somehow python is hallucinating numbers

statistics.quantiles is returning a value that shouldn't be there, to be precise 7100247.6 for the 99th percentile while non of the values go above 7M lol

statistics is a built in python module btw ^

[dense steppe]

maybe it is because there is the 98.Xth percentile and the 99.Yth percentile but no exact 99th percentile, and thus the prev and next are combined according to some weight

[left orbit]

but none of the values went above 7M so idk where it got that from

but i will investigate after an 8h nap

[dense steppe]

perhaps it is actually 'inventing' new values by doing some stddev shit

[calm latch]

Bruh, my RISC-V driver was good enough to work as is on x86 (after I added port io instead of mmio) 💀

anyway, build as it is in dev branch

@left orbit

[calm latch]

*took me 40

[calm latch]

(this driver is asynchronous and interrupt driven for both reads and writes )

[torpid root]

oh we're testing?

[vale isle]

run it 100 times and take the median

if you have a problem in statistics that you don't know how to solve (because you know nothing about statistics just like me), median is the answer

[vale isle]

ns16550 is still ns16550 eh?

[median crest]

pick whatever is most convenient for you
its your os? pick the best score
its someone else's? pick the worst score

[strong heath]

@fiery turtle mint told me you use your own memcpy instead of the system one? and that you need to override it? what is that about

how am I supposed to do that from Ada

[loud ice]

you need to override it for good performance

in your kernel api header, you need to #define uacpi_memcpy __builtin_memcpy

(or can, at least)

[strong heath]

I dont have a kernel header

I am Ada

man thats ugly as balls

[loud ice]

you define a uacpi_libc.h header

and build with -DUACPI_OVERRIDE_LIBC

[loud ice]

^ repeat this for memset, memcmp, memmove and strlen

(or the subset that you have, anyway)

if you dont want to you dont have to

but its a pretty significant perf diff afaik

[flat badge]

Why does uacpi do that? It seems stupid

[loud ice]

so that the OS doesn't have to provide them if they don't have them i think?

the others make more sense tbh

like printf

[flat badge]

GCC can and will generate calls to memcpy even in freestanding code

[loud ice]

yes!

[flat badge]

Same for clang

[loud ice]

indeed!

just like gcc, but iirc not clang, will generate calls to popcountdi2

[strong heath]

this is actively harmful for any non C project, we are now to have C headers alongside our own ABI implementations? that is so unwieldy

[loud ice]

its a 5 line header

[flat badge]

Yes, so kernels have to provide memcpy anyway

[loud ice]

and its optional

[vast kestrel]

Specifically for the memcpy/memset/memmove it's a bit redundant tbh

Given the builtin versions already exists

[loud ice]

but yeah ^^

[mortal yoke]

memmove isn't really needed (as in calls to it aren't generated by the compilers as far as I know)

[strong heath]

its something I need to wire in my Ada build system

god knows how

[lofty dragon]

that's why i did not do it

[loud ice]

ah, makes sense

[lofty dragon]

i just didn't because i did not wanna bother lol

it was gonna be a pita so i left it as default

[strong heath]

especially for no reason

[loud ice]

tbh you can just add -Duacpi_memcpy=__builtin_memcpy to the CFLAGS i think?

[mortal yoke]

the default is not even that bad, like the score stays about the same

[vast kestrel]

There are also some str* functions I think

I mean, the default is basically a simple mem* impl

And I kinda doubt tbh that there are any huge copies being done in the code

[loud ice]

i propose that uacpi switches to this implementation of memcpy: c void memcpy(void* dst, void* src, unsigned long long size) { typedef struct { char c[size]; } fuckingwhat; *(fuckingwhat*)dst = *(fuckingwhat*)src; }

[vast kestrel]

Actually, can't the functions just be made weak?

[strong heath]

I just dont understand why this is not part of kernel provided ABI

[loud ice]

no, that's unportable

also i suspect it messes with LTO

[vast kestrel]

It shouldn't mess with lto

Assuming static linking obviously

[loud ice]

i think a lot of the performance gain is not from overriding them, but from gcc/clang knowing its memcpy?

just ignore it its not strictly speaking necessary

[strong heath]

why would you not handle this yourself internally then with some ifdefs

[loud ice]

(clang doesnt support this wonderful extension btw)

[strong heath]

as a compiler-specific optimization

[vast kestrel]

It's an optional abi, like sized frees

[strong heath]

why are optional abis done in such an uncomfortable way for non C bindings

[lofty dragon]

tbh all stuff that needs ifdefs or headers is going to be annoying to deal with in Ironclad's build system

be it this or anything else

[loud ice]

does ironclad's build system not support adding an include directory?

[vast kestrel]

Because no one came and said it was uncomfortable outside of c binding most likely

[loud ice]

or a -D cflag

[lofty dragon]

yes

it can be done

i just don't quite understand either why this is the way it is, personally, but whatever

[vast kestrel]

Overriding the header with a user header is meant as a way to more easily allow to override the functions instead of needing to have in the buildsystem -Duacpi_memcpy=..., and maybe some impls would need other kernel headers which would then need to be included as well

[lofty dragon]

like what i mean is that i don't understand what's gained by uacpi shipping its own versions of these functions by default

instead of hard relying on them

[loud ice]

it's easier if you dont care about the performance gain?

[vast kestrel]

I think just for easier build

Oh wait

They also support msvc

Idk if msvc has something like __builtin_memcpy that magically works

[loud ice]

probably not

but if you are an msvc user you deserve to suffer anyway

[vast kestrel]

Even tho that is probably fixed by just either using the builtin or using a custom prototype that the compiler expects

And still requiring the kernel to impl it

[loud ice]

i think this design choice comes from the fact that it used to contain sprintf?

[lofty dragon]

the point is that you have a prescribed kernel glue layer of like 25 functions already, adding 5 more that everyone pretty much already has sounds like a no brainer to me

[loud ice]

true

[vast kestrel]

Like specifically for the memcpy/memset/memcmp/memmove functions I think using the normal functions could work as is

There are some string functions that depends on the kernel might not exist

[loud ice]

you still need to include SOME header for memcpy/memset/etc though?

[vast kestrel]

You can just define them to be the expected versions directly

[loud ice]

you cant though

[vast kestrel]

Like have uacpi define the prototype

[loud ice]

okay how do you write the prototype?

[vast kestrel]

You can, because the compiler expects these functions and these signatures

[loud ice]

on 64bit sysv, you either write memcpy as void* memcpy(void* dst, const void* src, unsigned long size); or as void* memcpy(void* dst, const void* src, unsigned long long size);

[mortal yoke]

you use size_t

[vast kestrel]

Literally as void* memcpy(void*,void*,size_t)

That's what the compiler defines it to be

[loud ice]

does uacpi include stddef?

[vast kestrel]

Yeah

I think

[loud ice]

ah

[vast kestrel]

Maybe

[loud ice]

lol

[mortal yoke]

yes if you don't override it

[lofty dragon]

it includes freestanding headers yes

[gentle peak]

it has its own overridable version that delegates to stddef.h by default

[loud ice]

ah

okay

yeah

[vast kestrel]

Even if not there are compiler builtins for the type

[lofty dragon]

and yes i would depend on the standard prototypes already, not like uacpi_ prefixed ones

[slim panther]

if i use UACPI_OVERRIDE_LIBC, where would i need to put that header?

[vast kestrel]

Which uacpi already checks for the specific compiler

[loud ice]

they include "uacpi_libc.h" iirc

so. at the include path

[vast kestrel]

Now as for the vsnprintf, that might be much different

[loud ice]

but they are not necessarily the same as the type used in memcpy, aiui

[mortal yoke]

yeah

[lofty dragon]

i wouldn't depend on host for vsnprintf

[loud ice]

yeah no

i agree

[lofty dragon]

for several other reasons

[loud ice]

especially because its (partially) exposed to aml

[vast kestrel]

Yeah it has its own vsnprintf, but you can override it the same way

[lofty dragon]

mainly because it's not perf sensitive where it would even matter

[loud ice]

so it needs to be exactly accurate for compat

[gentle peak]

yeah proxima for example uses non standard printf format specs

[vast kestrel]

https://github.com/uACPI/uACPI/blob/misc-assortment/include/uacpi/platform/libc.h

[strong heath]

memcpy is pretty much C ABI with how compilers work nowadays

[vast kestrel]

These are the overridable functions

[strong heath]

defining it yourself is dumb when you are meant to be embedded

its just asking for messes

just assume they are present, and use them, done

extern memcpy(whatever)

solved the issue

[vast kestrel]

Worst case for GCC/clang use the builtin for msvc use whatever msvc specifically wants

[lofty dragon]

that's what flanterm does

that's what i am proposing

[strong heath]

and flanterm does well

that is the easiest, most powerful, least pain in the ass thing you can do

everything else is just bad design and working around things outside the real world

point me to an implementation hosting uacpi that doesnt have memcpy

[lofty dragon]

there isn't gonna be one

[strong heath]

uacpi is asking for allocators, for interrupt and event handling, and for memory mapping, but asking for memcpy is too much

[lofty dragon]

and if you wanna do the __builtin_memcpy trick btw you can still do it wholly inside uACPI with ifdefs

for compilers that support it

at which point the dependency is implicit

[gentle peak]

note that in some cases __builtin_memcpy instead of plain memcpy degrades performance

[lofty dragon]

well idk, that's something for infy to figure out when to use lmao

[vast kestrel]

I think if you mark the real mem* as non-inline it solved the problem

It just requires you to use the __builtin everywhere

[gentle peak]

on -O3 LTO clang with memcpy implemented in C, using the prototype instead of builtin increased proxima's score by like 1M iirc

[strong heath]

I dont even ncessarily care about the performance, which I am sure I will get a massive boost of

this is just bad design

not a single time that the builtin uacpi memcpys are used its intended behaviour

not a single system that supports uacpi doesnt have a memcpy

its just working around ghost problems that dont exist and adding complexity for no reason

[lofty dragon]

it's fine if he wants to keep the option but it should probably be opt-in, not out

imho

like if he wants to use it for unit tests or something

where it may make sense, idk

[loud ice]

huh

[dense steppe]

strange because for me, replacing the builtin with a prototype makes like zero difference

[loud ice]

are you using LTO?

[gentle peak]

GCC doesn't exhibit this behavior last time I tried

[dense steppe]

although my memcpy is literally just

• shuffle arguments
• rep movsb
• ret

[dense steppe]

no, just plain -O2

[strong heath]

that would make much more sense

[gentle peak]

and if you're not using LTO and/or not implementing memcpy in C the __builtin is much better

[loud ice]

then you wont exhibit this behavior anyway i think

[lofty dragon]

like code inside uACPI could realistically cause a dependency on memcpy

like, directly, from the compiler

at that point i don't see why this whole circus is even a thing

[gentle peak]

iirc infy tries to make sure that doesn't happen

[lofty dragon]

tries means nothing

[loud ice]

just implement uacpi_memcpy like this: c void uacpi_memcpy(void* dst, void* src, unsigned long long size) { typedef struct { char noThisIsNotSupportedByClang[size]; } fuckingwhat; *(fuckingwhat*)dst = *(fuckingwhat*)src; }

[loud ice]

wtf does that mean even

[lofty dragon]

he can try now, but a future version may make it happen

[loud ice]

LLVM can insert a memcpy wherever it wants

[lofty dragon]

or a different architecture

[loud ice]

and you cannot stop that

[lofty dragon]

or whatever

yeah

[mortal yoke]

you can reduce it tho

[lofty dragon]

not a valid argument

[loud ice]

why though

[mortal yoke]

yeah idk for memcpy specifically it doesn't make that much sense

[lofty dragon]

you either have or not have a dependency, it's not a spectrum

reducing it while still depending on it means nothing

by using the compiler you always implicitly depend on it

[gentle peak]

just like how gcc and clang allow themselves to use libgcc/compiler-rt whenever they want, but it's still completely viable to write kernels in a way that doesn't use libgcc

[calm latch]

Isn't rep movsb kinda bad for performance most of the time?

[lofty dragon]

technically it isn't viable

[mortal yoke]

its bad for small copies

its something doable tho

like you can avoid popcnt and whatever other things like that

[gentle peak]

linux does it so compilers are practically guaranteed to stay sane in their libgcc uses

[calm latch]

Like I think just manual loop unrolling is fast(er)

[gentle peak]

like sure there's no real guarantee

[lofty dragon]

idk what you are talking about

but

[gentle peak]

but no GCC or clang version is gonna get released that cannot build linux

[lofty dragon]

on non-x86-64 it is absolutely not viable

[gentle peak]

and linux doesn't use libgcc

[lofty dragon]

hey

let me try to express myself

one second

Linux does things like shipping its own freestanding headers so i am not surprised if it also ships its own libgcc compat routines

that's a different thing

[loud ice]

uacpi literally calls libgcc though

for popcount

[lofty dragon]

(this is something that the limine-c-template does too for example)

[loud ice]

(with gcc at least)

[gentle peak]

linux doesn't provide libgcc, and uacpi doesn't use it anymore

[lofty dragon]

are you sure linux doesn't provide libgcc routines at all?

[gentle peak]

yep

[dense steppe]

idkf, maybe it is.

will try it out later today

[gentle peak]

they have a separate macro for 64 bit division f.ex

[lofty dragon]

well that sounds like them taking the stupid route

[loud ice]

you cannot, however, stop gcc from calling its own 64 bit division

[lofty dragon]

something like cc-runtime is painless to use

Linux could use it totally fine

or compiler-rt

[gentle peak]

and when I worked on integrating uacpi into linux for a bit I encountered the popcount stuff

[calm latch]

like the phd memcpy is the way it is for a reason

[gentle peak]

you can, as evidenced by the fact that linux does it

[mortal yoke]

eh there isn't a huge diff between it and rep movsb

[loud ice]

no, what they do is they TRY

[mortal yoke]

with builtin memcpy falling back to that for larger copies

[loud ice]

but relying on that is unportable, version dependent, and can break on any update

[gentle peak]

you can't get a documented guarantee that it'll never be called by a future compiler, but you can get a practical guarantee because no future compiler will get released in a state where it cannot compile linux

[loud ice]

also this isnt a strong guarantee

[mortal yoke]

it doesn't matter lol

[loud ice]

linux could be implemented in a slightly different way

that would make it not hit it

and you would

[lofty dragon]

not depending on mem* is not sane on gcc/clang

[loud ice]

also that

[lofty dragon]

just like not depending on libgcc or alternatives is

[gentle peak]

oh yeah mem* is a different story

[loud ice]

i mean... https://godbolt.org/z/34sY86v1r

yeah

you cant not depend on memcpy

and memset

you also cant really not depend on the rest

[fiery turtle]

That was removed a very long time ago

[loud ice]

ah

so now it doesnt, on current gcc/clang

[dense steppe]

fucking what?
that's a legal struct definition in C?

[loud ice]

yes

its not supported by clang though

[dense steppe]

typedef struct { char c[size]; } y; where size is a run-time value

[loud ice]

for hopefully obvious reasons

[fiery turtle]

As for the default libc impl, since it expects a few uncommon c functions, or for example vsnprintf, which is critical for correct aml, it seemed strange to exclude some just because “but memcpy is so common everyone has it lol”

[dense steppe]

ah so it's a gcc extension

[loud ice]

no its not

its standard

[calm latch]

Not obvious, I would have used it for my IPC memes

[loud ice]

its an optional part of the standard, though

[loud ice]

you shouldn''t

[dense steppe]

alright, I'm considering switching to clang now

[loud ice]

VLAs are bad

[calm latch]

But instead I just call alloca

[mortal yoke]

[loud ice]

please dont

just dont

[fiery turtle]

Without the default libc impl it was insanely annoying to port because they had to be propagated via some header anyway, like uacpi cannot just include <string.h> and other headers blindly because they aren't freestanding

[calm latch]

(Though malloc and free in the same call context get optimized away by the compilers anyway)

[loud ice]

only sometimes

but yeah

[dense steppe]

new and delete are nowadays common to optimize in C++ compilers

[loud ice]

yeah same thing as malloc/free

[dense steppe]

in some cases, usage of runtime-allocated memory by containers such as std::vector<int> can even be optimized away

it's awesome

and constexpr is awesome too lol

[loud ice]

yeah

[calm latch]

I think new gets optimized to malloc, which gets optimized away?

[loud ice]

no they are specially known to the compiler on their own

[calm latch]

[dense steppe]

yeah

[calm latch]

But like C++ optimizations are insane sometimes

[loud ice]

you can make any other function work like that too

[dense steppe]

and I don't think that they are changed to calls to malloc

because operator new is its own thing etc. etc.

and exceptions, obviously. exceptions

[loud ice]

oh yeah that too

[strong heath]

the prototype is standard, you can just extern it out

I understand your argument for vsnprintf and stuff, but for memcpy its silly

it just is

some functions should be excluded out of the define everything yourself mantra out of commoness and utility

[fiery turtle]

So I should blindly extern stuff by default, but only for some because they're kinda common, and compilers might call them anyway, but not for others because idk

[lofty dragon]

yes

of course if you put it that way it is easier to make it sound like a coocoo idea

[fiery turtle]

uacpis default memcpy outperformed managarms PhD memcpy on lto O3

[lofty dragon]

anything put in clown terms will sound like a circus

[fiery turtle]

Are we talking about just the memcpy

Or something else too

[lofty dragon]

the memcpy family

[median crest]

cant you just make the uacpi memcpy a weak function or something if youre not happy removing it

[mortal yoke]

weak functions are funky

when compiled to static libraries

[fiery turtle]

MSVC, LTO builds, static libraries

[lofty dragon]

so like memcpy, memmove, memset, memcmp

[median crest]

bruh

[lofty dragon]

those 4 are required by gcc and clang to exist

[fiery turtle]

Perhaps

[loud ice]

perhaps definitely lol

[mortal yoke]

I don't think I have seen a single memmove call ever tho

its mostly just memset/memcpy

[lofty dragon]

i am just saying

[loud ice]

i think i might have seen it in rust generated code? idk though

[fiery turtle]

Why

[lofty dragon]

because everyone has them

[loud ice]

they are definitely required by clang and gcc, because they always emit calls to them

and you cannot stop that

[lofty dragon]

given 99.9% of people use gcc/clang they will have them, also you already depend on them implicitly on those compilers

[fiery turtle]

True

[calm latch]

but what about msvc

[lofty dragon]

and even people not using gcc/clang, frankly, will have them

[fiery turtle]

But its not true for all mem stuff, literally no code in uacpi out 30k lines generates implicit memcpy calls

[lofty dragon]

like what OS kernel does not have those basic functions that requiring them is absurd?

[fiery turtle]

They might have their own versions of them

[lofty dragon]

you have no way of guaranteeing this

on gcc/clang

[flat badge]

as soon as you do *a = *b where a and b are structs, gcc will generate implicit calls

if the structs are large enough

also, GCC will convert loops to memcpy

[fiery turtle]

Yes but its anecdotal evidence not many people will have those

[loud ice]

or if the structs have a variable sized member

[fiery turtle]

Referenced implicitly

[loud ice]

WHA

[lofty dragon]

anecdotal evidence != does not depend on...

[loud ice]

oh

you will always have memcpy calls?

[fiery turtle]

Never said that tho

[lofty dragon]

i am stressing the point

[fiery turtle]

Im just saying that the cases of implicit memcpy references dont magically appear out of nowhere

[lofty dragon]

of course not

[fiery turtle]

They're caused by specific code, e.g. large struct copies etc

[lofty dragon]

but you are also not the compiler

a future version may decide that code that rn does not generate those calls, will

[dense steppe]

ucc when?

[lofty dragon]

and it would be legal, because they are already stating they depend on those 4 functions

[loud ice]

the full list of functions that LLVM will call is here: https://paste.sr.ht/~pitust/5642cb3fb4fb3627069670cd5ec39197ce085d33

or may call, at least

[kind mantle]

Lily-CC mode that does memcpy for everything >4 bytes?

[fiery turtle]

Like I agree in general

I dont wanna hear about uacpi bugs because of shitty libc beginners make

[lofty dragon]

for the record it's no mystery, it's very clearly documented in both gcc and clang manuals

[fiery turtle]

I dont think its such a problem to have a built-in memcpy

[loud ice]

the full list isnt that clear i think?

but yea

[lofty dragon]

really? that's a bad reasoning. there are a million other ways you can screw up wiring up uACPI and what you're thinking of is a bad memcpy?

if someone can't do a memcpy they should not touch uACPI with a 10ft pole

jesus christ

[fiery turtle]

I've seen some horrors that people made when uacpi required every libc dependency from the host

[strong heath]

yeah like lmfao

the beginners you complain will fuck up stuff about already do with the rest of things

[loud ice]

clang will memmove if:

• you use memmove, __builtin_memmove, __builtin_memmove_chk
• you use bcopy or __builtin_bcopy

[strong heath]

this is just a bad reason

[fiery turtle]

But your reasons are: its common, and your build system cant handle headers well

Those aren't that great either

[lofty dragon]

i am saying it's a saner default

not that you should get rid of the option

[fiery turtle]

True I guess

[dense steppe]

in my opinion, having uACPI define its own libc functions by default is good because

1. there might be bugs in the kernel's definitions.
2. the kernel might call them something else, like RtlCopyMemory, or just not at all have them.
   a counterpoint to 1) is that it's a kernel skill issue and the kernel should fix it. or that the uACPI libc functions might compile to jmp memcpy etc. anyways (except this doesn't happen if -ffreestanding afaik)

[lofty dragon]

it's common, it's what most normal sane in the head people want, every has those functions, yes, dealing with defines and headers is annoying in other non-make/cmake/etc build systems

and you can still have the old behaviour as opt-in rather than opt-out

[strong heath]

2. is not a thing for the record, memcpy is required by all language runtimes existing out there, and modern C compilers straight up require them to exist

[loud ice]

any good build system would make it easy to add an include path?

[kind mantle]

I've found that only the most naive implementations of stuff like memset and memcpy will compile into jumps on GCC

[flat badge]

imho "API surface minimalism" is not a good goal