07:09:39 XanClic joined the channel
07:17:19 xq: DOOOOOOM
07:17:22 xq: moin LittleFox
07:41:52 kevin joined the channel
10:54:30 LittleFox: hai xq
10:55:20 xq: herzlichen glühstrumpf zum doom nochmal :)
11:04:09 LittleFox: danke x)
11:04:30 LittleFox: das achievement da war aber eigentlich tatsächlich nicht doom sondern PAT, wodurch doom nun schnell ist x)
11:04:36 LittleFox: doom geht schon ne woche oder so länger :D
11:04:38 xq: PAT?
11:06:20 LittleFox: page attribute(?) table(??)
11:06:31 LittleFox: jedenfalls kann ich nun dem framebuffer mit writecombine nutzen
11:06:41 LittleFox: und habe spielbares doom statt 0.33fps oder so
11:07:03 LittleFox: "Page-Attribute Table"
11:07:09 LittleFox: auf den bindestrich bin ich ne gekommen ¯\_(ツ)_/¯
11:08:17 xq: ah, was sagt das genau?
11:09:02 LittleFox: kannst damit an einer page definieren welchen caching modus sie hat
11:09:25 LittleFox: also ursprünglich konntest du pro page writethrough setzen (und damit writeback deaktivieren) oder uncachable setzen
11:09:45 LittleFox: mit PAT werden aus den beiden bits und dem huge bit (auf unterster ebene) ein 3 bit index in die PAT
11:10:17 LittleFox: in der PAT hast du 8 einträge für verschiedene caching modi, teilweise per MTRRs überschreibbar, teilweise nicht
11:10:42 LittleFox: write combine steht leider nicht standardmäßig mit drin, also musst du als erstes die PAT anpassen und dann musst du die pages halt auch entsprechend setzen
11:10:51 xq: ah, cool
11:11:06 xq: writecombine heißt? ich darf writes zusammenfassen, aber beim readback muss ich durch den cache lesen?
11:11:46 LittleFox: writeback heißt die cpu darf writes beliebig zusammenfassen und muss nicht jedes write einzeln auf den bus werfen
11:11:53 LittleFox: für MMIO dinge wie framebuffer durchaus wichtig ^^
11:12:24 xq: ahjo
11:12:27 LittleFox: für andere MMIO dinge will eins das aber eher nicht, weil du halt nicht weißt wann dein write am gerät ankommt ^^
11:12:36 xq: also, depends strongly on device
11:12:40 LittleFox: jup
11:12:48 xq: Framebuffer ist ja nur MMM
11:12:56 xq: :D
11:13:00 LittleFox: *auge zuckt*
11:13:02 LittleFox: xD
11:13:06 xq: Memory Mapped Memory :D
11:13:10 LittleFox: ja schon klar
11:14:05 LittleFox: soo commit gepusht: "LLVM update"
11:14:08 LittleFox: mein armer server
11:14:48 LittleFox: (der das ja jetzt bauen muss)
11:14:55 xq: oh no
11:14:58 xq: auf 12.0?
11:15:09 xq: ich frag mich grade, wie ich hier mein Meta-UI-System designe…
11:15:10 LittleFox: lol nope
11:15:11 LittleFox: edge
11:15:16 LittleFox: LF OS hat edge
11:15:23 xq: ouha
11:15:34 xq: also LF OS balf auf Amiga500? :D
11:15:37 LittleFox: muss viel zu oft dran rum patchen und hab manchmal patches für upstream xD
11:15:43 LittleFox: huh :D
11:15:51 xq: 68k-Backend kommt in LLVM 13
11:15:56 xq: (also müsste das in edge drin sein)
11:15:56 LittleFox: (inzwischen 2 commits in libc++)
11:15:59 LittleFox: ah
11:16:00 xq: oh, sehr fein!
11:16:01 LittleFox: x)
11:16:09 LittleFox: libc++ geht nun wieder mit newlib xD
11:16:20 xq: ich freu mich sehr darüber (also 68k-Backend)
11:16:24 LittleFox: ^^
11:16:29 xq: weil bald Amiga-Demo mit Zig *grins*
11:18:42 xq: (btw, wtf @ llvm release mode)
11:18:55 xq: 12.0.0 wurde mit known blocking bugs released
11:18:57 LittleFox: einfach keine releases nutzen
11:20:19 xq: hrhr
11:20:46 LittleFox: hm scheinbar bissl was ccache-nutzbar ^^
11:20:57 kevin: LittleFox: Wie machst du denn deine Writes? Eigentlich wenn man komplette Framebuffer richtig kopiert, sollte WC nichts bringen.
11:21:09 kevin: Wenn man natürlich byteweise ankommt, dann schon
11:21:23 LittleFox: ich hab ein memcpy, das ist mit -O3 auch hübsch optimiert
11:21:36 kevin: Und es bringt dir trotzdem was?
11:21:38 LittleFox: aber 16 byte auf einmal vs cacheline auf einmal ist ja nochmal unterschied
11:21:45 LittleFox: ja, wie gesagt von 0.33 fps oder so auf spielbar ^^
11:22:00 LittleFox: (keine ahnung obs nun cacheline ist)
11:22:19 LittleFox: kann dir gerne nen build mit und ohne PAT geben ^^
11:22:20 kevin: Hm, als ich das mal probiert hatte, hat es mir gar nichts gebracht. Vielleicht hab ich's auch falsch gemacht...
11:22:46 kevin: Aber ich meine auf osdev.org haben sie auch gesagt, dass es eigentlich nichts bringen darf, wenn das memcpy gescheit arbeitet
11:23:36 LittleFox: alle OS mit schnellem framebuffer machen per PAT oder MTRR WC an
11:23:40 LittleFox: ^^
11:23:44 kevin: Jo, wird schon Cacheline sein. Was sind denn das normal aktuell? 64 Bytes oder so?
11:24:30 LittleFox: uff keine ahnung tatsächlich
11:24:47 kevin: Ich glaub, Doom auf tyndur hab ich noch gar nicht auf echter Hardware probiert
11:24:57 kevin: Aber andere Sachen sind eigentlich ganz brauchbar gelaufen
11:25:07 kevin: Supertux und so
11:25:10 LittleFox: oh sind extra buffer
11:25:33 LittleFox: gibt "line fill buffer", werden wohl genutzt um cache lines zu füllen und bei intel auch für write combine
11:25:45 LittleFox: ach ne
11:25:53 LittleFox: die enthalten den inhalt einer cache line + metadaten
11:26:03 LittleFox: hm
11:26:05 LittleFox: whatever
11:26:05 LittleFox: https://stackoverflow.com/a/49961612/2537210
11:26:07 LittleFox: lest selbst xD
11:26:43 XanClic: 64 Bytes bekommt man doch mit einem AVX-512-vmovaps hin :)
11:26:46 LittleFox: größe des framebuffers könnte auch sehr relevant sein
11:26:59 LittleFox: hm AVX-512 kann ich aber ne voraussetzen, oder?
11:27:05 XanClic: Eher nicht, nein
11:27:10 LittleFox: also, mache -O3 und amd64, also SSE hab ich garantiert ^^
11:27:33 XanClic: Auf týndur würds noch komplizierter, ich glaube, da werden nicht mal die FP-Register beim Taskswitch gesichert
11:27:42 XanClic: wäre also schade, wenn memcpy() SSE benutzt
11:28:06 LittleFox: bei LF OS auch noch nicht (:
11:28:06 LittleFox: xD
11:28:11 XanClic: Ach so. *g*
11:28:16 LittleFox: deswegen crasht doom irgendwann dann doch
11:28:16 LittleFox: :D
11:28:19 LittleFox: also
11:28:21 LittleFox: vermute deswegen
11:28:31 LittleFox: dauert unterschiedlich lange und bis dahin läufts gut und das würde sinn machen
11:28:34 XanClic: Also die gleiche Lage
11:28:43 XanClic: týndur schaltet SSE ja schon auch an
11:29:00 XanClic: Aber wer lässt schon mehrere Prozesse gleichzeitig Dinge tun
11:29:59 XanClic: > __asm__ __volatile__ ("fxsave %0" :: "m"(*last_fpu_sse_user->arch.fxsave));
11:30:05 XanClic: Endlich ein Punkt für µxoµcota
11:30:35 LittleFox: aber das will eins doch nur machen wenn der prozess die fpu nutzte
11:30:46 XanClic: Ach, ich darf da nicht rein gucken. Das juckt zu sehr.
11:30:49 LittleFox: also, fpu abschalten, auf exception warten, flag setzen, fpu einschalten und weiter :o)
11:31:00 XanClic: Da denkt man doch gleich wieder „so ein OS, das wär mal wieder was“
11:31:22 XanClic: LittleFox, ja, deshalb last_fpu_sse_user
11:32:27 LittleFox: ah
11:33:01 LittleFox: bevor ich das mit der fpu fixe muss ich mal schauen wer mir random den stack unaligned
11:33:25 LittleFox: damits mit -O3 läuft brauche ich aktuell -mstackrealign
11:37:17 XanClic: Jetzt verstehe ich
11:37:23 XanClic: Man muss gar nicht die FPU abschalten
11:37:37 XanClic: Es gibt da dieses praktisch CR0.TS-Flag, das ist genau dafür da
11:37:43 XanClic: *praktische
11:38:04 XanClic: Und ich dachte, das wäre nur zufällig im Code und hätte nix mit FPU/SSE zu tun
11:39:00 LittleFox: uuuh
11:39:01 LittleFox: nice
11:40:05 LittleFox: hm kann das ja mal einschalten, dann weiß ich zumindest obs wirklich daran liegt ^^
11:42:04 xq: LittleFox: du meintest, du hast dir mal Rust angeschaut?
11:42:31 LittleFox: 2 oder 3 mal kurz drauf geschaut und wollte es lernen
11:42:47 xq: ah
11:42:51 LittleFox: aber schnell in "du brauchst diese magischen kommentare damits überhaupt geht" bereichen gelandet
11:43:01 LittleFox: und iwie fühlte sich das instabil und "alpha" an x)
11:43:13 LittleFox: aber werde mal schauen ob ich nen multiboot2 loader für LF OS in rust gebaut bekomme
11:43:30 xq: viel glück :)
11:43:51 xq: mir persönlich war das alles zu viel magie dafür, dass es eine native sprache ist
11:43:58 xq: und zu viele allokationen /o\
11:44:10 XanClic: Als ich mirs zuletzt für OS-Dev angesehen hatte, wars auch noch ziemlich furchtbar
11:44:18 LittleFox: ich schreib auch C++ mit templates, also ich mag magie
11:44:29 XanClic: Aber als ich für týndur den ersten Minitest angefangen hatte, war das eigentlich nicht so schlimm
11:44:33 xq: LittleFox: ich meine eher sowas wie "wir verlassen uns auf compileroptimierungen"
11:44:34 XanClic: Also vielleicht ist irgendwas besser geworden
11:44:47 XanClic: also der Minitest ohne irgendwelche Bibliotheken
11:44:50 xq: aber ich finds halt (mittlerweile) echt schlimm, zu sagen: "jo, allocations failen nicht"
11:44:59 LittleFox: ja für lowlevel wars iwie seltsam damals als ich da schaute
11:46:00 LittleFox: C++ template magic, anyone? :D
11:46:01 LittleFox: https://praios.lf-net.org/littlefox/lf-os_amd64/-/blob/20-9p-implementation/src/userspace/lib9p/lib/message.h#L75
11:46:27 LittleFox: https://praios.lf-net.org/littlefox/lf-os_amd64/-/blob/20-9p-implementation/src/userspace/lib9p/lib/wireutils.h#L38
11:47:24 xq: LittleFox: ich empfehle dir, mal sowohl Rust als auch Zig anzugucken
11:47:32 xq: mit letzterem macht OS-Dev sehr viel Spaß :)
11:47:32 LittleFox: Zig war seltsam
11:47:38 xq: wann hast du draufgeguckt?
11:47:44 xq: da gabs mal eine zeit, wo alles komisch war :D
11:47:47 LittleFox: das war so komisches magie aber dennoch nicht besser als C unterm strich xD
11:47:54 LittleFox: also die paar dinge die ich von dir gesehen hab
11:48:42 LittleFox: if((cpu->rip & 0x0000800000000000) == 0)
11:48:49 LittleFox: die 8 geht so schön unter in den ganze 0en
11:49:08 xq: naja, du hast halt im vergleich zu C: vernünftige pointertypen, vernünftige codemagie ("templates sind kacke, lass uns Zig schreibe), error handling, ne standard library, die auch freestanding geht
11:49:19 xq: aber halt manuelles speichermanagement
11:49:35 LittleFox: sobald da eh manuelles speichermanagement ist kann ich auch einfach c++ schreiben
11:49:42 xq: ieh! :D
11:49:51 xq: aber C++ ist kacke :D
11:50:03 LittleFox: nope
11:50:10 LittleFox: wenn du das findest hast du einfach noch nie gutes C++ gesehen
11:50:14 LittleFox: (die links sind kein gutes C++)
11:50:43 LittleFox: und "X und Y sind kacke, Z ist viel besser" ist eh nicht das gelbe vom ei :P
11:50:52 xq: ^^
11:50:59 xq: ich bin in C++ relativ fit
11:51:22 xq: aber C++ ist inherently flawed im vergleich zu Rust oder Zig, weil die Defaults halt relativ scheiße sind
11:51:37 xq: und man für sane defaults überall ein opt-in braucht
11:53:32 xq: auch wenn ich bei zig dem "mut by default" nicht zustimme
11:54:23 LittleFox: du kannst halt in C++ fit sein und trotzdem fast alles mit new machen
11:54:51 xq: stimmt
11:55:01 xq: mein code hatte am ende nur noch sehr selten new
11:55:05 LittleFox: oki
11:55:06 xq: wenn überhaupt
11:55:13 xq: vector statt arrays, falls notwendig
11:55:25 xq: wenig allocations => code schneller
11:55:35 LittleFox: jup
11:55:39 LittleFox: und weniger kaputt
11:55:48 xq: was halt schön ist: zig hat explizite allokatoren by default
11:55:54 LittleFox: je weniger speichermanagement manuell gemacht wird desto weniger kann falsch sein
11:56:02 xq: ich hab grade einfach nen icon rendering, was statt "crashen" einfach nicht weiterrendert
11:56:21 xq: "je weniger speicher gemanaged wird, desto weniger kann falsch sein" ist auch gut :)
11:56:46 LittleFox: hm, 20 1byte mallocs() gehen genau so oft schief wie 20 10byte mallocs() :P
11:56:56 LittleFox: malloc()s x)
11:57:17 xq: so meinte ich das nicht
11:57:23 xq: 20 mallocs gehen öfter schief als 1
11:57:34 xq: was mir in c++ fehlt ist nen vernünftiges allocator interface
11:58:02 LittleFox: was brauchts mehr als "ist member der klasse und liegt da drin"? :D
11:58:10 LittleFox: also, ohne spaß, was meinst du?
11:58:26 xq: C++-Allokatoren sind anstrengend
11:58:33 xq: eben auch, weil "nondefault"
11:58:52 xq: schnapp dir eine C++Library und du musst erst mal die hälfte umbauen, weil niemand allokatoren verwendet (mir eingeschlossen)
11:58:56 xq: weil es nicht idiomatisch ist
12:06:47 xq: brb
12:12:51 LittleFox: birb
12:27:21 XanClic: https://git.xanclic.moe/XanClic/bare-rust
12:27:28 XanClic: das hat jetzt länger gedauert, als ich gedacht hätte
12:27:41 XanClic: aus irgendeinem Grund hat ld mein -e main ignoriert und einfach .text wegoptimiert
12:27:55 LittleFox: wer braucht schon programmcode in der binary
12:28:08 XanClic: ist eh nur buggy, stimmt
12:28:11 XanClic: jedenfalls denk ich nach der Erfahrung, dass es besser wäre, sich eine Bibliothek zu kompilieren, die man dann gegen einen C-Stub linkt
12:28:30 XanClic: gut, man kanns auch umgekehrt machen, mit der cc-Crate
12:28:57 XanClic: einfach in build.rs den C-Stub bauen, der den Entrypoint enthält, und den mit rein linken lassen
12:29:39 XanClic: ach ja, cargo build --target ./i686-unknown-none-elf.json -Zbuild-std=core
12:30:49 XanClic: Es gibt auch schon x86_64-unknown-uefi als Standardtarget, das klingt auch interessant, aber na ja
12:32:40 LittleFox: hm will mir eigentlich kein großes build tool ans bein nageln, bau mir glaube bissl was in mein cmake rein um rustc aufzurufen
12:32:40 LittleFox: xD
12:33:13 LittleFox:
12:33:13 LittleFox:
12:33:21 LittleFox: mein armer laptop erst der das ja auch bauen muss x
12:33:24 LittleFox: xD
12:33:51 XanClic: dachte ich auch, aber so schlimm scheint Cargo ja echt nicht zu sein
12:34:48 XanClic: meine Laptops sind auf jeden Fall leistungsfähiger als mein Server
12:34:52 XanClic: weiß noch, gitlab auf dem Server war nix gut
12:35:49 XanClic: also mein erster Versuch war damals glaub ich direkt rustc, aber das hat nicht funktioniert
12:36:02 XanClic: das jetzt mit cargo -Zbuild-std=core schon
12:36:17 XanClic: kann man jetzt draus machen, was man will
12:43:43 LittleFox: naja ich hab halt mein cmake system schon da
12:43:48 LittleFox: hm
12:43:57 LittleFox: also klar kann ich cmake auch cargo aufrufen lassen
12:43:59 LittleFox: aber.. hm
12:44:13 LittleFox: rustc --emit obj klingt sauberer?
12:44:22 LittleFox: also, ähnlicher zu allem bestehenden
12:44:38 LittleFox: und llvm-bc wäre halt auch ne variante x)
12:45:05 LittleFox: und server hat übrigens 4 kerne, 8 threads. laptop 2 kerne und 4 threads x)
12:46:35 LittleFox: der server ist da also schon besser dran
12:49:59 kevin: XanClic: Ist das das Minimum, das man braucht, um ohne Standardbibliothek zu bauen? Oder was genau hast du da versucht?
12:50:04 XanClic: kevin, ja
12:50:28 kevin: Das heißt, da noch einen Multibootheader ran und es ist ein Kernel
12:50:30 XanClic: da kommt was raus, was ein bisschen was mit dem Stack macht (versucht vermutlich, an argv zu kommen) und dann den Entrypoint aufruft
12:50:33 XanClic: Ja
12:50:41 XanClic: Eigentlich schon
12:51:16 XanClic: weiß nicht, ob das mit CONST in Rust geht, müsste man ausprobieren
12:51:34 XanClic: wenn man das in C definiert, könnte man auch gleich den Entrypoint in C machen, dachte ich, wäre irgendwie sauberer
12:51:42 XanClic: da kann man dann noch was auf den Stack legen, damit das nicht so kaputt ist da
12:51:48 kevin: Naja, mit C hab ich das auch in einer separaten Assemblerdatei, das fände ich nicht schlimm
12:51:58 XanClic: ach so, ich hatte das immer in C
12:52:08 XanClic: Mit __attribute__((section(".multiboot")))
12:52:14 kevin: Jo, geht natürlich auch
12:52:50 kevin: Theoretisch sind drei Integer sogar klein genug, dass du sie im Linkerscript haben könntest *g*
12:54:06 kevin: Bei Rust hatte ich bisher den Eindruck, dass alles was global ist, eklig wird. Aber ich glaube, das liegt in erster Linie daran, dass es nicht nur definieren, sondern auch noch benutzen wollte...
12:55:14 XanClic: ja
12:55:15 XanClic: definieren geht
12:55:24 XanClic: wie hab ich noch gleich errno gemacht…
12:55:50 XanClic: https://git.xanclic.moe/XanClic/lbuilds/src/branch/rust-next/patches/rust-libc/0001-Ein-bisschen-t-ndur-Support.patch#L473
12:55:51 XanClic: :)
12:56:59 kevin: Jo, wird halt unsafe
12:57:32 kevin: Ohne unsafe kommt man an eine static-mut-Variable gar nicht ran, oder?
12:57:40 XanClic: denke mal nicht
12:57:55 XanClic: weiß nur noch, dass das normal richtig eklig ist, auch mit unsafe
12:58:01 XanClic: mit den Pointern ist ja eigentlich gar nicht mal so eklig
12:59:29 kevin: Ich finde es halt schade, dass sich das unsafe dann komplett durchzieht
12:59:37 kevin: Aber wahrscheinlich ist errno halt einfach eine dumme Idee gewesen
13:01:28 kevin: Hm, und normal ist errno threadlokal, oder?
13:02:30 XanClic: ja
13:02:32 XanClic: bei uns halt nicht
13:02:40 XanClic: Na ja, irgendwann hört man mit dem unsafe natürlich auf
13:02:54 XanClic: Und sagt „das ist jetzt safe, weil…“
13:03:19 XanClic: Und soweit ich weiß, kann man auf const-Variablen R/W zugreifen, wenn die von einem Lock geschützt sind
13:03:22 kevin: Ich meinte jetzt speziell in dem Patch
13:03:27 XanClic: ach so
13:03:34 XanClic: Na ja, das sind alles libc-Funktionen, deshalb sind die alle unsafe
13:03:42 XanClic: Wird von den Callern auch so erwartet
13:03:50 XanClic: Hätte die alle safe machen können, aber warum
13:03:50 kevin: Die nehmen wahrscheinlich sowieso alle Pointer
13:04:05 XanClic: (eigentlich?) alle Funktionen aus libc:: sind unsafe
13:04:58 kevin: XanClic: const wäre dann ja sowieso die Mutex (oder so) und nicht ihr Inhalt?
13:05:49 kevin: Mich hat da dann nur immer gestört, wie viele Mutexe und Zeug ich verbaut habe, obwohl ich genau weiß, dass es nur einen Thread gibt...
13:06:32 kevin: Aber ich bin ja eh noch in der Phase, in der ich jedesmal mit dem Compiler kämpfe, wenn ich irgendwas tun will
13:07:53 kevin: Hm, ich könnte ja den nächsten Day of Learning mal für einen Rust-Kernel benutzen
13:17:36 XanClic: kevin, irgendwie so, ist dann halt unsafe drin
13:18:35 kevin: In der Implementierung der Mutex natürlich schon, aber im externen Interface nicht
13:18:43 XanClic: ja
13:19:16 kevin: Ich glaub, ich hab sogar mal in den Mutexcode reingeschaut, weil mich irgendwas verwirrt hat
13:19:52 kevin: Wenn es nicht irgendwas ähnliches anderes war
13:48:30 kevin joined the channel
20:40:19 Paddy joined the channel