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=osdev&y=18&m=5&d=4
00:00:00 --- log: started osdev/18.05.04
00:18:55 --- join: xerpi (~xerpi@95.red-83-45-196.dynamicip.rima-tde.net) joined #osdev
00:19:34 --- quit: bender (Quit: Connection closed for inactivity)
00:19:46 --- join: zeus1 (~zeus@197.239.6.56) joined #osdev
00:24:34 --- join: godel (~gonzalo@190.192.95.122) joined #osdev
00:30:49 --- join: aesycos (~aesycos@47.188.182.89) joined #osdev
00:32:20 --- part: aesycos left #osdev
00:34:52 --- quit: quc (Remote host closed the connection)
00:35:04 --- join: quc (~quc@87.116.237.247) joined #osdev
00:41:35 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
00:42:47 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
00:42:47 --- nick: Halofreak1990_ -> Halofreak1990
00:47:18 --- join: sixand (~Thunderbi@106.127.19.245) joined #osdev
00:47:26 --- quit: zeus1 (Ping timeout: 260 seconds)
00:47:49 --- quit: godel (Ping timeout: 240 seconds)
00:48:06 --- join: Kimundi__ (~Kimundi@i577A9FBB.versanet.de) joined #osdev
00:48:16 --- quit: xerpi (Ping timeout: 255 seconds)
00:58:39 --- quit: sixand (Ping timeout: 256 seconds)
01:06:06 --- quit: JusticeEX (Ping timeout: 264 seconds)
01:14:15 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
01:17:43 --- quit: Kimundi__ (Ping timeout: 256 seconds)
01:19:36 --- quit: Pseudonym73 (Remote host closed the connection)
01:20:02 --- join: _sfiguser (~sfigguser@130.108.214.77) joined #osdev
01:31:00 --- join: zeus1 (~zeus@197.239.6.56) joined #osdev
01:31:17 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
01:34:39 --- join: martossikas (~garramba@fp76f166f9.stmb206.ap.nuro.jp) joined #osdev
01:34:55 --- quit: ACE_Recliner (Remote host closed the connection)
01:38:36 --- join: martossikas1 (~garramba@36-66-50-84.dyn.estpak.ee) joined #osdev
01:38:46 <martossikas1> one of the last times being here, so cpus could do quite well via caches a tlb in hw or sw, as if it was a register file on gpu, provided that sufficient amount of cache is present on some newer chips, but still there needs to be some way to fast switch thread contexts
01:39:58 <martossikas1> also than instruction set of the chip should take memory or immediate operands that are cached somehow, i am no big expert on cpu instruction sets, was never interested enough
01:41:43 --- quit: martossikas (Ping timeout: 240 seconds)
01:45:40 <martossikas1> so to do it per application basis , linux has some mlock facilitites to lock the lines, that musicians use to implement somewhat realtime audio, it'd do fine, but if context switches go faster it'd better
01:50:09 --- quit: martossikas1 (Quit: Leaving)
01:54:01 --- quit: hmmmm (Remote host closed the connection)
01:57:19 --- quit: zeus1 (Ping timeout: 240 seconds)
01:57:19 --- quit: bemeurer (Ping timeout: 240 seconds)
02:02:41 --- quit: MarchHare (Ping timeout: 260 seconds)
02:02:50 --- join: kimundi (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
02:04:11 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
02:09:10 --- quit: dengke (Quit: Leaving)
02:26:10 --- quit: hunterlabs (Ping timeout: 256 seconds)
02:31:51 --- quit: elevated (Quit: bye)
02:32:31 --- quit: vaibhav (Quit: Leaving)
02:33:36 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-xmfaqchpfjtbvqzz) joined #osdev
02:36:48 --- join: Asu (~sdelang@AMarseille-658-1-21-156.w86-203.abo.wanadoo.fr) joined #osdev
02:41:12 --- join: zeus1 (~zeus@197.239.6.56) joined #osdev
02:46:01 --- quit: raphaelsc (Remote host closed the connection)
02:47:01 --- quit: `Guest00000 (Ping timeout: 260 seconds)
02:47:10 --- join: andrei-n (~andrei@51.214-65-87.adsl-dyn.isp.belgacom.be) joined #osdev
02:50:10 <geist> man, 2 months later and 2 delayed shipments, the riscv board i bought is still not shipping
02:50:21 <rain1> :( why not?
02:51:16 <Vercas> geist: I feel your pain. I ordered a PicoEVB a month ago and a couple of adapters... And the adapters haven't arrived. Got a $250 piece of hardware in my hand but no way to use it.
02:51:37 <izabera> i ordered a kebab a few minutes ago and it's still not shipping
02:51:56 <Vercas> izabera: Tragic. What sauce?
02:52:02 <Brnocrist> I am still waiting for risc-v board as well..
02:52:14 <geist> Brnocrist: one of the hifive1s?
02:52:29 <rain1> i feel your pain guys, im waiting for an afforable riscv computer
02:53:57 <Vercas> I nearly finished my new interrupt handling stuff for my kernel.
02:54:12 <Vercas> Worked just a few minutes a day on it. :/
02:54:23 <Vercas> Didn'
02:54:34 <Vercas> ...'t realize how all over my use of interrupts was.
02:54:46 <Vercas> And how many times I basically implemented the same stuff.
02:56:22 <Brnocrist> geist: yes, the hifive1
02:58:05 <Ameisen> I had a number of concerns about that.
02:58:17 <Ameisen> biggest being the 16KiB data scratchpad
02:59:32 --- join: Amaan (uid4967@gateway/web/irccloud.com/x-cakotgfaemnhdhww) joined #osdev
03:11:09 <Vercas> That board looks noice.
03:11:34 --- quit: JusticeEX (Ping timeout: 268 seconds)
03:14:50 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
03:15:42 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
03:17:59 <geist> fascinating, the interface that the 80287 used to extend the 80286 is pretty magic
03:18:16 --- join: oaken-source (~oaken-sou@p4FE2D158.dip0.t-ipconnect.de) joined #osdev
03:18:45 <Vercas> geist: Wouldn't expect less.
03:18:46 <geist> from whati can tell it sits on the same data bus and watches the 286 for any read/writes to IO port f8, fa, fc
03:19:17 <geist> which drives out on the address bus, and those are used as control signals to the 287 that it's transferring data between the two processors (on the data bus)
03:20:06 <geist> since all the x87 instructions are in the ESC space of the opcode matrix (D8-DF prefix) it can i think parallel decode it
03:23:04 --- join: mra90 (~Martin@brx176.neoplus.adsl.tpnet.pl) joined #osdev
03:25:00 --- quit: MaryJaneInChain (Remote host closed the connection)
03:26:17 --- quit: _sfiguser (Quit: Leaving)
03:26:36 --- quit: bslsk05 (Quit: woops)
03:26:36 --- quit: puckipedia (Quit: *eh*)
03:26:37 <geist> oh very cute. 80387 uses a similar thing, but it uses A31 to signal a transfer with the 387
03:27:02 <geist> which is invalid, no IO port instruction can use A31, so it moves it out of the way. f8/fa/fc are no longer used
03:27:18 --- join: bslsk05 (~bslsk@puckipedia.com) joined #osdev
03:27:48 --- join: puckipedia (~puck@puckipedia.com) joined #osdev
03:29:55 <geist> and 80387sx does eactly the same thing but it uses A23 instead of A31
03:34:37 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-hzjwxoylvsbujtbu) joined #osdev
03:39:52 --- quit: quc (Remote host closed the connection)
03:40:05 --- join: quc (~quc@87.116.237.247) joined #osdev
03:40:13 <Vercas> Noice.
03:44:29 --- quit: quc (Ping timeout: 256 seconds)
03:51:10 --- join: quc (~quc@host-89-230-169-5.dynamic.mm.pl) joined #osdev
03:55:19 --- quit: quc (Ping timeout: 248 seconds)
04:03:03 --- quit: oaken-source (Ping timeout: 265 seconds)
04:05:05 --- join: quc (~quc@87.116.228.164) joined #osdev
04:05:07 --- join: m3nt4L (~asvos@2a02:587:a023:f000:3285:a9ff:fe8f:665d) joined #osdev
04:05:21 --- join: ecraven (~ecraven@www.nexoid.at) joined #osdev
04:13:23 --- join: NaNkeen (~nankeen@115.164.81.83) joined #osdev
04:26:15 --- quit: JusticeEX (Ping timeout: 265 seconds)
04:30:00 --- join: vmlinuz (~vmlinuz@2804:431:f724:df47:bad8:b80a:f1ec:523e) joined #osdev
04:30:00 --- quit: vmlinuz (Changing host)
04:30:00 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
04:30:15 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
04:34:31 --- join: oaken-source (~oaken-sou@p4FE2D158.dip0.t-ipconnect.de) joined #osdev
04:47:47 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
04:50:52 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-zpxiqnumvoikjqwu) joined #osdev
04:50:56 --- join: restinpeace (~restinpea@FL1-221-171-90-186.tky.mesh.ad.jp) joined #osdev
04:52:33 --- part: restinpeace left #osdev
04:59:42 --- quit: kimundi (Ping timeout: 276 seconds)
05:02:53 --- quit: ephemer0l_ (Remote host closed the connection)
05:03:11 --- join: `Guest00000 (~user@37.113.172.28) joined #osdev
05:03:13 --- join: ephemer0l_ (~ephemer0l@pentoo/user/ephemer0l) joined #osdev
05:04:54 --- join: Guest60839 (uid294264@gateway/web/irccloud.com/x-kgvjeizwmdyghilf) joined #osdev
05:09:06 --- quit: disasm (Quit: WeeChat 2.0)
05:16:05 --- quit: ALowther (Remote host closed the connection)
05:16:33 --- join: kimundi (~Kimundi@dynip-129-217-122-160.wifi.tu-dortmund.de) joined #osdev
05:21:27 --- join: Guest46 (4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72) joined #osdev
05:22:31 <Guest46> Anyone here worked with UEFI and Rust?
05:29:30 --- join: Lowl3v3l1 (~Lowl3v3l@141.35.23.133) joined #osdev
05:29:30 --- quit: Lowl3v3l (Read error: Connection reset by peer)
05:29:52 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
05:30:39 --- quit: JusticeEX (Ping timeout: 255 seconds)
05:35:11 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
05:35:41 --- join: martossikas (~garramba@36-66-50-84.dyn.estpak.ee) joined #osdev
05:36:55 --- part: martossikas left #osdev
05:37:31 --- join: martossikas1 (~garramba@36-66-50-84.dyn.estpak.ee) joined #osdev
05:37:45 <martossikas1> couple of links that may turn to be useful.
05:37:52 <martossikas1> http://www.eng.utah.edu/~cs5785/slides-f08/20-1up.pdf
05:38:05 <martossikas1> http://docplayer.net/amp/53807093-Software-based-branch-predication-for-amd-gpus.html
05:38:06 <bslsk05> docplayer.net: Software-based Branch Predication for AMD GPUs - PDF
05:38:36 <Vercas> Some bloke just wandered into our test lab, talking on the phone.
05:38:58 <Vercas> M8 that's like a bull wandering into a china shop when he's anxious.
05:39:28 <martossikas1> they show how predication on vliw can be done in software , some of the riscV chips can be vliw too, i did not generate the verilog and did not check hence
05:39:34 <Vercas> Every single thing there is exactly where it's meant to be. e.g. screws that were removed from a disk enclosure several months ago. :D
05:45:10 <martossikas1> basically vliw allows packing slightly more alus in case of gpu chip, i even like this a bit more, but the sw programmer has to know how to run it, but the differences are not as big, very tiny power effeciency in favor of vliw there, but in case of end user programmers, not comprehending how things work then true SIMD, is slightly perhaps more convenient
05:45:40 --- join: Naergon (~Naergon@unaffiliated/naergon) joined #osdev
05:47:17 --- join: tacco| (~tacco@i59F526A9.versanet.de) joined #osdev
05:49:02 --- quit: kimundi (Ping timeout: 256 seconds)
05:54:12 --- join: kimundi (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
05:54:57 --- quit: NaNkeen (Ping timeout: 240 seconds)
05:57:05 --- quit: zeus1 (Ping timeout: 256 seconds)
05:58:50 <martossikas1> i have all the issue logic ex stage long latency parking for vliw and variable width simd units for all gpu models developed, i am just waiting what to do with it
05:59:06 * variable looks at martossikas1
06:01:45 <martossikas1> i myself don't game and don't have time either, need to work soon, but it could be a poor gamers dream
06:06:04 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
06:07:26 <Mutabah> Guest46: Yep
06:08:34 <Mutabah> Guest46: I've written a UEFI bootloader (more of a boot shim) for my OS
06:08:39 --- join: NaNkeen (~nankeen@115.164.81.83) joined #osdev
06:08:49 --- quit: awang (Ping timeout: 240 seconds)
06:08:51 <Guest46> Mutabah: How did you compile your code to be uefi compatible
06:09:18 <Guest46> Mutabah: I wrote some bindings and would like to test them but I can't seem to make uefi recognize my binary :/
06:10:04 <Mutabah> Well, the loader just interpreted an elf binary
06:11:06 <Mutabah> and the bootloader itself is just linked into a pe32+
06:11:14 <Mutabah> https://github.com/thepowersgang/rust_os/tree/master/Bootloaders/uefi
06:11:15 <bslsk05> github.com: rust_os/Bootloaders/uefi at master · thepowersgang/rust_os · GitHub
06:11:34 <Mutabah> ... it's only been tested on qemu+ovmf though
06:11:57 <Guest46> Thanks, Ill check it out
06:12:02 <Guest46> Thats what I'm using too :D
06:14:45 --- quit: vmlinuz (Ping timeout: 255 seconds)
06:15:23 <Guest46> Also as a side question, how does an UEFI loader actually call the OS. I understand how the loader gets called but at what point does the loader hand control to the kernel?
06:16:09 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
06:17:06 <martossikas1> variable: i head off soon, any assistance or elaboration needed on the links contents?
06:19:24 <Lowl3v3l1> Guest46: the uefi loader has a table in which it locates which kernel to load. afterwards, it looks in its partition for this kernel, loads the PE into memory, reads it's entry point and jumps to it.
06:19:35 <martossikas1> to fight over irc about the code is silly, i did not expect this to happen, perhaps my reputation is just too notorious but, rather than arguing about it, it's best to use it instead, the code i mean, since overall the cores are designed to allow this, must had done somehow in purposly so too
06:19:45 <martossikas1> on purpose perhaps
06:19:46 <Mutabah> Guest46: The bootloader/kernel presents itself as a UEFI "application", eventually it calls "ExitBootServices", which gets the firmware to clean itself up and let the application have full control
06:20:05 <Guest46> ahh okay
06:20:12 <Guest46> so the kernel is actually an UEFI application
06:20:20 <Guest46> got it
06:20:40 <Lowl3v3l1> Guest46: either that or some bootloader is the uefi application and it calls the kernel
06:20:52 --- quit: Lowl3v3l1 (Quit: Leaving.)
06:24:13 --- nick: Guest71235 -> mrush
06:24:19 --- join: promach2 (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:26:53 <martossikas1> variable: so if you want look, the amd assmebly dest is like seen the first operand, the cpu link has another way around .. the low level refered asm code is pretty similar, just magnify the amd link and look at the add operands, some of the MUL part is left outside, but provides enough to understand it right?
06:27:46 <martossikas1> so on the read stage to avoid exec stalls , another instruction dest can be overwritten with a new value, and this instruction will be skipped, it can be done so only on vliw, it works minorly differently on SIMD
06:31:50 --- join: vmlinuz (~vmlinuz@187.101.155.139) joined #osdev
06:31:50 --- quit: vmlinuz (Changing host)
06:31:50 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
06:31:56 <Guest46> Mutabah: Do you know of a way to compile/link it with just the built in rust tools like xargo/llvm ld or do I need to get some other cross compiler toolchain?
06:33:39 <martossikas1> it has nothing in common with hw based predication, which is done too for this hw, though even an exec masc based predication can be done in sw too, but it is vliw's sw based predication to skip an instruction
06:34:58 <martossikas1> ok, cheers than! bye.
06:35:05 --- quit: martossikas1 (Quit: Leaving)
06:35:09 --- quit: ALowther (Remote host closed the connection)
06:38:28 <Mutabah> Guest46: Should be possible to use a target spec to make rustc call with the right linker options
06:38:46 <Mutabah> Buuut... I haven't done that for EFI
06:39:43 --- quit: gamozo (Ping timeout: 264 seconds)
06:40:15 --- join: zeus1 (~zeus@197.239.6.56) joined #osdev
06:42:33 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:44:23 --- quit: oaken-source (Ping timeout: 248 seconds)
06:44:53 --- join: MarchHare (~Starwulf@mo-184-5-204-232.dhcp.embarqhsd.net) joined #osdev
06:45:04 --- join: millerti (~millerti@cpe-66-24-91-119.stny.res.rr.com) joined #osdev
06:45:14 <Guest46> Also if I do want to separate the boot loader from the os or use some existing boot loader like clover, how can I make sure that the boot loader can find my kernel?
06:49:40 --- quit: zeus1 (Ping timeout: 256 seconds)
06:56:02 --- join: glauxosdever (~alex@ppp-94-66-37-144.home.otenet.gr) joined #osdev
07:00:09 --- part: ebrasca left #osdev
07:00:55 <Mutabah> Config file?
07:01:07 --- quit: MarchHare (Ping timeout: 256 seconds)
07:01:21 <Mutabah> Or hard-coded path on the EFI partition
07:02:49 --- quit: NaNkeen (Ping timeout: 240 seconds)
07:05:18 --- join: masoudd (~masoudd@5.115.117.24) joined #osdev
07:10:44 --- quit: xenos1984 (Quit: Leaving.)
07:11:20 <glauxosdever> I have a question. Computers in university labs take 5 to 10 minutes to present you with the login screen. I can usually see the hard drive working during this time (does Windows 7 perform defrags during booting or something?), but it's taking too long. And no one in charge has been notified, as they probably couldn't be bothered
07:11:43 <glauxosdever> How could I solve it, at least for the computer where I usually sit?
07:13:59 <bcos_> Take a screenshot of the login screen, and then set the "boot splash screen" to that! :-)
07:14:50 <glauxosdever> lol
07:15:04 <glauxosdever> Well, it's still non working.
07:15:19 --- quit: awang (Ping timeout: 248 seconds)
07:16:18 <bcos_> Ok.. Find someone in the same class that is always on time, and give them something ($10?) to turn your computer on for you. Then arrive 5 to 10 minutes late to see that your computer is already at the login screen! :-)
07:17:06 <glauxosdever> lol
07:17:39 <glauxosdever> Well, the professor usually unlocks the door when we are going to begin the lab
07:17:52 <glauxosdever> So that doesn't work either :p
07:18:18 <glauxosdever> But, curiously now, why does Windows suck so much that booting takes that much?
07:18:28 <glauxosdever> *that much time
07:18:49 <CWiz> it could be possible that the machine is being reimaged at boot. I know some places do that to get rid of anything that a user might do to the machine
07:19:45 <glauxosdever> There is a lot of junk in there. From images and test html code to virtual machines. I doubt it's being reimaged
07:21:01 <glauxosdever> But yeah, curious
07:21:18 <bcos_> Is the disk drive full?
07:21:39 <bcos_> (or almost full)
07:22:00 <bcos_> - that can cause problems (fragmentation, heads bouncing from one end of the disk to another, ...)
07:22:52 <glauxosdever> Hm, I'm not in the lab currently actually, but I'd assume it's not full, since I recently installed a Debian VM so I can use the tools I'm familiar with.
07:23:02 <bcos_> The other thing I'd look for is network activity - maybe it's mounting a network drive or something, and just pre-fetching stuff from disk because the disk isn't being used
07:23:06 <glauxosdever> And there weren't any problems
07:23:23 <glauxosdever> Could be, I'll check it next time
07:24:08 <bcos_> Could try defrag (at least can't hurt), if you have enough access
07:25:43 <glauxosdever> Ok, I'll try it. If I can't, I'll notify someone in charge and hope for the best
07:26:42 --- quit: mavhq (Read error: Connection reset by peer)
07:27:59 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
07:28:06 <glauxosdever> I remember once, in another lab, some computers booted quite quickly (< 5 minutes) while some needed up to 40 minutes (and I was one of the unlucky ones).
07:28:44 <glauxosdever> Fortunately, next time it was fixed
07:32:50 --- join: hmmmm (~sdfgsf@pool-72-79-161-213.sctnpa.east.verizon.net) joined #osdev
07:38:31 --- quit: quc (Ping timeout: 264 seconds)
07:42:41 --- join: Lowl3v3l (~Lowl3v3l@dslb-088-066-071-181.088.066.pools.vodafone-ip.de) joined #osdev
07:45:19 --- quit: aalm (Ping timeout: 240 seconds)
07:46:16 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
07:46:22 --- part: Lowl3v3l left #osdev
07:50:46 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
07:50:55 --- quit: ALowther (Ping timeout: 268 seconds)
07:52:41 --- quit: rain1 (Remote host closed the connection)
07:55:49 --- join: rain1 (~rain1@unaffiliated/rain1) joined #osdev
08:04:57 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
08:05:43 --- quit: JusticeEX (Ping timeout: 268 seconds)
08:06:05 --- quit: Guest46 (Remote host closed the connection)
08:10:11 --- quit: kimundi (Ping timeout: 260 seconds)
08:10:16 --- join: Guest46 (4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72) joined #osdev
08:12:18 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:16:39 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
08:17:57 --- quit: variable (Ping timeout: 276 seconds)
08:22:34 --- join: baschdel_ (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
08:22:48 --- quit: baschdel_ (Client Quit)
08:23:49 --- join: baschdel_ (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
08:24:14 --- quit: baschdel_ (Client Quit)
08:24:32 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
08:26:24 --- quit: nightmared (Quit: WeeChat 2.1)
08:39:19 --- quit: Guest46 (Remote host closed the connection)
08:46:32 --- quit: grouse (Quit: Leaving)
08:46:56 <baschdel> Hello, can somebody tell me why ld alwas puts my multiboot header at the end of the .text section ? Link script : https://yourpart.eu/p/86F2AS2puF
08:46:57 <bslsk05> yourpart.eu: Etherpad
08:48:29 <baschdel> and more important how to get it closer to the start ...
08:48:57 <Ameisen> Hrmm... what are the full Windows paths for a drive?
08:49:13 <Ameisen> Like, D:\ maps to something like //D/ or something
08:49:38 <baschdel> I'm on linux
08:51:31 <Ameisen> \\?\ is the prefix
08:51:46 <Ameisen> for drive letters it is just the letter thereafter. You'd have to use a device-specific identifier otherwise
08:54:04 <baschdel> You confused me a little
08:54:46 <baschdel> As said above I use a linux system . no drive letters
08:55:10 <Ameisen> I added namespaces to BSD once
08:55:16 <Ameisen> so you had system:/...
08:55:34 <Guest60839> Why aligned memory access is faster than unaligned memory access?
08:55:55 --- quit: mra90 (Ping timeout: 264 seconds)
08:56:12 --- join: mra90 (~Martin@bsx242.neoplus.adsl.tpnet.pl) joined #osdev
08:57:08 --- join: BrainFog (~BrainFog@cpc89010-gill18-2-0-cust1263.20-1.cable.virginm.net) joined #osdev
08:57:12 <BrainFog> hey guys!
08:57:14 <baschdel> @Ameisen Ok i don't use them just /home/baschdel/Dokumente/devel/icefire/icefire_t6.4.1
08:57:22 <baschdel> Hello
08:57:53 <pounce> baschdel: I doubt they were talking to you
08:58:51 <BrainFog> Does anyone know why many things including the RTC go a lot slower in a nested virtualized environment?
09:00:03 --- quit: CheckDavid (Quit: Connection closed for inactivity)
09:01:50 --- quit: Tazmain (Quit: Leaving)
09:02:57 --- quit: millerti (Ping timeout: 256 seconds)
09:04:17 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
09:11:30 --- join: oaken-source (~oaken-sou@p4FE2C58D.dip0.t-ipconnect.de) joined #osdev
09:19:04 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:23:48 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
09:25:12 --- quit: vdamewood (Client Quit)
09:27:25 --- join: nightmared (~nightmare@unaffiliated/nightmared) joined #osdev
09:28:21 --- quit: `Guest00000 (Ping timeout: 260 seconds)
09:30:53 --- quit: nightmared (Client Quit)
09:31:36 --- join: nightmared (~nightmare@unaffiliated/nightmared) joined #osdev
09:33:28 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:33:37 --- quit: glauxosdever (Quit: leaving)
09:36:28 <pounce> is the interrupt descriptor table per-cpu?
09:37:05 <pounce> (in other words, is it always safe to modify it after a `cli`?)
09:38:11 <Ameisen> sooo close to having gcc build
09:38:25 <Ameisen> building clang is... vastly simpler
09:38:37 <Ameisen> helps that llvm and clang can be built natively on basically every platform
09:38:42 <Ameisen> including in visual c++
09:39:59 --- join: `Guest00000 (~user@37.113.172.28) joined #osdev
09:41:20 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
09:42:40 --- quit: mpetch (Quit: No Ping reply in 180 seconds.)
09:43:44 <jjuran> Guest60839: Because processors think in terms of words, not individual bytes. An unaligned memory access involves multiple words and some shifting.
09:44:05 --- join: mpetch (~mpetch@vps2.gnubg.com) joined #osdev
09:49:54 <Ameisen> running into issues finding stdio.h. Not sure why it needs a libc for this.
09:50:25 <Ameisen> jjuran - newer x86 processors handle unaligned ops at the same speed as aligned.
09:50:33 <Ameisen> the wonders of CISC
09:52:05 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
10:00:14 --- quit: vdamewood (Ping timeout: 265 seconds)
10:06:04 --- join: aalm (~aalm@37-219-119-194.nat.bb.dnainternet.fi) joined #osdev
10:14:31 --- quit: bauen1 (Ping timeout: 264 seconds)
10:18:55 --- quit: nightmared (Quit: WeeChat 2.1)
10:19:51 --- quit: pounce (Ping timeout: 248 seconds)
10:19:52 --- join: light2yellow (~l2y@217.30.64.102) joined #osdev
10:21:08 --- quit: nur (Quit: Leaving)
10:21:27 --- quit: promach2 (Ping timeout: 248 seconds)
10:27:55 --- quit: m3nt4L (Quit: Leaving)
10:35:03 * geist yawns
10:35:47 * klys tosses chocolate covered coffee beans at geist
10:37:02 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
10:37:37 --- join: nur (~hussein@slb-97-111.tm.net.my) joined #osdev
10:37:45 <geist> hmmm, not bad
10:37:51 <geist> i am drinking coffee for sure
10:38:18 <klys> good morning
10:38:45 <Ameisen> I can't stand coffee for some reason
10:38:48 <Ameisen> the flavor, the smell.
10:38:53 <klys> same
10:39:06 <Ameisen> if my wife drank coffee, or has a drink with even a little bit, I can tell right away
10:39:29 <geist> oh bummer. it's lovely
10:40:29 --- quit: tux3 (Changing host)
10:40:29 --- join: tux3 (tux@unaffiliated/tux3) joined #osdev
10:41:08 <klys> ameisen, what file needed stdio.h ?
10:41:27 --- quit: ALowther (Ping timeout: 240 seconds)
10:41:56 <Ameisen> klys - I changed a few things aroudn to make sure it knew the target correctly. I'll get back to you
10:42:02 <klys> k
10:42:08 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
10:46:47 --- join: freakazoid0223_ (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
10:49:18 --- quit: freakazoid0223 (Ping timeout: 264 seconds)
10:53:38 --- join: nightmared (~nightmare@unaffiliated/nightmared) joined #osdev
10:55:23 <Ameisen> atm, it succeeds in building binutils, it builds a 'lite' version of gcc to build gcc again, and it's failing libgcc
10:55:32 <Ameisen> waiting until it gets back to that point
10:56:28 <mra90> is GAS and AS the same thing?
10:56:30 <klys> bbl. lunchtime
10:56:37 <mra90> simply gnu assembler
10:59:58 <geist> yes
11:00:19 <geist> well, gnu assembler is a specific thing
11:00:27 <geist> 'as' may be pointing at gnu as, or maybe something else
11:00:30 <geist> so maybe the answer is no
11:00:36 <geist> but it depends on precisely the context
11:04:41 --- quit: Guest60839 (Quit: Connection closed for inactivity)
11:07:50 --- quit: light2yellow (Quit: light2yellow)
11:08:14 --- join: godel (~gonzalo@190.192.95.122) joined #osdev
11:10:19 --- quit: oaken-source (Ping timeout: 265 seconds)
11:12:46 --- quit: elderK (Ping timeout: 260 seconds)
11:15:24 --- quit: hppavilion[1] (Ping timeout: 276 seconds)
11:22:08 --- join: attah (~attah@h-155-4-135-114.NA.cust.bahnhof.se) joined #osdev
11:22:41 --- quit: JusticeEX (Ping timeout: 260 seconds)
11:22:56 --- join: user_457467 (~user34657@173.170.58.131) joined #osdev
11:23:38 <user_457467> if i wish to build a gcc that can compile a linux userland for i686, would i set my target to "i686-linux-gnu"?
11:24:10 --- join: glauxosdever (~alex@ppp-94-66-37-144.home.otenet.gr) joined #osdev
11:25:55 <klys> yes.
11:26:13 <user_457467> ty
11:27:28 --- quit: user_457467 (Client Quit)
11:29:32 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
11:30:53 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
11:36:41 --- quit: hppavilion[1] (Ping timeout: 260 seconds)
11:42:12 --- join: alexneudatchin (~alexn___r@31.148.139.118) joined #osdev
11:43:00 --- quit: hiei (Quit: ...)
11:43:13 --- join: hiei (jinzoninge@gateway/shell/elitebnc/x-rjqhhjpicfkiscyl) joined #osdev
11:43:49 --- quit: BrainFog (Ping timeout: 240 seconds)
11:44:18 <geist> ah gcc 8.1 got released a few days ago
11:44:19 --- quit: hiei (Remote host closed the connection)
11:44:35 --- join: hiei (jinzo@gateway/shell/elitebnc/x-fjmsjvukpnvbupar) joined #osdev
11:48:58 <aalm> o_O
11:49:49 <aalm> still at "gcc version 4.2.1 20070719" here
11:52:45 <chrisf> aalm: apple machine?
11:53:48 <aalm> Target: amd64-unknown-openbsd6.3
11:53:51 --- quit: ratsch (Quit: Leaving)
11:55:06 <geist> 4.2.1 is the magic version that sytems that dont want to deal with GPLv3 stick with
11:55:12 <geist> iirc 4.2.1 is the last GPLv2 version of teh compiler
11:55:14 <aalm> yep
11:55:21 <geist> apple stuck with it for a long time until clang completely replaced everything
11:55:37 <geist> and then iirc clang itself pretends to be 4.2.1, or at least did for a long time
11:55:49 <aalm> we've got "OpenBSD clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)" too
11:55:51 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
11:56:12 <geist> oh hey, look at that. gcc 8.1 finally added the 'naked' attribute for x86
11:56:41 <chrisf> git fa
11:56:47 <chrisf> oops.
11:56:48 <aalm> actually, i think clang6 even, but i havent updated for few weeks
11:56:53 <geist> no i will not git fa!
11:57:08 <geist> https://gcc.gnu.org/gcc-8/changes.html for anyone that cares
11:57:10 <bslsk05> gcc.gnu.org: GCC 8 Release Series — Changes, New Features, and Fixes - GNU Project - Free Software Foundation (FSF)
12:09:20 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
12:14:01 --- quit: Tazmain (Client Quit)
12:15:30 --- quit: baschdel (Ping timeout: 256 seconds)
12:25:39 --- join: BartAdv (uid90451@gateway/web/irccloud.com/x-kammkbfnvjxmdtfs) joined #osdev
12:26:59 --- quit: godel (Ping timeout: 276 seconds)
12:35:13 --- join: lldd_ (~atrapado@unaffiliated/atrapado) joined #osdev
12:38:57 <lldd_> is it a reasonable optimization to only save and restore caller-save registers when we return to the same thread in a interruption or system call? or it is better to save all registers always?
12:39:15 <geist> it's a reasonable optimization
12:42:06 <lldd_> ok thanks. specially if there are many registers in the architecture, I understand. and then care has to be taken to not to trash accidentally one of them
12:42:25 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
12:44:33 --- quit: nightmared (Quit: WeeChat 2.1)
12:44:56 --- quit: masoudd (Ping timeout: 260 seconds)
12:46:01 --- join: nightmared (~nightmare@unaffiliated/nightmared) joined #osdev
12:47:02 --- join: masoudd (~masoudd@5.115.117.24) joined #osdev
12:50:52 --- join: oaken-source (~oaken-sou@p4FE2C58D.dip0.t-ipconnect.de) joined #osdev
12:52:59 --- join: mipicdev (~mipicdev@p200300E4ABCE7392C97A60EBCBD8253F.dip0.t-ipconnect.de) joined #osdev
13:03:19 --- quit: `Guest00000 (Ping timeout: 240 seconds)
13:06:49 --- quit: nj0rd (Ping timeout: 240 seconds)
13:09:21 --- join: masoudd_ (~masoudd@5.117.61.157) joined #osdev
13:10:30 --- join: `Guest00000 (~user@37.113.172.28) joined #osdev
13:11:03 --- quit: oaken-source (Ping timeout: 248 seconds)
13:11:35 --- quit: masoudd (Ping timeout: 248 seconds)
13:13:49 --- quit: alexneudatchin (Quit: Leaving)
13:22:02 --- join: nj0rd (~nj0rd@mue-88-130-48-139.dsl.tropolys.de) joined #osdev
13:28:28 --- quit: mipicdev (Quit: Konversation terminated!)
13:28:51 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
13:28:59 --- join: hppavilion[1] (~dosgmowdo@250-200-58-66.gci.net) joined #osdev
13:29:59 --- join: mipicdev (~mipicdev@p200300E4ABCE7392C97A60EBCBD8253F.dip0.t-ipconnect.de) joined #osdev
13:34:43 --- join: josuedhg (~josuedhg_@134.134.139.72) joined #osdev
13:45:01 --- quit: mipicdev (Quit: Konversation terminated!)
13:46:26 <Kazinsal> fellow chip fab technology nerds: TSMC has announced they can stack GPU wafers on top of each other now instead of just having to increase die size to fit more transistors in a given area
13:46:36 <Kazinsal> this is both really cool and kind of frightening because holy shit the thermals
13:47:04 --- join: arora (~ashok@92.99.133.177) joined #osdev
13:49:26 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:49:31 <geist> wow yeah
13:50:46 <Kazinsal> they're even saying it's possible to stack interposers so they can have more than just two dies on a stack
13:51:37 <Kazinsal> or to have a core die on top of an uncore die so they can do things like condense HBM and GPU onto one die instead of three to five bonded dies
13:52:34 <geist> from a modularity point of view that makes a lot of sense
13:52:50 <geist> seems like you could map different hard blocks from different vendors vertically
13:53:32 <geist> with dies manufactured at different times
14:00:11 <Ameisen> hrmm... binutils doesn't appear to bebuilding gold for some reason
14:05:41 <arora> hey, where are motherboard drivers in the linux kernel?
14:07:57 --- join: godel (~gonzalo@190.192.95.122) joined #osdev
14:08:07 --- join: daniele_athome (~daniele_a@5.170.121.225) joined #osdev
14:08:51 <geist> not sure there are a lot of specific mobo drivers. there may be chipset drivers for particular purposes
14:08:57 <geist> but nothing that's for a particular motherboard
14:10:26 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
14:13:17 <arora> geist: how can i know if a particular chipset has drivers for it (msi)?
14:15:07 --- quit: andrei-n (Ping timeout: 264 seconds)
14:18:13 <aalm> boot it?
14:26:26 --- quit: `Guest00000 (Ping timeout: 260 seconds)
14:29:21 <arora> aalm: it boots up but doesnt come back up after suspend
14:29:48 <arora> kernel issue #199577 to be exact though i am just helping to solve it
14:33:22 --- quit: fujisan (Quit: Connection closed for inactivity)
14:40:32 --- quit: glauxosdever (Quit: leaving)
14:45:42 --- join: kimundi (~Kimundi@i577A9FBB.versanet.de) joined #osdev
14:50:37 --- quit: lldd_ (Quit: Leaving)
14:52:49 --- quit: daniele_athome (Ping timeout: 240 seconds)
14:53:23 --- join: light2yellow (~l2y@217.30.64.102) joined #osdev
14:58:30 --- quit: attah (Remote host closed the connection)
14:59:20 --- join: daniele_athome (~daniele_a@5.170.120.213) joined #osdev
15:00:36 --- quit: doug16k (Remote host closed the connection)
15:00:37 --- quit: light2yellow (Quit: light2yellow)
15:03:34 --- quit: vmlinuz (Quit: Leaving)
15:04:26 --- quit: daniele_athome (Ping timeout: 268 seconds)
15:04:51 --- join: Asu` (~sdelang@92.184.101.236) joined #osdev
15:08:26 --- quit: Asu (Ping timeout: 260 seconds)
15:09:44 --- quit: mra90 (Ping timeout: 264 seconds)
15:10:36 --- join: mra90 (~Martin@bsx242.neoplus.adsl.tpnet.pl) joined #osdev
15:18:49 --- quit: masoudd_ (Ping timeout: 240 seconds)
15:22:45 --- quit: arora (Quit: leaving)
15:28:36 --- quit: Asu` (Quit: Konversation terminated!)
15:48:26 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
15:56:30 --- join: MarchHare (~Starwulf@mo-184-5-204-232.dhcp.embarqhsd.net) joined #osdev
16:02:56 --- join: `Guest00000 (~user@37.113.172.28) joined #osdev
16:15:36 --- quit: xenos1984 (Quit: Leaving.)
16:17:37 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-iwbwayowwnftrmjw) joined #osdev
16:19:29 --- quit: raiz (Ping timeout: 256 seconds)
16:25:26 --- quit: Shamar (Quit: Lost terminal)
16:31:32 --- join: tsurai_ (~tsurai@mail.tsunix.de) joined #osdev
16:32:02 --- quit: tsurai (Ping timeout: 276 seconds)
16:38:16 --- quit: tsurai_ (Ping timeout: 260 seconds)
16:38:26 --- quit: baschdel (Ping timeout: 256 seconds)
16:40:07 --- quit: kimundi (Ping timeout: 248 seconds)
16:52:27 --- quit: JusticeEX (Ping timeout: 240 seconds)
16:54:07 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
16:58:15 --- quit: godel (Ping timeout: 248 seconds)
17:24:10 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
17:25:14 --- quit: BartAdv (Quit: Connection closed for inactivity)
17:31:08 --- quit: MDude (Quit: Going offline, see ya! (www.adiirc.com))
17:31:43 --- join: MDude (~MDude@pa-67-234-118-37.dhcp.embarqhsd.net) joined #osdev
17:32:10 --- join: SGautam (3bb6fe68@gateway/web/freenode/ip.59.182.254.104) joined #osdev
17:33:50 <SGautam> Is the Spectre thing new, or was it discovered post-Meltdown and just came out now?
17:34:21 --- join: tsurai (~tsurai@mail.tsunix.de) joined #osdev
17:35:40 <SGautam> "On May 3, 2018, eight additional Spectre-class flaws were reported affecting Intel and possibly AMD and ARM processors. Intel reported that they are preparing new patches to mitigate these flaws.[27]"
17:37:43 --- quit: JusticeEX (Ping timeout: 248 seconds)
17:40:56 <Mutabah> SGautam: Spectre was originally announced at almost the same time as meltdown
17:41:10 <Mutabah> These new ones are the same sort of attack as the original spectre
17:42:23 --- join: raiz (~raiz@45.32.148.100) joined #osdev
17:43:11 --- join: doug16k (~dougx@172-97-186-27.cpe.distributel.net) joined #osdev
17:48:34 --- join: promach2 (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
17:48:42 --- quit: tsurai (Ping timeout: 264 seconds)
17:49:40 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
17:50:30 --- join: vaibhav (~vnagare@125.16.97.127) joined #osdev
17:52:47 --- quit: hppavilion[1] (Ping timeout: 268 seconds)
17:53:09 --- join: tsurai (~tsurai@mail.tsunix.de) joined #osdev
17:55:19 --- quit: raiz (Ping timeout: 240 seconds)
18:00:08 --- join: raiz (~raiz@fardan.info) joined #osdev
18:05:09 --- quit: raiz (Quit: I'll be back...)
18:07:48 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
18:07:54 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
18:11:18 --- join: quc (~quc@87.116.228.164) joined #osdev
18:14:57 --- quit: tktech (Ping timeout: 240 seconds)
18:22:44 --- join: tktech (~tktech@ec2-52-70-105-60.compute-1.amazonaws.com) joined #osdev
18:27:08 --- join: NaNkeen (~nankeen@115.164.81.83) joined #osdev
18:30:31 --- quit: ALowther (Remote host closed the connection)
18:31:28 --- join: NaNkeen_ (~nankeen@115.164.81.83) joined #osdev
18:35:19 --- quit: elevated (Ping timeout: 248 seconds)
18:52:01 <CrystalMath> i have a question
18:52:16 <CrystalMath> how do i port a library, let's say libpng, before i can actually run configure inside my OS?
18:52:55 <CrystalMath> i can't run configure as that would require porting sh and stuff, and considering my OS is not a *nix, it's not an easy task at all
18:53:15 <Mutabah> Cross-compile?
18:53:23 <Mutabah> I.e. run configure on your dev box
18:56:19 --- quit: MDude (Ping timeout: 240 seconds)
18:58:02 --- join: MDude (~MDude@pa-67-234-118-37.dhcp.embarqhsd.net) joined #osdev
18:58:59 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
19:06:18 --- join: bcos (~bcos@1.123.132.110) joined #osdev
19:09:47 --- quit: bcos_ (Ping timeout: 265 seconds)
19:14:46 --- join: bemeurer (~bemeurer@185.236.200.248) joined #osdev
19:15:06 --- quit: zhiayang (Ping timeout: 264 seconds)
19:16:20 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-uvgazzmjqxwhtzvp) joined #osdev
19:16:32 <lachlan_s> Hello again!
19:16:43 <lachlan_s> It's been a while since I logged on
19:17:22 * Mutabah waves
19:18:08 <lachlan_s> My os is going quite well!
19:18:43 <lachlan_s> Got accepted for the gsoc project for it!
19:27:21 --- quit: X-Scale (Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet)
19:27:46 <SGautam> that's cool
19:27:51 <SGautam> congrats lachlan
19:28:57 <lachlan_s> Thanks man
19:42:01 <qoxncyha> is there an atomic 3-way pointer swap that can be emulated by most modern architectures?
19:46:10 --- quit: SGautam (Quit: Page closed)
19:53:06 --- quit: mra90 (Ping timeout: 260 seconds)
20:00:00 --- quit: Shikadi (Read error: Connection reset by peer)
20:01:33 --- quit: tacco| ()
20:03:39 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
20:08:36 --- part: NaNkeen_ left #osdev
20:09:36 --- quit: NaNkeen (Quit: leaving)
20:09:58 --- join: NaNkeen (~nankeen@115.164.81.83) joined #osdev
20:10:15 --- join: geistdos (~JZoidberg@97-113-178-181.tukw.qwest.net) joined #osdev
20:10:33 <geistdos> fun! got an eth card working on the old 386
20:11:57 --- quit: ALowther (Remote host closed the connection)
20:11:58 --- quit: geistdos (Client Quit)
20:15:35 --- quit: nj0rd (Ping timeout: 256 seconds)
20:18:46 --- quit: NaNkeen (Ping timeout: 260 seconds)
20:21:46 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
20:23:10 <Mutabah> Ooh, fanceh
20:23:27 <doug16k> what nic?
20:24:01 <geist> 3c509B-TPO
20:24:14 <geist> got one on ebay for pocket change
20:24:18 <geist> and a SB16
20:25:01 <doug16k> ISA? wow. BNC connector?
20:25:10 <geist> no. TPO is 10baseT
20:25:14 <doug16k> ah
20:25:27 <geist> the NE2K that came with it had BNC, but i didn't have any BNC cables, so it was easier to just get another card off ebay
20:25:37 <geist> and 3c509s were known to be a lot better in general, supposedly
20:25:44 <geist> i'll look at the linux driver in a bit and see
20:28:07 <geist> neat thing is someone put together a cute little TCPIP stack for dos with a bunch of utilities
20:28:15 <geist> telnet, ftp, http get, ftp server, http server
20:28:22 <geist> so now you can easily move files around
20:29:07 --- quit: quc (Remote host closed the connection)
20:29:28 <doug16k> qoxncyha, 3-way?
20:30:08 <qoxncyha> doug16k: yep. trying to atomically insert into a linked list, so that i don't end up with the ABA problem.
20:30:08 --- join: nj0rd (~nj0rd@mue-88-130-48-064.dsl.tropolys.de) joined #osdev
20:30:22 --- quit: pounce (Quit: WeeChat 2.1)
20:30:24 <qoxncyha> (but with the additional stipulation of no spinlocks)
20:31:49 --- join: NaNkeen (~nankeen@115.164.81.83) joined #osdev
20:32:06 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
20:35:42 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
20:35:45 <doug16k> I think the PDP-11 had linked list instructions :P
20:35:59 <qoxncyha> doug16k: unfortunately i'm on x86
20:36:21 --- join: mra90 (~Martin@bsd174.neoplus.adsl.tpnet.pl) joined #osdev
20:36:49 --- quit: NaNkeen (Ping timeout: 268 seconds)
20:40:07 --- join: quc (~quc@87.116.228.164) joined #osdev
20:43:46 <geist> vax did
20:44:09 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:44:46 <doug16k> ah
20:45:02 <geist> http://www.itec.suny.edu/scsys/vms/OVMSDOC073/V73/4515/4515pro_022.html
20:45:03 <bslsk05> www.itec.suny.edu: VAX MACRO and Instruction Set Reference Manual
20:45:07 <doug16k> cisc gone wild
20:45:28 <geist> actually it's pretty simple, because it did the standard circular double linked list
20:45:38 <geist> the advantage of that is there are no decisions, you can just microcode it as a series of load/stores
20:45:43 --- quit: sprocklem (Ping timeout: 255 seconds)
20:46:46 <geist> http://www.s-and-b.ru/syshlp/vms_html/4515/4515pro_021.html section 9.2.7
20:46:52 <bslsk05> www.s-and-b.ru: VAX MACRO and Instruction Set Reference Manual
20:46:53 <geist> neat that it does seemt o have a 'self relative' mode
20:48:03 --- quit: ALowther (Remote host closed the connection)
20:48:04 <geist> looks like instead of storing a prev/next pointer you store the relative distance of the current item to the prev/next
20:48:18 <geist> thats kind of cute, if you can guarantee that the items are near each other you can probably use smaller offsets
20:48:18 --- join: sixand (~Thunderbi@112.5.248.209) joined #osdev
20:48:33 <geist> that'd be handy on something like a 32bit relative offset on a 64bit machine to save space
20:48:45 <geist> if you can guaratnee that everything is within +/- 2GB
20:50:16 --- quit: `Guest00000 (Ping timeout: 260 seconds)
20:50:39 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
20:51:35 <doug16k> that's what I do in my red-black tree, I store 32 bit indices from the base of the block for the left/right/parent links. that way I can realloc/mremap it without touching anything to grow it and it maximizes locality
20:54:05 <doug16k> I had considered doing it like std::map but I wanted to avoid tons of separate allocations
20:56:51 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
20:57:24 <doug16k> really not liking xilinx tools
20:57:29 <doug16k> crappy
20:58:16 <doug16k> if I use the DDR memory controller IP I can't use the clk input anymore. what the hell?
20:59:12 <doug16k> hundreds of warnings in their IP
20:59:28 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
21:02:25 <jjuran> doug16k: 68020+ has CAS and CAS2, a foundation of the queues used in Massalin’s Synthesis OS :-)
21:04:07 <Ameisen> doug16k - what about binary tree instructions
21:05:07 <Ameisen> geist - can't you functionally do that with x86?
21:05:15 <Ameisen> with it's 10 billion addressing modes?
21:05:48 <qoxncyha> unfortunately i'm not on vax :P
21:06:00 <Ameisen> Well, there's your problem.
21:06:53 <doug16k> qoxncyha, 32 or 64 bit?
21:07:08 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
21:07:21 <qoxncyha> doug16k: 64-bit
21:07:30 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:07:47 <doug16k> you can use the upper 16 bits as a sequence number to work around ABA. x86_64 addresses are 48 bit
21:08:41 <doug16k> is your list just a last in first out stack?
21:09:09 <qoxncyha> doug16k: does that make things easier? then sure
21:09:26 --- quit: unixpickle (Client Quit)
21:09:56 <qoxncyha> sorry, can you explain what you mean by using the upper 16 bits?
21:10:28 <doug16k> x86_64 has a 48 bit linear address space. bit 63:48 are always equal to bit 47
21:10:58 <mischief> uh, i don't think they are ignored
21:10:59 <doug16k> so if bit 47 is 0, then bit 63:48 are 0. if bit 47 is 1, then bit 63:48 are 1111111111111111
21:11:10 <doug16k> they aren't ignored
21:11:17 <mischief> pretty sure you'll get a trap if you have a noncanonical address
21:11:28 <doug16k> you'll get #GP
21:11:54 <qoxncyha> sure, i get that there's 48 usable bits
21:12:12 <doug16k> so you can pack a sequence number in the upper 16 bits for ABA handling
21:12:23 <qoxncyha> doug16k: how? :P
21:13:00 <doug16k> when you cmpxchg the new pointer value, you always write a value with the upper 16 bit sequence number one more than the original
21:13:28 <doug16k> if something else sneaked in and changed it (ABA) then you won't see the expected sequence number even though they changed the pointer back to "A"
21:13:30 <Ameisen> of course, that isn't forward-compatible.
21:14:32 <doug16k> anyway, I recommend against fancy lock-free trickery
21:14:49 <qoxncyha> doug16k: i'm trying to learn
21:14:52 <Ameisen> Wouldn't the smarter, forward-compliant way be to use CMPXCHG16B?
21:15:09 <Ameisen> And have a 64-bit pointer and the remaining 64 btis be a counter
21:15:14 <doug16k> assuming you have a double-sized cas
21:15:16 <qoxncyha> okay, so i'm inserting C between A -> B. i set C's nextptr -> B and A's nextptr -> B. if another thread comes in and tries to do the same thing, wouldn't we end up with A -> D -> B and dangling C -> B?
21:16:10 <doug16k> that's why I asked if it was just a lifo stack
21:16:21 <doug16k> there is no "inserting between" with LIFO
21:16:44 <qoxncyha> gotcha, so with a LIFO stack i could just traverse and cmpxchg
21:16:57 <doug16k> would still have ABA
21:17:11 <doug16k> but yeah, in simple scenario it would seem to work
21:17:23 <qoxncyha> you're right
21:17:40 <qoxncyha> how would a stamped reference help in this case?
21:18:00 <doug16k> the cmpxchg wouldn't be the value you expected so you would know to restart
21:18:20 <qoxncyha> okay, so a spinlock would be required
21:18:21 <doug16k> even if ABA scenario occurred
21:19:28 <doug16k> the trouble with trying to do this is not the insertion or traversal, it is removal. how can you reliably free a node that another thread might be accessing?
21:19:49 <qoxncyha> yes
21:19:54 <doug16k> that is the pain of lock free
21:20:18 <geist> doug16k: there was some paper recently i was reading that did something like that
21:20:37 <doug16k> hazard pointers?
21:20:44 <geist> it was some sort of pointer + array bounds thing, by having some sort of negative pointer
21:21:23 <geist> i forget the details, but something like the top N bits were fffff... which was the 2s compliment of the size, so if you added the offset to it you'd still be good if it were negative. or smething like that
21:21:43 <doug16k> ah
21:22:39 <geist> i'm butchering it, it was actually a lot more lever than that
21:22:39 <qoxncyha> doug16k: can you explain what you mean by removal is troubling?
21:23:26 <doug16k> when you free a node it could get allocated right after, and trashed. what if another thread is just about to access it? you have no way of being sure that some other racing thread is just about to access it
21:23:48 <doug16k> being sure whether*
21:24:11 <Ameisen> I saw that paper
21:24:13 <Ameisen> but didn't read it
21:24:15 <Ameisen> :|
21:24:33 <Ameisen> It was posted on one of the programming subreddits
21:26:19 <qoxncyha> doug16k: okay, so A -> B, i am freeing B but another thread wants to insert B -> C, is that what you're talking about?
21:27:01 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
21:27:16 --- join: oaken-source (~oaken-sou@p4FE2C58D.dip0.t-ipconnect.de) joined #osdev
21:27:17 <doug16k> qoxncyha, so, you cheat. you delay freeing it, hopefully long enough that nobody is just about to access it. hope is all you have. if the machine is overloaded, a thread might have been delayed seconds, right before it accesses it anyway. you have to delay the free extremely long, to be sure that it won't get dereferenced after it is freed
21:27:33 <qoxncyha> you could atomically mark B for deletion, then set A to point to null, then free B
21:27:54 <qoxncyha> other threads wouldn't try to write to B since it was marked for deletion
21:27:59 <doug16k> how does that prevent another thread accessing it after?
21:28:08 <qoxncyha> doug16k: because of the marker
21:28:11 <doug16k> no, memory updates don't propagate anywhere near that fast
21:28:20 <qoxncyha> well that's the point of atomicity, no?
21:28:25 <doug16k> no
21:28:54 <doug16k> atomicity does not make updates instant
21:29:25 <doug16k> it makes it so you are sure that nobody can sneak in and change it or see a half-updated value
21:29:37 <qoxncyha> as soon as i set the deletion marker on B, nobody will try to make it point to C
21:29:46 <doug16k> stores are queued
21:30:33 <qoxncyha> that's the thing, i'm trying to implement the queue itself
21:30:43 <qoxncyha> for the sake of learning
21:31:01 <doug16k> what do you picture a store doing? you do the store and instantaneously the memory is updated?
21:31:43 <doug16k> the only thing you can guarantee is the order that other processors see the store. they see either the old value, or the new value
21:32:15 <doug16k> and you can guarantee that all prior stores are visible before the current store. there is no way to "expedite" other processors seeing a store
21:32:27 <doug16k> it is already doing it as fast as it can, every time
21:32:38 <qoxncyha> okay, so in the scenario A -> B, one thread tries appending: A -> B -> C at the same time though, another thread sees A -> B, tries to pop B
21:33:34 <qoxncyha> this is similar to the linked list insertion problem
21:34:01 <qoxncyha> once you inspect if A's nextptr is null, it's already expired as it could have changed
21:35:00 <qoxncyha> if you use stamped references you can get around it, i see the utility of that
21:35:51 <geist> https://twitter.com/chancancode/status/992529084025528320
21:35:51 <bslsk05> twitter: <chancancode> is slack using all your power? no problem, I have discovered free energy https://video.twimg.com/ext_tw_video/992529025410072576/pu/vid/720x1280/1IaFUV1GmEyOtQkd.mp4?tag=3
21:36:36 <geist> sadly none of my computers are advanced enough to have this sort of tech
21:36:46 <qoxncyha> doug16k: the problem is, it requires a spinlock
21:38:26 <doug16k> consider this sequence of events: 1) thread A stores something to X - it goes into the store queue, 2) thread B reads X, sees null, 3) the store from thread A makes it through the store queue - the CPU will do a cache coherency broadcast to read for ownership, 4) the cache line in the CPU running thread B is sent over to the CPU running thread A, 5) thread A's store is written to the cache line
21:38:51 <doug16k> note that thread B didn't instantaneously, magically, see the store
21:39:53 <qoxncyha> doug16k: B would read X and see A's data, if B used the right memory ordering
21:40:57 <geist> what doug speaks of is very very true especially for weak memory model machines, like ARM
21:41:26 <geist> where there are essentially *no* guarantees that any writes are observable in any particular order from an external observer
21:41:41 <geist> or seen at all. they cansit in the write buffer forever
21:41:57 <geist> *unless* a memory barrier is emitted
21:42:12 <geist> or any nubmer of other things (like taking an interrupt) that causes an implicit memory barrier
21:42:21 <doug16k> x86 doesn't guarantee write-to-read ordering, it is already a race anyway
21:42:51 <doug16k> no matter how hard it tried, thread A could have started the store one cycle later and it would miss it anyway
21:44:50 <geist> oooooh this is some tasty drumming: https://youtu.be/l7gpXUp2J_0?t=2141
21:44:52 <bslsk05> 'Charlie Hunter & Carter McLean: 2018-04-08 - Nod Hill Brewery; Ridgefield, CT (Complete Show) [4K]' by mk devo (01:41:20)
21:44:58 <qoxncyha> if you have atomic CAS, A has to CAS once, and B has to spinlock on CAS
21:44:59 <geist> and my fave jazz guitarist
21:45:11 <qoxncyha> but it's guaranteed, i think?
21:45:24 <doug16k> x86 does guarantee writes are VISIBLE to other processors in program order. the other cpu might see all of them, some of them, or all of them
21:45:25 <doug16k> er, or none of them
21:45:27 <doug16k> but if it does see some, it will see some portion of them in program order. the other cpu won't see a later store done and an earlier store not done
21:45:30 --- join: NaNkeen (~nankeen@123.136.118.12) joined #osdev
21:46:46 <doug16k> CMPXCHG and XCHG and XADD are stronger, they will do read for ownership first, then update the line. they won't magically see stores pending in another processor's store queue though
21:47:19 <doug16k> but that won't be a problem if all accesses to that variable use something that strong to update it
21:47:28 * variable glares at doug16k
21:47:51 * geist accesses variable
21:48:00 * variable feels vindicated
21:48:36 <qoxncyha> doug16k: okay, so let's say we're only using strong atomic instructions
21:48:38 * doug16k reads variable's cache line for ownership
21:48:44 * variable is owned by NO ONE
21:48:57 <geist> keep keeps a dictionary of what's in variable's cache
21:49:18 <variable> geist: sometimes I use big words to make myself sound photosynthesis
21:49:21 <geist> oh found it: https://www.cs.vu.nl/~herbertb/download/papers/delta-pointers_eurosys18.pdf
21:49:26 <geist> kind of neat
21:49:27 <qoxncyha> in that case, we're good, right? B can read A's update to X safely
21:50:19 <doug16k> qoxncyha, yes but if you are doing that many locked memory accesses you might as well just use a lock
21:51:05 <qoxncyha> doug16k: okay. i did not know that load/store are not consistent even at the most stringent ordering
21:52:01 <doug16k> I don't want you to be afraid of memory ordering, I just want you to realize that atomic is not about instantly seeing results, it is more about the order that things occur or the order that writes become visible
21:52:15 <geist> and the order that things happen relative to the atomic
21:52:26 <geist> that's sort of important a lot of times too, re: spinlock for example
21:53:30 <qoxncyha> i understand that atomic instructions are not immediate, but are not loads and stores consistent, with seqcst?
21:55:01 <doug16k> consider this: 1) thread A writes 0 to X, 2) a bazillion cycles go by including serializing things like IRQ handling, 3) thread A writes 42 to X, and at the same time thread B reads X
21:55:41 <qoxncyha> that's UB, correct?
21:56:02 <doug16k> thread B will probably see 0. ok now consider thread A writes it a bit sooner. thread B might still see 0. if you keep considering thread A writing it earlier, at some point, thread A wrote it soon enough for thread B to pick it up
21:56:42 <doug16k> so what would be the point of the CPU trying super-hard to handle that? no matter how hard it tries, thread A might have wrote it a tiny bit later anyway
21:57:20 --- quit: freakazoid0223_ (Quit: I was standing in the park wondering why frisbees got bigger as they get closer. Then it hit me.)
21:57:43 --- quit: NaNkeen (Ping timeout: 264 seconds)
21:58:01 <doug16k> what CPUs do provide is a way to enforce that these writes are visible to other CPUs before those later writes
21:58:27 <doug16k> but the other cpus may see none of them, or some of them, or all of them, only ordering of the visibility of changes is enforced
21:58:49 --- join: NaNkeen (~nankeen@123.136.118.12) joined #osdev
21:58:58 <qoxncyha> so what you're saying is, the important part is internal consistency, meaning the multiple different atomic steps of a write/read happen in sequence
21:59:13 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
21:59:16 <qoxncyha> but across threads memory ordering is not guaranteed
21:59:34 <doug16k> consider C++ x = new Foo(). if another CPU is going to use x and no locks are used, then the write to x might be visible before the writes in the constructor
21:59:44 <doug16k> ^ on a weakly ordered processor
21:59:50 <geist> yah
22:00:13 <variable> I would not use the term "weakly ordered processor"
22:00:14 <doug16k> if you used store-release to store to x, then the cpu would guarantee that all the stores in the constructor are visible before the store to x is visible
22:00:20 <variable> since there are various definitions of "weakly ordered"
22:00:49 <variable> qoxncyha: this post http://preshing.com/20120930/weak-vs-strong-memory-models/ - and this blog in general will be really useful to you
22:00:50 <bslsk05> preshing.com: Weak vs. Strong Memory Models
22:00:57 --- quit: lachlan_s (Quit: Connection closed for inactivity)
22:01:01 <doug16k> and again, the other cpu might not see any of the stores (yet), from the constructor or to x
22:01:03 <geist> also wikipedia had a pretty good table
22:01:14 <qoxncyha> thanks, i will have more questions later no doubt.
22:01:23 <geist> the only weaker one than arm was alpha which apparently can be weak relative to itself (!!) in some cases
22:01:39 <variable> alpha is an amazing processor which we should all prais
22:01:39 <doug16k> :O
22:02:17 <geist> https://en.wikipedia.org/wiki/Memory_ordering has a table
22:02:18 <bslsk05> en.wikipedia.org: Memory ordering - Wikipedia
22:02:20 <qoxncyha> doug16k: that makes sense
22:02:35 <geist> 'dependent loads reordered' is pretty much whaaaa
22:02:50 <variable> geist: yes
22:03:11 <variable> I love how the alpha is literally the only one to do that
22:03:15 <geist> yah
22:03:46 --- quit: ALowther (Ping timeout: 260 seconds)
22:04:07 <geist> i haven't looked at it, but i suspect it showed up as an ia-64 style bit on load/stores where you can say 'theres no way this is going to be a problem if you read it in any sequence'
22:04:17 <geist> and it was a compiler decision to emit that or not
22:04:30 <geist> kind of makes sense
22:05:05 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
22:05:18 <variable> geist: http://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html
22:05:19 <bslsk05> www.cs.umd.edu: Reordering on an Alpha processor
22:05:57 <qoxncyha> so memory ordering is thread-local?
22:07:14 <variable> so, time to debug gdb
22:07:19 <variable> which is crashing with an internal error
22:07:22 <variable> trying to look at a vmcore
22:07:28 <variable> I hate computers
22:08:00 <doug16k> memory ordering is about the order that other cpus see the stores - enforcing that other processors see earlier loads before later loads, and enforcing that earlier loads are not done ahead of other loads that are issued later
22:08:31 <variable> strictly speaking, it is possible to have "memory ordering" issue on a single core single-thread CPU
22:08:42 <variable> but you'll rarely if ever see the term used that way
22:09:29 <qoxncyha> that's confusing.
22:09:35 <doug16k> DMA/bus-master memory accesses act as if "other processors" are accessing the memory
22:09:36 <qoxncyha> i am not sure i understand.
22:09:48 <geist> yeah ARM calls them 'external observers'
22:10:00 <geist> in some cases the MMU itself is an external observer
22:10:23 <geist> so you have to be careful about barriering page table updates prior to a TLB refill
22:10:30 <variable> I don't know for sure, but I vaguely remember hearing about some processors that have "fetch delay slots" akin to "branch delay slots"
22:10:46 <clever> i remember having to do a certain sequence of cache flushing any time i DMA'd data in or out of the rpi gpu, when i was writing drivers for it
22:10:49 <variable> then again, my brain might be making stuff up
22:10:58 <variable> clever: that's so .... clever
22:11:10 <geist> we actually bumped into a fairly agressive prefetching behavior on the arm just yesterday
22:11:15 <clever> https://github.com/cleverca22/v3d2/blob/master/v3d2.c#L82-L87
22:11:17 <bslsk05> github.com: v3d2/v3d2.c at master · cleverca22/v3d2 · GitHub
22:11:27 <geist> debugged it as adjacent cache lines to something getting pulled in at inopportune moments
22:11:32 <clever> i might have been overly paranoid with my memory barriers here, not sure
22:11:41 <variable> geist: have you seen the article about the "instruction that was too unsafe to exist" ?
22:11:42 <clever> i think those ones are just to prevent the compiler from re-ordering the opcodes
22:11:42 <geist> debugged it a bit and sure enough the a53 (which is pretty derpy) can actually prefetch 5 or 6 cache lines ahead
22:12:06 <variable> geist: https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/
22:12:07 <bslsk05> randomascii.wordpress.com: Finding a CPU Design Bug in the Xbox 360 | Random ASCII
22:12:08 <clever> oh, line 82 was some kind of cache flush operation i think?
22:12:21 <variable> fun bug
22:15:36 <clever> "but hey, we’re video game programmers, we know what we’re doing, it will be fine. Oops." lol
22:17:46 --- quit: NaNkeen (Ping timeout: 260 seconds)
22:17:53 <doug16k> I found a bug in X-Plane 11: if you do the navigation training, and just do aerobatics and high G turns instead of following the instructions, the game just disappears and you find youself staring at the desktop
22:18:26 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
22:18:29 <qoxncyha> does memory ordering refer to a single thread only, or all threads?
22:18:44 <qoxncyha> sorry to repeat
22:19:18 <doug16k> it enforces the order that other cpus see your writes, and the order that you see other cpu's writes
22:19:21 --- join: NaNkeen (~nankeen@123.136.118.12) joined #osdev
22:20:21 <clever> "So a speculatively-executed xdcbt was identical to a real xdcbt! ", oh, that makes sense, needs a compile-time if and inlining!
22:20:39 <doug16k> your question is ambiguous though. not sure what you mean exactly
22:21:12 <clever> if you inline the function with the if statement, and the condition of the if is a compile-time constant, the compiler can just delete the else block that never happens
22:21:12 <qoxncyha> can memory operations be reordered in a single thread?
22:21:23 <clever> and then the cpu cant mis-predict and prefetch the wrong way
22:21:26 <variable> qoxncyha: not typically
22:21:28 <doug16k> on x86? no
22:21:34 <qoxncyha> no?
22:21:36 <clever> or use #ifdef to hard-delete it
22:22:08 <variable> wow
22:22:15 <variable> how do I get gdb to generate a useful core dump
22:22:19 --- quit: eremitah (Ping timeout: 264 seconds)
22:22:20 --- nick: eremitah_ -> eremitah
22:22:31 --- quit: oaken-source (Ping timeout: 248 seconds)
22:23:10 <qoxncyha> okay, makes sense.
22:23:12 <doug16k> qoxncyha, the memory accesses will behave as though they are perfectly sequentially consistent to the code, regardless of whether it does any fancy speculation under the hood
22:23:23 <qoxncyha> doug16k: yes i was confused about that
22:23:38 <qoxncyha> thanks for clarifying
22:23:40 <doug16k> x86 will restart loads that it started too soon to completely isolate issues from you
22:24:06 --- join: oaken-source (~oaken-sou@tmo-096-222.customers.d1-online.com) joined #osdev
22:24:15 <doug16k> ...when it detects that it wouldn't have been sequentially consistent
22:25:01 <qoxncyha> cmpxchg respects seqcst cross-platform, so that's safe to use in multiple threads, correct?
22:25:44 <doug16k> you mean the gcc __sync_val_compare_and_swap intrinsic?
22:27:02 <qoxncyha> doug16k: i am using rust. i forget what the llvm instruction is for it
22:27:34 <doug16k> I have no idea how rust handles any of that
22:30:45 * variable is starting to get pissed at gdb
22:35:57 --- quit: dbittman (Ping timeout: 276 seconds)
22:41:44 --- nick: vaibhav -> vaibhav|afk
22:43:12 <qoxncyha> doug16k: AtomicPtr::compare_exchange(a, b, SeqCst, SeqCst) compiles to `%3 = cmpxchg i64* %2, i64 0, i64 0 seq_cst seq_cst` LLVM and `lock cmpxchgq %rcx, 8(%rsp)` x86
22:43:41 <qoxncyha> https://play.rust-lang.org/?gist=5ce02ea9726682ee96b63498666000c4&version=nightly&mode=release
22:43:43 <bslsk05> play.rust-lang.org: Rust Playground
22:44:17 <qoxncyha> my question is: is that thread-safe?
22:49:23 <qoxncyha> bbl
22:50:27 <variable> https://reviews.freebsd.org/P176
22:50:28 <variable> FML
22:50:28 <bslsk05> reviews.freebsd.org: ✎ P176 (An Untitled Masterwork)
22:50:43 <variable> I really don't feel like debugging gdb
22:50:47 <variable> at 11pm
22:53:19 --- quit: oaken-source (Ping timeout: 240 seconds)
22:55:12 --- join: oaken-source (~oaken-sou@p4FE2C58D.dip0.t-ipconnect.de) joined #osdev
22:57:53 --- join: andrei-n (~andrei@51.214-65-87.adsl-dyn.isp.belgacom.be) joined #osdev
22:59:22 <izabera> when do you feel like debugging it?
23:05:16 --- join: punch (5cdf50a6@gateway/web/freenode/ip.92.223.80.166) joined #osdev
23:08:20 --- join: r00tus3r (uid126983@gateway/web/irccloud.com/x-cfqxlxioxeogzilc) joined #osdev
23:16:39 --- quit: drakonis (Read error: Connection reset by peer)
23:20:05 <variable> izabera: never?
23:22:47 --- nick: vaibhav|afk -> vaibhav
23:24:42 --- quit: oaken-source (Ping timeout: 264 seconds)
23:30:06 --- quit: Affliction (Remote host closed the connection)
23:30:51 --- join: Affliction (affliction@2600:3c01::13:ffff) joined #osdev
23:31:06 --- quit: tux3 (Ping timeout: 255 seconds)
23:31:37 --- join: tux3 (~tux@cmdline.org) joined #osdev
23:41:27 --- quit: doug16k (Ping timeout: 248 seconds)
23:43:39 --- join: M_D_K (~M_D_K@voidi.ca) joined #osdev
23:45:31 --- quit: NaNkeen (Ping timeout: 268 seconds)
23:47:03 <izabera> then i feel like qualifying your previous statement with a time was pointless
23:57:33 --- join: m_t (~m_t@p5DDA0D02.dip0.t-ipconnect.de) joined #osdev
23:59:59 --- log: ended osdev/18.05.04