channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=11&d=5
03:40:00 <devcpu> hey guys, i am trying to google the term "forward progress guarantee", but i get weird results, ot least i think they are weird since i don't know/understand what the term means, what does it mean?
03:42:00 <moon-child> it's a property of a concurrent system, namely that it does not deadlock
03:44:00 <devcpu> moon-child: tyvm! could you please give an example? i can digest assembly, at least most of the times =)
03:45:00 <zid> It's much more conceptual than that
03:50:00 <devcpu> i think i found a good paper on it https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-633.pdf
03:50:00 <devcpu> moon-child: zid: thanks for the pointers!
05:57:00 <vai> morning - .fi
07:46:00 <ksp> The
07:47:00 <ksp> Why did someone join and instantly quit
07:47:00 <Affliction> one of nature's mysteries
07:47:00 <Mutabah> people do that sometimes
07:48:00 <ksp> Mutabah: probably
13:10:00 <klange> Oops, it's been so long since I had actively done things in my Ubuntu install on my Surface it didn't even have a 64-bit toolchain setup
13:10:00 <klange> Ah well, was an opportunity to make sure I hadn't broken the set up scripts
15:03:00 <Mikaku> hi, is osdev.org down?
15:06:00 <GeDaMo> It's very slow for me
15:11:00 <Mikaku> seems starts responding now but it's very slow, indeed
15:14:00 <GeDaMo> https://web.archive.org/web/20210308081209/https://wiki.osdev.org/Expanded_Main_Page
15:14:00 <bslsk05> web.archive.org: Expanded Main Page - OSDev Wiki
15:15:00 <chibill[m]> I should get back into trying osdev for x86 type systems. Recently been focusing on my homebrew cpu at getting a basic bios and stuff written for it.
15:15:00 <GeDaMo> How are you building your CPU? FPGA?
15:17:00 <chibill[m]> Currently its just emulated in python until I can figure out some of the logic behind operations. (Like fetching instructions taking multiple cycles since they are 4 bytes each.) Going to build it in Digital which if I remember correctly will let me export to FPGA.
15:18:00 <chibill[m]> Basically I am at the stage of figuring out how micro-coding works.
15:32:00 <chibill[m]> Welp time for the fun of building a cross compiler on the system for the first time in like 3 years xD. (Last had one for a class that used xv6 but that was on a whole different machine.)
15:32:00 <junon> Or just use Clang.
15:32:00 <junon> Clang is a cross compiler by default.
15:33:00 <heat> it's a good idea to use multiple toolchains
15:33:00 <heat> portability is nice
15:34:00 <junon> Sure but clang is also a toolchain
15:34:00 <heat> that is correct
15:34:00 <junon> And GCC cross compilers aren't really different toolchains, just same one configured differently
15:35:00 <heat> yes
15:35:00 <chibill[m]> I am sort of surprised I have clang installed. Don't ever remember installing it.
15:35:00 <heat> but llvm and gnu are two different toolchains and that's my point
15:38:00 <heat> also /if you know what you're doing/(high entry barrier) you can skip the cross compiler if you're just compiling bare metal code for the host system
15:38:00 <heat> userspace is a bit harder but also doable
16:03:00 <chibill[m]> Question is there a tutorial or guide to making make files? I never really understood them and I don't want to be typing huge long commands to compile my os
16:03:00 <zid> rule: file_it_needs_first \n
16:03:00 <zid> \t command to produce file called rule
16:03:00 <zid> that's it
16:04:00 <chibill[m]> By never understood I mean making my own from nothing. I can do pretty well modifying and expanding existing ones.
16:04:00 <zid> a.exe: a.c\n\tgcc a.c -o a.exe
16:06:00 <heat> generally you have your usual targets (install, clean, maybe run if you so desire), install for example should depend on your program's target and your program's target should depend on its object files, and the object files depend on their .c files (+ header dep files)
16:06:00 <heat> ultimately you have a %.o: %.c \n\tgcc $< -o $@ $(CFLAGS) $(CPPFLAGS)
16:07:00 <zid> https://github.com/zid/boros/blob/master/boot/Makefile Most of my makefiles are just something like this
16:07:00 <bslsk05> github.com: boros/Makefile at master · zid/boros · GitHub
16:07:00 <catern> a memory model is a serialization mechanism, in both meanings of serialization
16:09:00 <catern> this is a witticism that is extremely niche (the niche is 2 people, me and the other person I was just talking to about how shared memory is a technique for transferring large datastructures from one core to another core)
16:10:00 <catern> (and obviously also a memory model is a serialization mechanism in the sense of providing sometimes-serial semantics to memory operations)
16:15:00 <eryjus> zid: why did you choose not to have boot.bin dependent on linker.ld? (thinking of `$(filter-out *.ld,$^)` )
16:16:00 <zid> eryjus: could have, wasn't important to my actual development cus I wasn't changing it
16:16:00 <zid> (should have)
16:48:00 <catern> i hope people like my witticism
17:59:00 <zid> [14:21] <matja> ziddie
17:59:00 <zid> [14:21] <matja> do you know if AMD publish microcode update changelogs?
18:00:00 <zid> mxshift? :p
18:00:00 <mxshift> I don't recall seeing them
18:00:00 <mxshift> might be buried in AGESA dumps
18:00:00 <zid> think we discussed that here like yesterday
18:03:00 <zid> <matja> microcode: microcode updated early to new patch_level=0x0a001143
18:03:00 <zid> Oh thank god for that
19:52:00 <mxshift> lol. Haven't used my AMD DevHub account in long enough that the password expired
19:55:00 <mxshift> at least for EPYC, there are release notes for microcode updates.