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=26
00:00:00 --- log: started osdev/18.05.26
00:01:00 --- quit: cirno_ (Remote host closed the connection)
00:01:27 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
00:04:31 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:10:53 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
00:19:48 --- quit: cirno_ (Ping timeout: 250 seconds)
00:20:54 --- join: xerpi (~xerpi@103.red-83-45-192.dynamicip.rima-tde.net) joined #osdev
00:23:20 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:29:08 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
00:31:00 --- quit: cirno_ (Remote host closed the connection)
00:34:27 --- quit: drakonis (Ping timeout: 240 seconds)
00:34:41 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:35:29 <variable> Its a three day weekend
00:35:31 <variable> so ofc I'm here
00:35:36 <geist> yep. same here
00:35:47 <geist> and once again i'm fiddling around with linux on the 386
00:36:09 <variable> geist: literal 386 ? or i386 ?
00:36:20 <geist> literal 386
00:36:32 <variable> cool
00:37:41 <geist> i found a more appropriate hard drive than the 200GB PATA drive i had floating around, so i swapped it
00:37:51 <geist> the 386 can't see more than 8GB of it anyway, so it was super overkill
00:37:59 <geist> found a 20GB drive i can use, so swapped it to that
00:38:18 --- quit: Mikaku (Quit: server maintenance ...)
00:38:45 <geist> the bios itself can only address up to 528 (1024/16/63), so you have the usual boot stuff must be in the first 500MB problem
00:39:19 <geist> but then linux does a more appropriate scan of the device, but linux 1.2.13 at the time apparently only knew about 16383 cylinders, which was the next PATA expansion, which comes out to 8GB
00:39:32 <_mjg_> nice
00:39:55 <_mjg_> going to mine bitcoin on this one?
00:40:02 <geist> hell ya
00:40:12 <variable> fewer rename registers (one of the biggest consumers of power),
00:40:14 <geist> it's surprisingly usable, really
00:40:17 <variable> does anyone know if this is true
00:40:23 <variable> and if so, a source?
00:40:26 --- join: Mikaku (~Mikaku@pdpc/supporter/active/mikaku) joined #osdev
00:41:15 <geist> it's possible. i remember there was a talk when the atoms first came out about how the lack of rename registers was a big win
00:41:38 <geist> something to the effect of even if you have a rename bank, passing around an index between the stages was either more or less power efficient
00:41:50 <geist> and so some designs either do the index or actually pass around copies of the register between the stages
00:42:27 <geist> presumably because the index though may be simpler, means you're going back and accessing the register file essentially on every stage, and that means you have to have a ton of ports on the register file
00:42:54 --- quit: Goplat (Remote host closed the connection)
00:43:02 <geist> and i think that may be one of those things where the circuitry to add more and more ports to the register file is a big deal
00:44:04 <variable> geist: makes sense
00:44:17 <geist> but then an atom doesn't have a register renamer propbably
00:45:39 <geist> https://en.wikipedia.org/wiki/Register_renaming#Architectural_vs_physical_registers has some talk about it
00:45:40 <bslsk05> en.wikipedia.org: Register renaming - Wikipedia
00:45:42 <geist> and seconds after it
00:48:35 <geist> i think it's the cost of the register file vs the cost of copying around large piles of data between stages
00:49:01 <geist> those are all latches that move data between stages, which makes up for a lot of the dynamic power usage of a cpu
00:49:30 <geist> if you're just passing a tag between stages (say 7 or 8 bits to refer to the register file) then thats a lot less than passing around 64bits or so
00:49:52 <graphitemaster> 8byte register renames on haswell are just a slop in a 64-byte register file, giving it 8 possible renames
00:50:11 <graphitemaster> which is to say that your rax register is actually a 64-byte unit
00:50:16 <graphitemaster> not an 8-byte unit
00:50:21 <geist> right
00:50:48 <graphitemaster> 64 turns out to be a good size since it's a cache line in size
00:50:55 <geist> wait. 64 what?
00:51:16 <graphitemaster> bytes
00:51:25 <geist> okay, i lost track of what you said then
00:51:55 <graphitemaster> haswell e, gprs are 8-byte but represented each by 64 byte register files, giving each gpr 8 possible renames
00:52:11 <graphitemaster> when you load something into a register, it loads a whole cache line into the full 64 byte register file
00:52:35 <geist> you mean architecturally load, or some internal thing? ie a mov instruction vs something in the pipeline?
00:52:41 <graphitemaster> architectually
00:52:42 <geist> unclear precisely at what level you're referring to
00:52:52 <graphitemaster> just explaining how the microarch internally works here
00:52:57 <graphitemaster> not how it's exposed from programming side
00:53:09 <geist> well, when i say 'architecturally load' i mean a mov instruction
00:53:22 <geist> so you're not talking about an architectural load
00:53:35 <graphitemaster> right, doing mov %reg, mem is actually a 64byte load into the register file that represents %reg
00:53:58 <graphitemaster> then it just gives you the 8 bytes you care about
00:54:08 <graphitemaster> or, 4 bytes you care about
00:54:11 <graphitemaster> or 2 bytes you care about
00:54:16 <graphitemaster> or 1 byte you care about :P
00:54:26 <geist> this doesn't make any sense. so you're saying it essentially prefetches the 64 bytes around your load into 7 other registers in the register file with the idea that you may need it?
00:55:14 <graphitemaster> well it does not prefetch, there is no way for the architecture to load anything but 64 bytes from memory, there is no smaller or larger unit
00:55:24 <geist> sure but it could be free to discard it
00:55:43 <graphitemaster> it loads the full 64 bytes into a register file that represents the register (every register is 64 bytes in size)
00:55:45 <geist> so you're saying that even if you only wanted one register load it loads 8 registers around it?
00:55:53 <graphitemaster> but then it gives you an alias in that file
00:56:02 <geist> oh. really? that seems highly inefficient
00:56:07 <graphitemaster> and will rename on demand
00:56:07 <geist> what would be the use case for that?
00:56:16 <graphitemaster> iterating an array of integers?
00:56:26 <geist> now your register file is 8 times the size
00:56:26 <graphitemaster> you have all of it prefetched
00:56:30 <variable> geist: graphitemaster: I just wanted to let you know that I've changed my privacy policy
00:56:49 <geist> variable: that's fantastic. let me unsubscribe from your site
00:57:03 <graphitemaster> geist, x86 does not care, their entire SIMD state is a massive register file too
00:57:21 <geist> so you say this is a haswell e thing?
00:57:26 <graphitemaster> it turns out you can make this very efficent
00:57:34 <geist> i'm a little surprised there, since in general haswell wasn't that much of a diff from previous gens
00:58:19 <graphitemaster> this microarch change was a requirement for tsx
00:58:25 <geist> that seems like a substantial enough feature that agner and whatnot would have picked up on it
00:58:29 <geist> hmm
00:58:52 <graphitemaster> it's not really a feature
00:58:57 <graphitemaster> since none of it is exposed or visible
00:59:28 <geist> well, you say it should improve performance of loops and whatnot if detects that you're walking through memory and can reuse the existing register file load
00:59:52 <graphitemaster> the overhead of the mechanism probably outweighs its benefits
01:00:07 <graphitemaster> but it gives you a simpler architecture, so better for power
01:00:09 <geist> yah, i can see it being some requirement for TSX,b ut otherwise not really being worth it
01:00:12 <graphitemaster> and some tsx stuff
01:00:35 <graphitemaster> you have only one fundamental unit to worry about in the whole microarch now
01:00:39 <graphitemaster> the cache line
01:00:44 <geist> oh that reminds me, i read some thing the other day that the new skylake big xeons switched away from the ring topology
01:00:50 <graphitemaster> and all operations are cache line sized
01:00:58 <geist> they now use some sort of row/column grid thing
01:01:00 --- quit: cirno_ (Remote host closed the connection)
01:01:06 --- join: Kazinsal_ (~Kazinsal@unaffiliated/kazinsal) joined #osdev
01:01:31 <geist> ie, a 6x6 row/column interlink with some of the squares used up with things like memory controllers and PCI links
01:01:49 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
01:01:59 <graphitemaster> I got a new phone today
01:02:03 <geist> https://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/5 which is regurgiating some intel slides
01:02:04 <bslsk05> www.anandtech.com: Intel's New On-Chip Topology: A Mesh - Sizing Up Servers: Intel's Skylake-SP Xeon versus AMD's EPYC 7000 - The Server CPU Battle of the Decade?
01:02:54 <graphitemaster> the _exact_ same one as my _old_ phone except without a broken screen, only problem is this particular phone has two possible CPUs, the snap dragon 835 or the Exynos 8895
01:02:55 <variable> graphitemaster: what kind of phone?
01:03:14 <variable> what's the difference?
01:03:23 <variable> and what's the phone
01:03:27 <variable> (I have a OG pixel)
01:04:00 <graphitemaster> well my old phone had the Exynos, which I looked for because it has slightly betyter performance and battery life (smaller manufacturing process)
01:04:12 <graphitemaster> but when I sent my phone in for warrenty, I got a replacement with the 835
01:04:16 <graphitemaster> and I'm upset
01:04:21 --- quit: Kazinsal (Ping timeout: 245 seconds)
01:04:28 <graphitemaster> I spoke to them and there is nothing they can do.
01:04:44 <graphitemaster> They do not gurantee that the replacement phone has the exact same hardware as the original.
01:04:58 <graphitemaster> Samsung Galaxy S8+
01:07:12 <geist> ah interesting, the skylake die shots look exactly like those mesh diagram
01:07:51 <graphitemaster> also, I can't believe a chipped corner is enough to cause the entire screen to go nuts
01:08:12 <graphitemaster> https://drive.google.com/open?id=17DFMlznwM2b3VM0AAa6FkT2T8mhW5ENR
01:08:13 <bslsk05> drive.google.com: VID_20180518_221632.mp4 - Google Drive
01:08:27 <geist> braniff: believe it
01:08:46 <graphitemaster> who is braniff
01:08:55 <geist> believe it!
01:09:19 <geist> https://www.youtube.com/watch?v=Z-EbALVUvfI
01:09:20 <bslsk05> 'BRANIFF' by Guy Incognito (00:00:04)
01:09:44 <graphitemaster> your meme is too old
01:09:44 <geist> basically the south park guys put that at the end of every ep as a joke, because it was an old defunct airline from the 70s
01:10:07 <graphitemaster> anyways, Android chokes when you restore everything from backup
01:10:21 <graphitemaster> and by choke I mean the play store loses its shit and gets all confused
01:10:28 <geist> Android chokes when you *
01:11:03 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
01:11:11 --- join: zeus1 (~zeus@197.239.32.35) joined #osdev
01:11:45 <graphitemaster> well that's why I get the fastest possible phone and then enable developer options to turn off all animations and animation delays, then grab cpu-z, and service disabler, disable all services but the ones I need, using cpu-z to profile, then drop it to a root shell, kill the cpu watchdog service, and scale it up, then force GPU on everything for all compositing and disable HW overlays
01:11:49 <graphitemaster> then nothing chokes
01:12:04 <geist> yeah feed it more Gibsons
01:12:30 <graphitemaster> then grab a steak knife, puncture the litium ion battery and throw the phone at my enemies
01:12:33 <graphitemaster> on air planes
01:12:57 <geist> this is hwo u win teh internet
01:15:57 <graphitemaster> I just watched a hydralic press video where they pressed a diamond
01:16:08 <graphitemaster> and the thing just chewed itself into the steel
01:16:13 <graphitemaster> without a fucking scratch
01:16:19 <graphitemaster> diamonds are cray cray
01:16:32 <geist> and they're forever
01:17:13 <graphitemaster> and artificially inflated, and not rare, and can be lab made, and are full of conflict and would be great insulators for electronics if they were not completely run by mafia companies
01:17:29 <geist> and made of blood
01:17:36 <geist> there's a lot of C in blood
01:17:42 <graphitemaster> ever see that non-conflict free diamond ad?
01:18:25 <graphitemaster> https://www.youtube.com/watch?v=gk7rCLwBmM8
01:18:25 <bslsk05> 'Unfair Trade' by Dumbest of All Worlds (00:00:30)
01:18:26 * geist can't think of a pun
01:19:11 <graphitemaster> one of my favorite channels, the history of crime is great too
01:19:16 <graphitemaster> https://www.youtube.com/watch?v=tGm7lpik1cA
01:19:17 <bslsk05> 'A Brief History Of Crime' by Dumbest of All Worlds (00:01:53)
01:23:38 --- join: raiz (~root@fardan.info) joined #osdev
01:24:07 --- quit: AverageJ0e (Ping timeout: 264 seconds)
01:25:02 --- join: Kimundi_ (~Kimundi@i577A946F.versanet.de) joined #osdev
01:26:33 --- join: amistillalive (~grandmaag@121-55-200-228.d.c200.guam.net) joined #osdev
01:28:02 <amistillalive> now graphitemaster made some real sense once again, what you described what x86 does in hw, is exactly what i explained doing on a gpu with addressspace tracer, which changes traced operands into private arrays!
01:28:43 <geist> oh great.
01:30:33 <bauen1> > people who commit the most crimes are considered president in many countries
01:30:58 --- quit: cirno_ (Remote host closed the connection)
01:31:36 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
01:38:40 --- quit: cirno_ (Ping timeout: 250 seconds)
01:40:16 --- quit: variable (Quit: /dev/null is full)
01:44:33 --- join: Asu (~sdelang@AMarseille-658-1-29-65.w86-219.abo.wanadoo.fr) joined #osdev
01:45:15 --- quit: awang (Ping timeout: 268 seconds)
01:53:05 --- quit: hmmmmmm (Remote host closed the connection)
02:05:03 --- quit: amistillalive (Remote host closed the connection)
02:16:35 --- quit: bauen1 (Remote host closed the connection)
02:19:10 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
02:20:35 --- quit: Amaan (Quit: Connection closed for inactivity)
02:20:37 --- quit: doug16k (Read error: No route to host)
02:21:59 --- join: amistillalive (~grandmaag@121-55-200-228.d.c200.guam.net) joined #osdev
02:27:28 --- join: `Guest00000 (~user@37.113.160.44) joined #osdev
02:27:48 --- join: m3nt4L (~asvos@2a02:587:a001:6900:3285:a9ff:fe8f:665d) joined #osdev
02:30:31 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
02:36:09 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
02:36:59 --- quit: m3nt4L (Remote host closed the connection)
02:39:50 --- join: GeDaMo (~GeDaMo@unaffiliated/gedamo) joined #osdev
02:42:23 --- quit: amistillalive (Remote host closed the connection)
02:44:45 --- quit: booyah (Read error: Connection reset by peer)
02:45:55 --- join: booyah (~bb@193.25.1.157) joined #osdev
02:46:39 <bauen1> has anyone here evere messed with the UHCI for a mac ?
02:47:02 <geist> not on a mac no
02:47:22 <geist> what kind of mac is this? if it's uhci it must be a pretty old one
02:48:09 <bauen1> Its an old black-macbook, older than 2010 I think
02:48:18 <geist> but x86 i assume?
02:48:20 <bauen1> yes
02:48:36 <geist> i think all the ppc ones were ohci based anyway
02:49:55 --- quit: JusticeEX (Ping timeout: 264 seconds)
02:49:58 --- join: glauxosdever (~alex@ppp-94-66-45-89.home.otenet.gr) joined #osdev
02:54:02 <geist> i used to have one of those black macbooks. it was a nice little thing
02:55:53 --- join: sympt (~sympt@209.58.135.120) joined #osdev
02:58:55 --- quit: sympt_ (Ping timeout: 264 seconds)
02:58:57 --- join: amistillalive (~grandmaag@121-55-200-228.d.c200.guam.net) joined #osdev
03:01:23 --- quit: elevated (Quit: bye)
03:02:46 --- join: m_t (~m_t@p5DDA0C92.dip0.t-ipconnect.de) joined #osdev
03:08:02 --- join: promach__ (~promach@2001:e68:4427:94e4:d26c:21ca:18b3:9623) joined #osdev
03:08:12 --- nick: promach__ -> promach2
03:11:55 --- quit: amistillalive (Quit: Leaving)
03:14:37 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
03:22:46 --- join: dijksterhuis (~dijksterh@cpc103046-sgyl39-2-0-cust267.18-2.cable.virginm.net) joined #osdev
03:22:51 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
03:24:32 --- quit: zeus1 (Ping timeout: 268 seconds)
03:30:29 --- join: tacco| (~tacco@i59F4D73A.versanet.de) joined #osdev
03:32:14 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
03:40:01 --- quit: NaNkeen (Ping timeout: 256 seconds)
03:40:07 --- quit: dijksterhuis (Quit: Mutter: www.mutterirc.com)
03:41:34 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
03:42:15 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
03:47:22 --- quit: Tazmain (Quit: Leaving)
03:47:45 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
03:52:18 --- quit: Tazmain (Client Quit)
03:53:55 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
03:57:48 --- quit: ljc (Remote host closed the connection)
03:58:35 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
04:01:41 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
04:01:57 <Sjors> hmm
04:02:02 <Sjors> I'm writing ATA write support
04:02:34 <Sjors> the write itself seems to succeed, then the wiki tells me to flush the cache
04:02:52 <Sjors> before flushing cache the SRV and RDY bits are set in the ATA command byte; after flushing, even after a while, RDY and BSY are both set
04:02:56 <Sjors> BSY never clears
04:05:19 <Sjors> although, the Wiki does not specify whether to flush the cache using FLUSH CACHE (0xe7) or using FLUSH CACHE EXT (0xea) when using LBA48 mode
04:07:06 --- quit: froggey (Ping timeout: 256 seconds)
04:09:48 <Sjors> according to the ATA standard, FLUSH CACHE works for LBA48 as well
04:09:51 <Sjors> "If the device supports more than 28 bits of addressing this command shall attempt to flush all the data in the volatile cache"
04:11:28 <Sjors> FLUSH CACHE EXT is only useful if an error occurs, then the returned LBA where the error occurred is valid
04:11:34 --- join: amistillalive (~grandmaag@S010690b134fc2cbf.vc.shawcable.net) joined #osdev
04:11:59 --- join: mra90 (~Martin@host-85-202-159-241.sta.tvknaszapraca.pl) joined #osdev
04:14:11 --- quit: JusticeEX (Ping timeout: 260 seconds)
04:14:40 <amistillalive> anyways graphitemaster the aliasing of regs, is actually implemented as a simple multiplexer for miaow it is a call to mux_256x32b_to_1x32b mux_rd_port_0 in reg_256x32b_3r_1w.v , and as you said it will just multiplex in miaow case 256x 32bits, cause that is formation of 4vectors that of 64 32bits values
04:14:57 <amistillalive> however on cpu it could be 64bytes instead as you said
04:15:08 --- quit: awang (Ping timeout: 245 seconds)
04:17:13 <amistillalive> three points out of three this time given to graphitemaster for helping out with explanations, we could yeah say that to be aliasing of register file, but in verilog terms this is a serial multiplexer
04:17:20 <bauen1> what i'm also not entirely sure is how you get the UHCI to generate a interrupt when a device is connected to one of the ports
04:18:26 --- join: Shikadi (~Shikadi@cpe-98-10-34-205.rochester.res.rr.com) joined #osdev
04:19:00 <amistillalive> and basically it's soul mission is to detect in that mux, whether it is a pointer, and then multiplex stuff to hold more values
04:19:34 <latentprion> *sole
04:22:29 <Shikadi> solar*
04:22:33 <Shikadi> no wait
04:23:26 --- quit: xerpi (Quit: Leaving)
04:26:43 <Sjors> any ideas why the BSY bit never clears as response to the CACHE FLUSH EXT command in ATA?
04:31:43 <Sjors> I've checked code in some other kernels and they look like this shouldn't occur
04:37:11 <bcos_> Oh my..
04:37:27 <bcos_> Sjors: "NOTE - This command may take longer than 30 s to complete."
04:38:03 <Sjors> bcos_: mm, I realized that, but this is taking minutes, while it's running in qemu on a disk image on an SSD
04:38:07 <bcos_> ..also looks like you need to check if the "PACKET Command feature set" is implemented
04:38:10 <Sjors> bcos_: so I doubt it's actually really still ongoing
04:38:55 <Sjors> isn't CACHE FLUSH EXT a mandatory command for all ATA devices?
04:39:20 <bcos_> No
04:40:01 <Sjors> section 4.2 of the standard
04:40:04 <bcos_> CACHE FLUSHE EXT is mandatory for devices that support 48-bit LBA, but 48-bit LBA is not mandatory so..
04:40:09 <Sjors> FLUSH CACHE is mandatory
04:40:12 <Sjors> EXT not indeed
04:40:18 <Sjors> but FLUSH CACHE has the same behaviour for me
04:40:37 <Sjors> it's mandatory if writing is supported on the device (which it is, the writes themselves are working)
04:41:30 --- quit: Asu (Ping timeout: 252 seconds)
04:41:40 --- join: Asu` (~sdelang@182.43.136.77.rev.sfr.net) joined #osdev
04:41:45 <bcos_> FLUSH CACHE is optional for devices implementing the PACKET Command feature set (which is why you'd check if that feature set is supported first)
04:41:53 <Sjors> ah, right, hmm
04:42:14 <Sjors> that's for ATAPI devices, right?
04:42:24 <bcos_> Yes
04:42:32 --- join: SlyFawkes (5166c138@gateway/web/cgi-irc/kiwiirc.com/ip.81.102.193.56) joined #osdev
04:42:32 <bcos_> (I think)
04:42:47 <Sjors> this isn't an ATAPI device anyhow
04:42:55 <Sjors> I checked for that
04:42:57 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
04:43:01 <amistillalive> i have to go myself, but on gpu, maximum array can be as many of CU's and hence SIMD's a chip has, cause there are opcode flops that are also like private and persistent regfiles in two states, lsu and alu states
04:43:06 <bcos_> Sjors: Checked how?
04:43:33 <amistillalive> hence it can move the same opcode to the same slot at one time, and if it is not a pointer then it can use the default opcode
04:43:48 <Sjors> bcos_: ran an IDENTIFY command according to the osdev wiki
04:43:54 <bcos_> Ah - cool
04:44:07 <Sjors> so it's not that...
04:44:22 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
04:45:26 <bcos_> Hrm. Does it behave similar in other computers?
04:46:04 <Sjors> I've only checked qemu tbh
04:46:10 <Sjors> can try running it in VirtualBox
04:46:20 <amistillalive> on CPU on the other hand, allthough i do not know for sure, this has to be done manually probably, so one cpu thread executes one part of the code or loop, and another thread another, they are of course async so this is how it goes, i won't go into details about TLS and other stuff
04:46:21 <Sjors> I've never, in the 3 years of its development, booted it on actual hardware
04:46:22 <bcos_> That'd be my next step
04:46:50 <bcos_> Sjors: Either that; or work on the error path - e.g. add a time-out, try to figure out how to recover, maybe add "device is faulty" state
04:47:26 --- quit: awang (Ping timeout: 256 seconds)
04:48:03 <bcos_> Sjors: That sounds "dangerous" - first time you boot on real hardware you'll probably find lots of problems - much easier to fix problems one at a time (as they're created) rather than being swamped.. ;-)
04:48:07 <Sjors> myeah, I think I'll do that if I'm sure it's an actual device error
04:48:19 <Sjors> yeah I know
04:48:29 <Sjors> I intend to, at some point
04:48:48 <Sjors> I do have it running on qemu, virtualbox and bochs and all three of them raised interesting differences
04:49:24 <bcos_> I'd want some generic framework for faulty hardware anyway - even if the currently problem is just a typo/mistake in your code it's a good excuse to test the "faulty hardware" handling
04:50:38 <amistillalive> also bare in mind, that on gpu addressspace tracer is for every unique source and dest reg detection, cause every reg is unique cause it will actually me a sum of the base and reg encoded, and later decoded again, where base is unique
04:51:26 --- quit: xenos1984 (Ping timeout: 245 seconds)
04:53:26 <bcos_> D'oh
04:54:07 <bcos_> Sjors: I'm using "ATA//ATAPI-6" for a reference - I have no idea if these commands were mandatory or optional (or non-existent) in earlier versions of the spec
04:54:11 --- join: user10032 (~Thirteen@2a02:c7d:314e:b300:98e:a154:9dd3:670e) joined #osdev
04:54:43 --- quit: NaNkeen (Ping timeout: 260 seconds)
04:54:56 --- join: m3nt4L (~asvos@2a02:587:a001:6900:3285:a9ff:fe8f:665d) joined #osdev
04:55:50 <Sjors> bcos_: that's from 2002, the document I was using was from 2008, but it looks like they have versions as of 2017 as well: http://www.t13.org/Standards/Default.aspx?DocumentType=3&DocumentStage=2
04:55:52 <bslsk05> www.t13.org: Technical Committee T13 AT Attachment
04:56:21 <bcos_> Sjors: Checking "ATA 1" now, and it looks like the command didn't exist back then
04:57:00 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
04:57:00 <Sjors> well the command does exist, I see the status change after using it
04:57:06 <Sjors> from SRV/RDY to RDY/BSY, no errors
04:57:27 <Sjors> it's like the device is waiting for more input, like the LBA address to flush
04:57:32 <Sjors> but I don't see any other kernel sending that
04:57:43 <Sjors> plus, the command is intended to flush everything, so..
04:58:03 <amistillalive> and so i go, about security i am sorry to say to those estonian lunatics who may not understand how things function, however izaberazas powerhammer pdf, might had made some monkeys to understand
04:58:21 <amistillalive> izabera's
04:58:22 <amistillalive> bye
04:58:27 --- quit: amistillalive (Quit: Leaving)
04:59:01 --- join: froggey (~froggey@unaffiliated/froggey) joined #osdev
04:59:22 <bcos_> Hrm
04:59:55 <bcos_> Sjors: Cache flush didn't exist in ATA-3 and older; but does exist in ATA-5 and newer. I don't think I have ATA-4 here..
05:00:39 --- join: regreg (~regreg@85.121.54.224) joined #osdev
05:01:12 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-fzlrvgfvdtlmbonz) joined #osdev
05:01:30 <lachlan_s> I'm honestly not a big fan of python
05:03:05 <bcos_> lachlan_s: I like chocolate!
05:06:27 --- quit: m3nt4L (Remote host closed the connection)
05:06:29 <bcos_> Sjors: Might be worth trying a different "non-data" command, like maybe NOP
05:06:43 <bcos_> ..just to make sure you're sending/handling the command right
05:08:35 <lachlan_s> Me too!
05:08:56 <promach2> bcos_ Mutabah _mjg_ Could you comment on http://forum.xillybus.com/viewtopic.php?f=4&t=588&start=10#p1602 ?
05:08:57 <bslsk05> forum.xillybus.com: The Xillybus Forum • View topic - problem with user_w_write_128_wren
05:09:47 <promach2> It ended up that it could be problem with allwrite() , I suppose ? https://gist.github.com/promach/9d185d35a6e6db0da10992a19c36f754#file-host-cpp-L256
05:09:49 <bslsk05> gist.github.com: C++ test code of HLS computation kernel for both Xillybus and RIFFA PCIe framework · GitHub
05:10:35 <Sjors> bcos_: ah good one, I'll try
05:13:20 <bcos_> promach2: A silly idea, but.. Are you using the right Linux driver? Would be funny if you're using a driver for a device that has a larger FIFO but your device has a smaller FIFO, so the driver borks up the flow control and..
05:22:05 <promach2> bcos_ : see the last section of http://xillybus.com/pcie-download
05:22:06 <bslsk05> xillybus.com: Download Xillybus for PCIe | xillybus.com
05:22:28 <promach2> Xillybus works out of the box with certain Linux distribtions, e.g. Ubuntu 14.04 and later. Also, Xillybus' driver is included in Linux kernel sources from 3.12.0 and later
05:23:17 <promach2> my system "uname -a" is giving
05:23:19 <promach2> Linux UbuntuHW15 4.13.0-36-generic #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
05:23:22 <promach2> bcos_
05:23:57 <bcos_> Heh, for Linux, "works out of the box" is typically a rare/temporary thing :-)
05:24:30 <bcos_> (quickly followed by something like "Oh crap, I updated and now everythign is broken")
05:24:31 <bcos_> :-)
05:24:55 <promach2> I really did not install anything
05:25:01 <promach2> it just works out of the box
05:25:02 --- quit: tacco| ()
05:26:05 <bcos_> It works? Your forum post made it sound like the user_w_write_128_wren signal which does not get asserted HIGH even though there are many more pixels bytes fed into the write()
05:27:03 <promach2> so, I could only blame linux driver ? I still doubt if I made some minor silly mistakes in my own coding
05:28:45 <bcos_> I don't know how much of the FPGA is user-configurable
05:31:58 <bcos_> ..but..
05:33:23 <bcos_> Hrm. I'm "relatively insistant" on good quality fault handling in device drivers and would be tempted to blame the driver (e.g. for failing to report "device is not responding") regardless of how badly the user's FPGA code screws things up
05:34:26 <bcos_> *insistent
05:34:36 <promach2> let's wait for the forum moderator reply.
05:35:05 <promach2> I guess I made some stupid mistake in my fpga code
05:36:16 <bcos_> Maybe
05:37:03 <bcos_> ..I don't know enough about the device, but I thought you were mostly just using their "DMA core" and it'd be their core that controls the low-level transfer
05:38:26 <bcos_> (and it'd be their core or their driver, that fails to detect/report "device not responding to write in a timely manner", and their driver that fails to make "write()" return with a suitable error code)
05:39:42 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
05:45:48 --- quit: JusticeEX (Ping timeout: 256 seconds)
05:49:06 --- join: sympt_ (~sympt@209.58.135.72) joined #osdev
05:51:45 --- quit: Lucretia (Remote host closed the connection)
05:52:03 --- quit: sympt (Ping timeout: 276 seconds)
05:52:34 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
05:53:34 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
05:54:03 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
06:14:21 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
06:16:43 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
06:17:17 --- quit: banisterfiend (Client Quit)
06:26:02 --- quit: xenos1984 (Ping timeout: 256 seconds)
06:32:55 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
06:37:52 --- join: MDude (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
06:44:50 --- join: tacco| (~tacco@i59F4D73A.versanet.de) joined #osdev
06:48:47 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
06:54:44 --- quit: ALowther (Remote host closed the connection)
06:55:18 --- join: ALowther (~alowther@2600:1:d20b:5c65:9055:f8c3:5b8f:97af) joined #osdev
07:00:30 --- join: ALowther_ (~alowther@68.200.236.134) joined #osdev
07:03:59 --- quit: ALowther (Ping timeout: 260 seconds)
07:08:32 --- quit: MDude (Ping timeout: 256 seconds)
07:10:44 --- join: S_Gautam (~bc2010asd@59.182.254.198) joined #osdev
07:11:18 --- join: MDude (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
07:12:00 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
07:14:40 --- quit: promach2 (Ping timeout: 256 seconds)
07:17:07 --- quit: S_Gautam (Changing host)
07:17:07 --- join: S_Gautam (~bc2010asd@unaffiliated/gautams) joined #osdev
07:17:42 --- quit: awang_ (Ping timeout: 252 seconds)
07:28:56 --- quit: AntiSpamMeta (Remote host closed the connection)
07:33:52 --- join: daniele_athome (~daniele_a@5.170.121.66) joined #osdev
07:36:24 --- join: amistillalive (~grandmaag@S010690b134fc2cbf.vc.shawcable.net) joined #osdev
07:39:33 --- quit: m_t (Quit: Leaving)
07:40:11 --- join: amistillalive1 (~grandmaag@83.246.170.102) joined #osdev
07:41:19 --- quit: daniele_athome (Ping timeout: 240 seconds)
07:41:51 --- quit: lucebac (Ping timeout: 260 seconds)
07:41:54 --- quit: amistillalive (Ping timeout: 252 seconds)
07:42:09 <amistillalive1> bauen1: hmm, my grannies uncle was second nose during the first republic, but... the assaults come from the first nose of soviet union, primarly by his delusional daughter, soviets chosen first communist nose curator in the district of estonia back then
07:42:32 <amistillalive1> i also had another main source of bans and assaults, which was another chick
07:43:48 <amistillalive1> now i was even tried to be framed on my brothers death on the streets, and also my best female friend was killed, i am planning a bit of tricks on my own too, to those people
07:45:36 <S_Gautam> well, the soviets have been dead for about 30 years now.
07:45:41 <S_Gautam> also this is #osdev
07:46:02 --- join: daniele_athome (~daniele_a@5.170.124.232) joined #osdev
07:46:07 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
07:50:34 <amistillalive1> unfortunently he as also an ex large stake holder in one of the biggest banks with all his conspirying moran important clueless noses, who maniupulate people today around the world, are still alive
07:57:36 <amistillalive1> as my father saw conflicts with such, saying congratulations now your life is spent in large degree in the institution, but i have second thoughts, i just kill them off, i have 20-30 names playing big role in this corruption
07:58:07 <bcos_> Can you give us these names?
07:58:36 <bcos_> It'd be useful, because at this point helping them murder you seems like the only way to stop your frequent burst of irrelevant shit
07:59:08 --- quit: NaNkeen (Ping timeout: 252 seconds)
08:03:57 <amistillalive1> i can handle you too...
08:04:09 <amistillalive1> i have bigger roof anyways then a communist shithole
08:04:34 <bcos_> I guess, as long as you buy me a nice box of chocolates first...
08:04:52 --- join: lucebac (~lucebac@lucebac.net) joined #osdev
08:04:52 --- quit: lucebac (Changing host)
08:04:52 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
08:04:57 <amistillalive1> you want to present as hero here, but unlike graphitemaster you have no sane sentences to show
08:05:07 <amistillalive1> much of a delusional gibberish
08:05:22 <amistillalive1> mainly entitled to estonian cockblockers level
08:05:31 <amistillalive1> yes, the names will be given to the world
08:05:46 <Sjors> geist: did you have a giant banhammer or do you know who does?
08:06:09 <glauxosdever> amistillalive1: We would prefer the GPU stuff, ok?
08:06:09 <amistillalive1> they will be sent both to wikipedia and also my autobiagraphy along with what every name did to me
08:06:22 <Sjors> amistillalive1: it's been pointed out before, but I'm going to give it one more shot: we are not interested in this story in this channel
08:06:23 <bauen1> amistillalive1: you using tor ?
08:06:47 <Sjors> amistillalive1: keep it ontopic. the CPU/GPU stuff was fine
08:07:55 --- join: promach2 (~promach@2001:e68:4427:94e4:d26c:21ca:18b3:9623) joined #osdev
08:08:36 <amistillalive1> well there is not much to discuss, i tried to say all of what was on my mind, it is very easy, i am unsure if there is a patent filed
08:09:06 <amistillalive1> for this i tried to hire a lawyer, but she turned out to be one of the consiprators friend
08:09:49 <amistillalive1> most likely wanting to hijack my ideas once again, i better off give it to public domain
08:10:39 --- join: Amaan (uid4967@gateway/web/irccloud.com/x-iirwlcaywnfjqxny) joined #osdev
08:10:50 <glauxosdever> We are not lawyers here either, we can't do anything about conspirators either. But yes, I wish research was public domain and not locked-in by various "prestigious" journals and conferences
08:12:10 <amistillalive1> well actually on cuda and opencl this can be done, multiple parallel iteration of the same instruction, but in graphics this ain't gonna work out by default, but can be done on any gpu that has programmable shading
08:13:11 <glauxosdever> What exactly can be done?
08:14:32 <amistillalive1> well when you looked at this parallel 1024-bit arithmetic thread, then there it was used in such manner
08:14:37 <amistillalive1> wait i get you the link
08:15:16 <glauxosdever> Oh, that one. Don't assume people remember what you were talking about earlier
08:15:16 <amistillalive1> http://on-demand.gputechconf.com/gtc/2012/presentations/S0221-1024-Bit-Parallel-Rational-Arithmetic-Operators-for-the-GPU.pdf
08:15:19 --- quit: Asu` (Read error: Connection reset by peer)
08:15:42 <amistillalive1> well the thing is it works on arrays there, cause cuda has addressspace concept
08:16:21 <amistillalive1> but before you get good framerates, insane ones and on low-power on programmable glsl shader
08:16:34 <amistillalive1> you need to flesh out an addressspace with a little of code
08:16:46 <glauxosdever> These slides look messed up..
08:17:29 <glauxosdever> I can see some things about particles inside there
08:19:14 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
08:19:28 <S_Gautam> I thought there were only 17 particles as per the Standard Model.
08:19:47 <S_Gautam> When computer scientists try to use physical analogies...
08:20:46 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
08:20:57 <glauxosdever> Seems they are biomedics-oriented
08:21:20 <amistillalive1> well for fleshing out an address space, you need to use mubuf lsu load to contiguous set of registers, followed by a mov that reads those registers and writes to somewhere, mov is whole-array operation
08:21:33 <amistillalive1> what happens then is, when the hw scheduler
08:22:23 <amistillalive1> sort of like has one instruction in a readback stage, this lane will be reflected back to the address space, which has in slot 1 in execution stage hijacks the it, and changes the
08:22:36 --- quit: drakonis (Ping timeout: 252 seconds)
08:22:55 <amistillalive1> private reg to an array, and later that following instruction will fetch the new content and execute on an array
08:23:00 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
08:23:22 --- quit: drakonis_ (Read error: Connection reset by peer)
08:23:34 <amistillalive1> which combined with putting wavefronts later into sleep, for an example with using dirty bit, lsu intentional stalling or just commands per hw
08:23:39 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
08:24:03 <amistillalive1> starts to use the frozen fifos to execute the commands, it is twice as fast per every instruction
08:24:29 --- join: drakonis__ (~drakonis@unaffiliated/drakonis) joined #osdev
08:24:32 <amistillalive1> low power, and the performance is how many pixels you render at a time, which is limited to how much resources you have
08:24:53 <glauxosdever> If I understood you correctly, that's a two-stage pipeline?
08:25:41 <amistillalive1> actually it is something like 7-8 i think by default, but when wavefronts go to sleep, it's yeah around 3-4 or two
08:25:56 <amistillalive1> readback writeback and execution and dispatch 4 then
08:26:11 <amistillalive1> fetch, decode, schedule are ignored
08:27:16 --- quit: drakonis (Ping timeout: 245 seconds)
08:27:32 <glauxosdever> Pipeline stages shouldn't change (unless I'm misunderstanding GPUs). It's more likely the acceleration because of pipelining decreases?
08:28:28 --- quit: drakonis_ (Ping timeout: 265 seconds)
08:29:52 <amistillalive1> glauxosdever: they do sleep in this case, they stall, this can be controlled as said by either stalling with errornous instruction decoded in the hotspot
08:30:02 <amistillalive1> intentionally putting lsu in a stall loop
08:30:12 <amistillalive1> or with hw commands to make wavefronts to sleep/halt
08:30:49 <amistillalive1> those stages are pretty deep, slightly deeper then the 4that remain, those that go to sleep
08:35:32 <amistillalive1> why this at all works in hw, was that spec of glsl and fragment program definers, were smart to force that on, with a feature called indirect texture load
08:36:00 <amistillalive1> where indices can be feed from another result array of another load back to reload the stuff from memory
08:36:28 <amistillalive1> deisgners of the api mandated all, that it would be possible, and it is overlayd entirely perfectly
08:36:48 <amistillalive1> there are two ways to define the address space
08:37:30 <amistillalive1> movrel family which maps to address reg with constant loads, or texture lookup, if we talk about non was it unified chip
08:37:43 <amistillalive1> sometimes fragment program has no address register available
08:38:09 <amistillalive1> then to make it functioning on all chips , it's better to use texture lookup that casts away to temp arrays
08:40:19 <glauxosdever> So it's stalling (like in hazards), so it's just the acceleration ratio that descreases
08:40:21 <amistillalive1> as far as the regfile is concerned, it will feed the alu bus of operands to compete over resources
08:40:38 <amistillalive1> only if the private register indeed was changed compared to the earlier iteration
08:40:55 <amistillalive1> otherwise the instruction get's skipped and it is not feeded to execution resources
08:40:58 <amistillalive1> fed
08:42:18 --- join: sympt (~sympt@209.58.135.106) joined #osdev
08:43:24 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
08:43:33 <amistillalive1> in other words, if the large mov array or add or whatever instruction you manipulate the bases of the reg source operands via local writebacks to that wavefront
08:43:49 <variable> amistillalive1: are you still alive?
08:43:50 <amistillalive1> does not really write new values worth of data to that base
08:44:06 <amistillalive1> then the instruction never executes
08:44:46 --- quit: sympt_ (Ping timeout: 256 seconds)
08:44:46 --- quit: drakonis__ (Ping timeout: 245 seconds)
08:45:26 <amistillalive1> and the performance gain can be computed with just a primitve function -- function of instruction number and perf gain is 2xarraysisize
08:45:50 --- quit: S_Gautam (Quit: Leaving)
08:46:10 <amistillalive1> which of course means that it is though very primitive but enough accurate measure, would sum to be like major thousound fold boost with
08:46:24 <amistillalive1> with only minor added lines
08:46:48 <amistillalive1> with a precompiler you can also add more and elliminate all the cpu overhead too
08:52:20 <glauxosdever> Sorry, gtg for now
08:52:21 <amistillalive1> i studied in tallinns technical university we had all the math there, and in addition i knew personally the biggest brain of derivatives in that school
08:53:04 --- quit: glauxosdever (Quit: leaving)
08:53:15 <amistillalive1> but i quitted cause , was very out of motivation due to no practise, but i remember the most, in addition my sports career also took a major hit after i got the first injury
08:53:29 <amistillalive1> but sportsmen are not dumb, this is what i say
08:55:47 <amistillalive1> against a joke when i was cracked up on a surgery, that sportsmen were doing practice when god gave brains to human, my tsitate against is, sportsmen were doing practice when leftovers who could not handle that failed because of their birth injuries everywhere where it was possible
08:56:02 <amistillalive1> and by no means they compete with me in programming either
08:57:59 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:01:11 <amistillalive1> you think you violate a sportstar to almost wheelchair , and belive you so tough guy, i whitewashed most with the injury still, where the noisiest ever got a point from me
09:01:20 <amistillalive1> never
09:06:56 <amistillalive1> and if the court has no proof whatsover and also no champs. medals or any rewards to show, i'd say buzz the fuck off when facing they do not even know what the procedure of their work was, cause my granny was criminal investigator, and from movies this no new thing to me...and with aussies, i bet one that i can score 5 three pointers in a row back those days when i was on form
09:07:26 <amistillalive1> cause they indeed all went in, this guy was sort of locked
09:07:38 <amistillalive1> he could not belive loosing the bet with such a statement
09:08:22 --- join: hmmmm (~sdfgsf@pool-72-79-160-80.sctnpa.east.verizon.net) joined #osdev
09:08:24 <amistillalive1> and who am i, michael jordon as he was thinking, no just an average estonian sportsmen i was, bye
09:08:28 --- quit: amistillalive1 (Quit: Leaving)
09:13:19 --- quit: magnificrab (Ping timeout: 240 seconds)
09:13:42 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
09:15:22 <m712> oh no martr is back
09:16:58 --- join: Asu (~sdelang@190.43.136.77.rev.sfr.net) joined #osdev
09:20:53 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
09:24:56 --- quit: zaquest (Quit: Leaving)
09:26:55 --- join: pyjong (~pyjong@109.76.99.180) joined #osdev
09:27:11 <pyjong> Haya!
09:27:30 --- join: zaquest (~notzaques@5.128.210.30) joined #osdev
09:27:57 <m712> OS golf when?
09:28:25 <m712> shortest hello world in $ARCH
09:28:34 --- join: m3nt4L (~asvos@2a02:587:a001:6900:3285:a9ff:fe8f:665d) joined #osdev
09:28:41 <m712> i bet you can fit that into 100 something bytes
09:28:46 <pyjong> Would somebody know what's the reason for reparenting to init in linux daemons?
09:29:04 <m712> pyjong: usually orphaning is done to daemonize
09:29:13 <m712> self-orphaning*
09:29:50 --- join: S_Gautam (~bc2010asd@59.182.254.198) joined #osdev
09:29:50 <pyjong> emmm... my ass can deamonize and it doesn't kill me in the process..
09:30:09 <m712> i don't care about that
09:30:55 <pyjong> Ok well.. from the perspective of the system. How is it whatsoever useful to be direct child of init?
09:31:32 <m712> pyjong: detaching from the process that started you
09:32:06 <m712> you create the child daemon process, then kill the parent, and the supervisor that's waiting for the daemon to start returns
09:33:36 <pyjong> I understand that's the way to go about it. I am rather curious about why am I supposed to do that. Why not just run the daemons main loop straight away, without having the parent die.
09:34:35 <pyjong> Which .. in that case there wouldn't even be need to fork
09:34:59 <bcos_> What is init? Some silly bash script that waits for its child to terminate before continuing?
09:35:04 --- join: matlock (~matlock@2600-6c5a-6e7f-e7d2-7063-76de-236f-b965.dhcp6.chtrptr.net) joined #osdev
09:36:21 <m712> bcos_: usually a small binary that reaps orphans and sends sigterm to all its children when sent a death signal
09:36:21 <S_Gautam> init also known as systemd
09:36:28 <m712> pfffffff
09:36:32 <m712> systemd is not inti
09:36:33 <m712> init
09:36:48 <m712> it's an operating system
09:36:56 <m712> emacs alternative
09:37:14 <S_Gautam> :D
09:37:20 <S_Gautam> systemd is best init'
09:37:35 <m712> sysvinit + openrc is great
09:37:38 <m712> no issues
09:38:41 --- quit: S_Gautam (Changing host)
09:38:41 --- join: S_Gautam (~bc2010asd@unaffiliated/gautams) joined #osdev
09:40:31 <pyjong> Soo.. no? No daemons.
09:44:36 --- join: sympt_ (~sympt@209.58.135.74) joined #osdev
09:47:38 --- quit: sympt (Ping timeout: 245 seconds)
09:49:09 --- quit: matlock (Read error: Connection reset by peer)
09:52:02 --- join: amistillalive (~grandmaag@83.246.170.102) joined #osdev
09:52:30 --- join: matlock (~matlock@173.44.37.114) joined #osdev
09:53:04 --- quit: sympt_ (Remote host closed the connection)
09:54:04 <amistillalive> bcos_: do you wanna give the communist some blow job, that would suite your talent obviously, my grave would have a plate title lost sportsman, yours will be lost cock action hero! maybe such with his daughter some portuguese cock too, that seems to suite your needs to kill me, you can then score some double of the title
09:54:52 <amistillalive> however abortion leftover you are, and nothing is going to change the fact, you can get additional cock socking title as you proposed.
09:54:54 <amistillalive> bye
09:54:57 --- quit: amistillalive (Client Quit)
09:56:25 <m712> pyjong: because the supervisor can't just disconnect
09:56:34 <m712> and disconnecting requires orphaning either way
09:56:43 <m712> and unix' worse is better comes into play here
09:56:48 <m712> don't question
09:58:40 --- quit: nj0rd (Ping timeout: 252 seconds)
09:59:36 --- quit: user10032 (Remote host closed the connection)
10:06:14 --- join: nj0rd (~nj0rd@mue-88-130-48-006.dsl.tropolys.de) joined #osdev
10:09:50 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
10:10:18 --- join: sympt (~sympt@209.58.135.106) joined #osdev
10:18:15 --- quit: pyjong (Ping timeout: 248 seconds)
10:20:35 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
10:30:02 --- quit: promach2 (Quit: WeeChat 2.1)
10:31:33 --- join: sympt_ (~sympt@209.58.135.72) joined #osdev
10:34:21 --- quit: sympt (Ping timeout: 245 seconds)
10:34:28 --- quit: elevated (Quit: bye)
10:45:59 --- join: pyjong (~pyjong@109.76.99.180) joined #osdev
10:48:54 --- quit: Salek (Ping timeout: 252 seconds)
10:51:51 --- quit: Goplat (Remote host closed the connection)
10:52:06 --- quit: sympt_ (Remote host closed the connection)
11:01:26 --- quit: nj0rd (Ping timeout: 245 seconds)
11:13:07 --- quit: pyjong (Quit: Leaving)
11:16:44 --- join: pyjong (~pyjong@109.76.99.180) joined #osdev
11:16:53 --- join: nj0rd (~nj0rd@mue-88-130-48-191.dsl.tropolys.de) joined #osdev
11:17:41 --- quit: Xark (Ping timeout: 260 seconds)
11:22:23 --- join: Xark (~Xark@unaffiliated/xark) joined #osdev
11:25:16 --- quit: drakonis (Remote host closed the connection)
11:25:50 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
11:26:07 <sortie> Evening
11:26:12 <m712> Don't worry, you don't need to understand the details.
11:26:28 <m712> worst sentence possible used during operating system development
11:26:30 <m712> https://os.phil-opp.com/entering-longmode/
11:26:30 <bslsk05> os.phil-opp.com: Entering Long Mode | Writing an OS in Rust
11:26:32 <m712> sortie: evening
11:26:49 <sortie> Evening m712
11:33:03 <pyjong> m712: yeah I wasn't questioning anything. Anything goes really.. but I need there to be some reason behind. It will start making sense at some point
11:33:24 <m712> pyjong: no sense in trying to find sense in UNIX
11:33:30 <m712> it'll just make your head hurt
11:34:02 <pyjong> :D
11:34:37 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
11:35:00 --- join: sympt (~sympt@209.58.130.210) joined #osdev
11:35:13 <sortie> m712: Hmm it's alright
11:35:32 <m712> unix touched me in a no-no place
11:36:06 <sortie> Sexual assault is no joke, m712.
11:36:14 <m712> i'm gonna sue bell labs
11:40:21 <sortie> Eh
11:40:26 <sortie> It's weekend
11:40:37 <sortie> I hope I get clear enough in the head to maybe do some osdev
11:40:55 --- quit: lachlan_s (Quit: Connection closed for inactivity)
11:53:01 --- join: matlock_ (~matlock@2600-6c5a-6e7f-e7d2-e185-8b10-02da-10a0.dhcp6.chtrptr.net) joined #osdev
11:54:32 --- quit: xenos1984 (Ping timeout: 252 seconds)
11:56:11 --- quit: matlock (Ping timeout: 260 seconds)
12:05:19 --- quit: daniele_athome (Ping timeout: 240 seconds)
12:11:49 --- quit: sympt (Quit: Leaving...)
12:15:26 --- join: attah (~attah@h-155-4-135-114.NA.cust.bahnhof.se) joined #osdev
12:15:32 --- join: dennis95 (~dennis@i577BCE18.versanet.de) joined #osdev
12:23:51 --- join: Sonicbit (~Sonicbit@185.53.85.10) joined #osdev
12:23:59 --- quit: matlock_ (Read error: Connection reset by peer)
12:24:18 --- quit: JusticeEX (Ping timeout: 245 seconds)
12:25:42 --- join: anabellasumella (~grandmaag@121.152.108.83) joined #osdev
12:26:48 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
12:27:12 --- join: Guest21615 (~testerr@206.189.79.99) joined #osdev
12:27:13 --- quit: Guest21615 (Remote host closed the connection)
12:27:27 --- join: Asu` (~sdelang@AMarseille-658-1-29-65.w86-219.abo.wanadoo.fr) joined #osdev
12:27:32 <anabellasumella> i hate attention to be honest, as far as i am conserned i'd live in cage happily! not sure where bcos found something to pick at , but the confirmation links: https://devtalk.nvidia.com/default/topic/541356/opengl/slow-local-arrays-in-glsl/
12:27:34 <bslsk05> devtalk.nvidia.com: slow local arrays in GLSL - NVIDIA Developer Forums
12:27:34 --- quit: Asu (Ping timeout: 256 seconds)
12:27:42 --- join: Guest21615 (~testerr@206.189.79.99) joined #osdev
12:27:48 <anabellasumella> https://devtalk.nvidia.com/default/topic/390366/instruction-latency/
12:27:50 <bslsk05> devtalk.nvidia.com: Instruction Latency - NVIDIA Developer Forums
12:29:46 <anabellasumella> so with another couple of instructions vega variable width simd in hw can be implemented on any hw, but see the link how glsl arrays fragment badly, unrolled loop insts. taking slots etc.
12:30:43 <anabellasumella> it is very logical, but with me it's hard to have arguments too, i am 35years old i know every detail about gpus, since i have been at it for past 10years
12:33:50 <sortie> Hello anabellasumella
12:34:26 --- join: dafnamay[m] (dafnamayma@gateway/shell/matrix.org/x-ynsyihljcmphwjsh) joined #osdev
12:36:18 --- join: cutebyte (~cyfer@user-94-254-168-64.play-internet.pl) joined #osdev
12:36:46 <cutebyte> exit
12:36:55 <cutebyte> Whoops. Sorry bout that. :D
12:37:14 --- quit: cutebyte (Quit: leaving)
12:37:20 --- join: zeus1 (~zeus@197.239.7.39) joined #osdev
12:37:29 <anabellasumella> i ainõt gonna apaplogise, and i do not expect you morans to, or any other gpu channel lunatics, shovel your apologises to your ass!
12:37:33 --- quit: anabellasumella (Quit: Leaving)
12:38:09 <sortie> I like how this particular spammer goes away when I say hi
12:43:37 --- join: m_t (~m_t@p5DDA0C92.dip0.t-ipconnect.de) joined #osdev
12:43:49 <m712> how's weather in estonia
12:47:54 --- quit: sortie (Quit: Leaving)
12:50:45 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
12:50:50 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
12:53:14 --- join: pie__ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
12:54:08 --- join: jakogut_ (~jakogut@162.251.69.147) joined #osdev
12:54:22 --- join: posixparrot (~shittypoo@121.152.108.83) joined #osdev
12:55:37 <posixparrot> sortie: still wanna sue me, someone should take you seriously, i organize all the posix devs at you for your clueless disgraceful behavior too, go to home retarded kid!
12:55:43 --- quit: posixparrot (Client Quit)
12:55:54 <sortie> lol
12:56:26 --- quit: pie_ (Ping timeout: 245 seconds)
12:56:30 <sortie> I appreciate how that person continues to consistently self-own when trying to act superior but come across as a piece of shit.
12:56:33 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
12:58:05 --- join: posixparrot (~shittypoo@121.152.108.83) joined #osdev
12:58:59 <posixparrot> even estonians are doing jokes on facebook, advising me probably that it is pointless to argue with idiots, it is like playing chess with a tuve, who shits the table full and pretends to be a winner anyways...
12:59:57 <posixparrot> they have their history of arguing me, and as many argues as many losses, so they have at least learned
13:00:51 <sortie> Checking the logs, posixparrot?
13:01:29 <sortie> posixparrot: It's a nice evening. I suggest you go outside and enjoy the evening.
13:02:27 --- quit: spare (Ping timeout: 240 seconds)
13:02:49 <posixparrot> i just got really curious and like worried, that how's with shitty poopix development?
13:03:08 --- quit: posixparrot (Quit: Leaving)
13:03:14 <sortie> lol
13:03:28 <geist> kill dm
13:03:31 <geist> kick even
13:03:43 <graphitemaster> what the fuck is going on in here
13:03:45 --- join: glauxosdever (~alex@ppp-94-66-45-89.home.otenet.gr) joined #osdev
13:03:56 <geist> it's martm again
13:03:57 <sortie> It's funny how people think they can get to me by saying nasty things about POSIX
13:04:09 <graphitemaster> sortie, POSIX is garbage compared to SORTIX
13:04:13 <graphitemaster> <3
13:04:16 <geist> sortie: it doesn't matter, it's just martm. he doesn't operate on traditional metrics of logic
13:04:55 <sortie> https://www.youtube.com/watch?v=aKnX5wci404&feature=sortie&t=38s
13:04:56 <bslsk05> 'The Naked Gun - "Nothing to see here!" (1080p)' by Cobra Supreme (00:00:48)
13:05:06 <rain1> poopix
13:05:15 <rain1> owned
13:05:27 <geist> yeah that's an april 1st release there
13:05:38 <geist> ponyos vs poopix: the battle of the hobby oses
13:05:45 <sortie> geist: Yeah just letting him selfown a bit before I start the kicks
13:06:09 <geist> last time around i just got him to direct the nonsense spew at me in privmsg
13:06:17 <geist> it went on for days and pages and pages of text
13:06:38 <rain1> why dont you just /ignore him?
13:06:57 <geist> i did. point is it kept the spew from going to the channel
13:07:03 --- quit: AverageJ0e (Ping timeout: 260 seconds)
13:07:10 <geist> well, i ignored him the old fashioned away, didn't read it
13:07:13 <doug16k> this room should require registration. it's worth the inconvenience
13:07:21 <geist> eh. no
13:07:30 <rain1> maybe allowing him to rant would be theraputic for him
13:07:32 <geist> this aint *nothing* compared to what this channel has gone through before
13:07:35 <geist> rain1: exactly
13:07:54 <geist> i figured let him rant at me in a controlled environment, get it out of his system
13:08:10 <geist> i'm perfectly capable of not getting offended or whatnot
13:08:12 <doug16k> the personal attacks aren't cool though :(
13:08:12 <sortie> Anyways he just wanted to taunt me
13:08:20 <sortie> We had a fun conversation last time. I guess he wants me to escalate.
13:08:30 <sortie> I might. Eh.
13:08:31 <graphitemaster> geist, I found a solution to the private message problem on here
13:08:36 <_mjg_> well, if you genuinely think this person is mentally ill
13:08:43 <geist> oh we definitely do
13:08:48 <_mjg_> waiting for them to come back and keep talking shit is not the right thing to do
13:08:50 <geist> he's been in an out of here for the last few years
13:08:58 <geist> tere's just nothing else we can do
13:09:07 <sortie> Well we know who it is
13:09:18 <graphitemaster> I found a freenode flag that requires someone be registered with services to private message you
13:09:28 <glauxosdever> A troll would probably quit after some days or so
13:09:30 <sortie> Honestly it's just a question of whether it's worth the bother to do something
13:09:30 <graphitemaster> +R
13:09:50 <sortie> glauxosdever: lol yeah no
13:09:54 <geist> generally yes. most of the time he spews some stuff and then moves on
13:10:02 <graphitemaster> the amount of spam private messages I get has dropped to 0 from like at least 4 a week
13:10:05 <geist> so we usually just let it go, unless it's over the top of some on topic thing
13:10:25 <sortie> I see no reason for this discussion
13:10:40 <geist> me and you yes, but then there are always new people, etc
13:10:53 <geist> so this discussion will happen again and again, it is the way of things
13:11:38 <graphitemaster> here's an on topic discussion worth having, has anyone looked into polymorphic kernel development before?
13:12:34 <glauxosdever> graphitemaster: Using the same functions on files, memory areas, streams, etc?
13:12:34 <geist> gonna have to be more specific there
13:12:36 <graphitemaster> i.e live rerandomization of address spaces and kernel data structures to prevent side channel attacks
13:12:38 <doug16k> more polymorphic than kaslr?
13:12:44 --- quit: sortie (Quit: Leaving)
13:13:30 <glauxosdever> So, not the polymorphism in the OOP sense
13:13:40 --- join: daniele_athome (~daniele_a@5.170.128.38) joined #osdev
13:13:58 <graphitemaster> right, polymorphic in the sense of address space randomization that is frequent and live, so bruteforce is not possible, but also binary rewriting
13:14:34 <graphitemaster> I read an interesting paper last night on it, research stuff...
13:14:41 <glauxosdever> Link?
13:14:41 <graphitemaster> the challenges, like needing an in kernel JIT
13:14:46 <graphitemaster> http://www.minix3.org/theses/kuijsten-polymorphic-os.pdf
13:15:06 <geist> or have the kernel use a neural net to keep inventing new virtual machine cpu architectures, build a runtime, then translate the kernel to that, then switch
13:15:21 <glauxosdever> A bit long. Won't read it now
13:15:26 --- quit: Lucretia (Remote host closed the connection)
13:15:41 <geist> see i wasn't too far off. jit the kernel to different cpu architectures dynamically
13:15:45 <glauxosdever> I made the naive assumption it would be implemented using smart pointers
13:15:59 <glauxosdever> But that defies the purpose
13:16:02 <graphitemaster> I can't believe I read that whole paper last night
13:16:05 <doug16k> it's not worth one moment of thought until I do KPTI in my kernel :)
13:16:32 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
13:17:19 <doug16k> without KPTI on intel, you might as well set the user bit on all page tables, lol
13:17:30 <graphitemaster> or identity map the whole address space
13:17:52 <doug16k> at least the read only ones
13:18:57 <doug16k> you'd need a double indirection for it to high KASLR right? you'd need a user accessible trampoline that doesn't reveal the kernel's load address
13:19:05 <doug16k> s/high/hide/
13:19:30 <geist> well, that would come with KPTI
13:19:48 <graphitemaster> the easiest way to protect your OS is to not allow running native code at all
13:19:53 <geist> oh i see. yeah you'd want to double indirect the call into the kernel, you're right
13:20:17 <graphitemaster> I really want to experiment with the idea of putting something like LuaJIT in the kernel
13:20:24 <graphitemaster> and writing all of userland in Lua
13:20:42 <geist> reminds me, there was some sort of newer lua like thing that someone was interested in at work the other day
13:20:42 <graphitemaster> LuaJITOS, LJITOS
13:20:49 <geist> seemed nice. but now i forget what it was
13:20:51 <bcos_> Making sure there's no "kernel addresses" in IDT and GDT sounds like a lot of fun for something like NMI or double fault
13:20:53 <graphitemaster> LJOS
13:22:08 <graphitemaster> geist, you're probably thinking of Terra
13:22:13 <graphitemaster> http://terralang.org/
13:22:13 <bslsk05> terralang.org: Terra
13:22:18 <geist> maybe? lemme see
13:22:56 <geist> wasn't exactly this no. it had nothing to do with lua per se, it just had most of the same constraints
13:23:37 <graphitemaster> Ravi ?
13:23:42 <graphitemaster> https://github.com/dibyendumajumdar/ravi
13:23:42 <bslsk05> dibyendumajumdar/ravi - Ravi Programming Language is a derivative of Lua 5.3 with limited optional static typing and LLVM based JIT compiler (28 forks/440 watchers)
13:23:53 <geist> wren.io apparently
13:24:00 <graphitemaster> oh, wren.io is meh
13:24:04 <graphitemaster> not jit compiled
13:24:07 <graphitemaster> just a bytecode
13:24:10 --- join: mastertroll (~shittypoo@121.152.108.83) joined #osdev
13:24:22 <geist> yes, hence the 'lua like constraints'
13:24:24 <graphitemaster> I prefer gravity to wren https://github.com/marcobambini/gravity
13:24:25 <bslsk05> marcobambini/gravity - Gravity Programming Language (94 forks/2389 watchers)
13:24:29 <geist> as in a very simple little runtime you can jam into things easily
13:24:32 <graphitemaster> very similar
13:24:35 <mastertroll> two total nutters from google are starting to think something! that has always looked bad
13:24:41 <graphitemaster> but gravity is smaller and faster than wren
13:24:47 <mastertroll> especially when they allready genuinly think
13:24:54 <geist> which is gravity?
13:25:13 <graphitemaster> https://marcobambini.github.io/gravity/
13:25:13 <bslsk05> marcobambini.github.io: Gravity
13:25:37 <graphitemaster> "VM code is about 2K lines long, multipass compiler code is about 3K lines and shared code is about 2K lines. Compiler and virtual machine together add less than 200KB to the executable size in a 64bit system."
13:25:40 <mastertroll> graphitemaster: you look as pedantic in your sophistacated programming terms, that you could allready have a conversation with 60year old granny in the market
13:25:53 <geist> still that's pretty big. out of the realm of simple embedded things
13:26:00 <mastertroll> graphitemaster: however it seems that it would suite you better then programming at least
13:26:03 <geist> hence why lua still lives. nice for just sticking into something
13:26:04 <graphitemaster> geist, still smaller than wren
13:26:16 <geist> no wya. it says righ tthere it takes 200KB on a 64bit machine
13:26:40 <geist> huh. those numbers are weird
13:26:43 <graphitemaster> geist, also you don't need to put the compiler on the deivce you target, since gravity can be offline compiled into a binary
13:27:02 * geist nods
13:27:05 <graphitemaster> wren code calls back into the compiler so you can't decouple it
13:27:31 <mastertroll> graphitemaster: duve , do you like to shit constantly on the chess table every time you get beaten?
13:27:47 <graphitemaster> can the mods start modding
13:27:49 <geist> ah okay, that makes sense
13:27:58 --- mode: ChanServ set +o geist
13:28:01 --- mode: geist set +b *!*shittypoo@121.152.108.*
13:28:01 --- kick: mastertroll was kicked by geist (mastertroll)
13:28:37 <graphitemaster> thanks
13:28:58 <graphitemaster> anyways yeah, those numbers seem odd
13:29:09 <graphitemaster> 2+3+2k is 7k of code
13:29:15 <geist> actually kind of funny that they're written as 'see how small 200KB is!'
13:29:16 <graphitemaster> I don't understand how that becomes 200KB
13:29:24 <geist> whereas in embedded world thats like half the flash of a large mcu
13:29:26 <doug16k> 200KB is a lot of native code
13:29:35 <graphitemaster> maybe they compile with -O3 instead of -Os
13:29:47 <doug16k> maybe they included symbols?
13:29:53 <graphitemaster> the engine at work when compiled with -O3 is like 16MiB, when I compile it as -Os, it's less than 1MiB
13:30:08 <graphitemaster> and yeah, maybe they include symbols?
13:30:27 <geist> yah i've found that most folks dont really understand what's in a binary and tend to just use the size of the file most of the time
13:30:39 <graphitemaster> which sucks because the size command is perfect
13:30:44 <graphitemaster> it tells you bss, text, data
13:30:45 <graphitemaster> as a table
13:31:06 <geist> yep. though a think i've discovered that's pretty annoying: llvm-size interprets things a little differently than binutils size
13:31:07 <doug16k> graphitemaster, nice
13:31:21 <geist> in that they make different decisions about what goes in .text and what gets clumped with .data and ewhatnot
13:31:23 <m712> size should pass a table structure to the shell
13:31:32 <m712> using the OS provided bus
13:31:41 <m712> but i'm just dreaming
13:31:57 <geist> specifically one of the two decides that rodata is really data and shouldn't be clumped with text
13:32:09 <geist> and the other one decides that if it's a R segment it's text
13:32:09 <graphitemaster> the product at my startup company is almost 30k lines of C, and this is its size: https://pastebin.com/raw/Cf72Re3n
13:33:18 <graphitemaster> which is not that large :P
13:33:27 <m712> graphitemaster: is it open source
13:33:30 <graphitemaster> no
13:33:36 <m712> i guessed
13:33:50 --- join: goaway (~goaway@2601:196:8701:e3bb:c0dd:ad78:ba8a:2a7c) joined #osdev
13:33:52 <graphitemaster> I started a buisness to make money not perform charity
13:33:58 <m712> he's back
13:34:04 <geist> m712: yeah we had some grand plans for that sort of stuff for fuchsia but thus far haven't had the cycles to materialize
13:34:06 --- part: goaway left #osdev
13:34:19 <geist> ie, the more complex arg/return value from processes
13:34:24 <m712> geist: hm
13:34:32 <m712> fuchsia is still C or no?
13:34:41 <m712> didn't really take a look at it yet
13:34:44 <geist> since it's all just done via IPC and whatnot in the kernel, there's no reason it can't be done in a structurede way, just hasn't been on the radar
13:34:54 <geist> fuchsia is written in a pile of languages
13:34:58 --- mode: geist set -o geist
13:35:00 <doug16k> size is practically zero until it exceeds L3 cache size
13:35:08 <geist> as you get closer to the metal it gets more C/C++
13:35:20 <m712> geist: is java still in there?
13:35:29 <geist> negative
13:35:30 <m712> i guess you'd need it for android compat
13:35:33 <m712> oh?
13:35:42 <graphitemaster> geist, btw, I got a chance to play with the programmable arm vector processor that has definable vector components and sizes and float forms (16, 32, 64)
13:35:49 <geist> dunno where 'still' is, it never was in there
13:36:05 <graphitemaster> geist, 4x64 adds are faster than 8x32 adds
13:36:28 <geist> stands to reason if they have a finite number of 64bit wide ALUs
13:37:32 <doug16k> think so? for the most part you can split up a vector ALU by gating carry/etc at boundaries
13:37:42 <doug16k> depends on exactly how they implement it though, of course
13:38:16 <geist> oh wow, never occurred to me you could do this: std::lock_guard<std::mutex>{m}, ++i;
13:39:00 <geist> graphitemaster: is this what you did with that lock wrapper thing? seems you could put a do { } while (0) in the second slot of the comma
13:40:08 <graphitemaster> that's dangerous, I wouldn't trust it, and no, my lock wrapper is more like for(lock a(mutex); a; a.unlock()) where lock's constructor locks the mutex, and a has an operator bool that returns true while locked, and a.unlock ... unlocks the mutex
13:40:14 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
13:40:41 <graphitemaster> the whole thing becomes #define locked(mutex) for(lock lock##__LINE__(mutex); lock##__LINE__; lock.unlock())
13:40:47 <graphitemaster> do then I can do locked(mutex) { code here }
13:40:47 <doug16k> my first thought was for too. the operator bool is a cool idea, but backward sense
13:40:54 <graphitemaster> s/do/so/
13:41:17 <doug16k> shouldn't it be for(lock a(mutex); !a; a.unlock()) and return true when locked?
13:41:49 <graphitemaster> that does not make sense, because lock::lock() would lock it, in which case a will be true
13:41:55 <graphitemaster> and !a will be false, so it never enters the scope at all
13:42:01 <doug16k> ah right, lol
13:42:14 <doug16k> so operator bool does return true when locked
13:42:17 <doug16k> nvm
13:42:28 <graphitemaster> I also use it not in that context too
13:42:37 <graphitemaster> like I'll have code like if(lock) { }
13:42:40 <graphitemaster> to test if a lock is locked
13:42:45 <graphitemaster> so I like that operator bool
13:42:47 <geist> ah no you can't put a new scope in the right side of the comma
13:42:49 <geist> so it doesn't really work
13:43:03 <graphitemaster> you could have a member function like is_locked()
13:43:14 <doug16k> the for trick works as single line or with braces, which is cool
13:43:17 <geist> https://godbolt.org/g/Reainr
13:43:20 <bslsk05> godbolt.org: Compiler Explorer
13:43:23 <graphitemaster> yes, it's nice to write code like
13:43:36 <graphitemaster> if (foo) locked(mutex) { code } else locked(mutex) { code }
13:43:50 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-tbcakpwzsposhcff) joined #osdev
13:49:01 <doug16k> graphitemaster, why ##__LINE__, shouldn't be necessary right? without it you might get Wshadow warnings though
13:49:21 --- quit: oaken-source (Ping timeout: 260 seconds)
13:49:28 <graphitemaster> yeah
13:50:37 <doug16k> there is also semi-portable __COUNTER__ which would handle two lock statements on one line
13:50:41 --- quit: drakonis (Read error: Connection reset by peer)
13:51:00 <variable> \o/
13:52:35 --- join: bemeurer (~bemeurer@104.200.152.5) joined #osdev
13:53:11 <geist> ah i've never heard about __COUNTER__ but i assume it returns an incrementing count per compilation unit
13:53:31 --- quit: AverageJ0e (Ping timeout: 245 seconds)
13:53:37 --- quit: GeDaMo (Remote host closed the connection)
13:53:41 <doug16k> per macro invocation I believe
13:53:55 <geist> right
13:54:22 <doug16k> ah I see, yeah it would reset per compilation unit
13:55:15 <_mjg_> geist: so are you still up for that crap benchmarking?
13:55:21 <_mjg_> (or is it 'down'?)
13:56:21 <variable> O.o o.O
13:57:01 <_mjg_> what
13:58:48 --- quit: behalebabo (Max SendQ exceeded)
13:59:06 --- join: behalebabo (~behalebab@unaffiliated/behalebabo) joined #osdev
14:13:06 <_mjg_> so in my os i implemented the idle loop in the form a bitcoin miner
14:13:27 <_mjg_> it gets to run before i start up the userspace miner
14:13:45 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
14:14:15 --- quit: daniele_athome (Ping timeout: 260 seconds)
14:14:43 <doug16k> _mjg_, you've gotta be kidding
14:14:58 <_mjg_> why
14:15:20 <doug16k> it does it even on a laptop on battery?
14:15:51 --- quit: S_Gautam (Quit: Leaving)
14:16:08 --- join: isd (~isd@pool-71-174-32-198.bstnma.east.verizon.net) joined #osdev
14:16:15 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
14:16:41 --- join: soulisson (~soulisson@unaffiliated/soulisson) joined #osdev
14:16:42 <_mjg_> mined coins let me afford the extra battery and then some
14:17:15 --- quit: glauxosdever (Quit: leaving)
14:19:26 --- quit: Lucretia (Remote host closed the connection)
14:19:42 <soulisson> Hi. I read the wikipedia article on operating systems. There is something which isn't clear to me. Is an operating system the kernel and its modules or the kernel, the modules, and other programs shipped with them, like notepad for windows?
14:20:42 <sortie> That's really just a question of definition
14:20:49 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
14:20:51 --- join: copyingcat (~armelion@85.191.253.15) joined #osdev
14:21:14 <sortie> I tend to prefer the all-inclusive definition, where "the OS" also contains the whole base system and things installed by default
14:21:24 <sortie> But that's really more of a "OS image release"
14:21:44 <sortie> I tend to just say "kernel" when I mean the kernel of the OS
14:22:01 <soulisson> sortie, thanks very much
14:22:15 <sortie> I'm sure there's academics with exact definitions, but that's not really real world useful
14:22:29 <copyingcat> i am sorry graphitemaster quasimodo cockblockers life is difficult, you must impress with your complex terms to get attention, i am really sorry about that, the truth is when you get treated enough then plagiatising even works for you to some degree, and you make some sense sometimes!
14:22:50 --- quit: copyingcat (Client Quit)
14:23:09 --- mode: ChanServ set +o sortie
14:23:24 --- quit: dbe (Ping timeout: 252 seconds)
14:23:34 --- mode: sortie set +b *!*@85.191.253.15
14:23:56 <soulisson> sortie, the wikipedia definition seems to refer to the operating system as the kernel and its modules but I agree with you
14:24:26 <sortie> Well, when you make an OS, all the additional parts also matter
14:24:39 <soulisson> indeed
14:24:40 <sortie> The base system is an important part of making a real OS
14:25:19 <soulisson> sortie, I guess the definition depends on people, right?
14:25:19 --- quit: m3nt4L (Remote host closed the connection)
14:25:39 <sortie> Yeah but it's not really that important
14:25:53 <sortie> The real question is what you want to say about an OS, what you are trying to accomplish by using the term
14:26:00 <_mjg_> i think most people consider an os to be the entire package
14:26:01 --- join: Goplat (~goplat@reactos/developer/Goplat) joined #osdev
14:26:09 <soulisson> sortie, you're right. Thanks for your help
14:26:10 <_mjg_> basically windows-style
14:26:27 <soulisson> _mjg_, I agre
14:26:31 <soulisson> *agree
14:33:20 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
14:41:14 --- join: spare_ (~user@unaffiliated/spareproject) joined #osdev
14:43:15 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
14:44:36 --- quit: banisterfiend (Client Quit)
14:48:05 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
14:48:06 --- quit: JusticeEX (Ping timeout: 248 seconds)
14:49:19 --- quit: regreg (Ping timeout: 240 seconds)
14:53:50 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
14:57:20 --- quit: banisterfiend (Client Quit)
14:58:34 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
14:59:02 <doug16k> soulisson, my definition of operating system is the layer that manages sharing of the computer's resources, isolates processes from one other, and provides an abstraction layer to allow software to use the hardware without knowing anything about the hardware implementation
15:03:56 --- quit: attah (Remote host closed the connection)
15:06:41 <doug16k> it also provides abstractions for storage formats and interfaces, communication protocols and devices, timekeeping, etc.
15:07:19 <geist> indeed
15:07:27 <geist> that's a fairly modern, but usable definition
15:07:35 <geist> since that's the sort of things that most modern OSes expect
15:07:44 <geist> though you're starting to get a bit into desktop/server class OS territory
15:11:46 --- quit: pyjong (Quit: Leaving)
15:13:16 --- quit: zeus1 (Ping timeout: 252 seconds)
15:13:46 <doug16k> yeah, the truly universal definition is "it depends" :)
15:14:44 <geist> when you get down into the low functionality stuff you start to get into monitor-class
15:15:07 <geist> like, say, the apple 2 monitor. lets you poke around in memory and load binaries into ram to run
15:15:23 --- quit: Kimundi_ (Ping timeout: 260 seconds)
15:15:24 <geist> and provides a set of hardware abstraction routines, but otherwise doesn't manage resources for you
15:15:58 <geist> you can see how something like DOS or CP/M builds from that
15:16:23 <geist> provides an abstraction for a file system and some global memory management and the ability to load a structured program from disk
15:16:34 <geist> but otherwise doesn't provide much more, at least in basic form
15:16:54 --- quit: gattuso (Remote host closed the connection)
15:17:01 <geist> but they're absolutely OSes in the traditional sense, they're just not providing multi processing
15:17:43 <doug16k> yes, and the OS may delegate to an underlying layer (e.g. the BIOS) for hardware abstraction
15:17:49 --- join: gattuso (~gattuso@pompel.me) joined #osdev
15:18:01 --- quit: aalm (Ping timeout: 260 seconds)
15:18:19 <geist> right, in that case DOS essentially extends the BIOS. much in the same way that say apple 2 DOS or prodos extended the monitor rom
15:26:32 --- quit: spare_ (Remote host closed the connection)
15:27:02 --- quit: dennis95 (Quit: Leaving)
15:30:22 --- quit: Asu` (Quit: Konversation terminated!)
15:30:44 --- join: vix (4dac8cd3@gateway/web/freenode/ip.77.172.140.211) joined #osdev
15:31:02 <vix> someone implemented TLB shootdown?
15:31:20 <geist> everyone has to at some point
15:31:28 <geist> depending on precisely what you're talking about
15:31:31 --- join: zeus1 (~zeus@197.239.5.112) joined #osdev
15:32:02 <vix> well, I just know how it works theoretically, I am wondering about the performance impact of IPI
15:32:14 <geist> a lot.
15:32:35 <geist> it's expensive. you want to avoid doing a TLB shootdown as much as possible
15:32:48 <geist> and/or pick an architecture where you dont have to do it
15:33:00 <vix> which arch?
15:33:05 <geist> anything but x86
15:33:20 <geist> TLB shootdown is basically an x86 thing, most other modern arches dont have that problem
15:33:45 <lachlan_s> Hi geist
15:33:54 <geist> hola
15:34:13 <vix> how other arch manages this?
15:34:28 <geist> broadcast TLB shootdown instructions
15:34:49 <vix> ah, it is implemented in cpu
15:34:56 <geist> correct
15:35:21 <vix> why intel didn't? is there a particular reason?
15:35:42 --- quit: sortie (Read error: Connection reset by peer)
15:35:48 <geist> old architecture, not designed with smp in mind
15:35:55 <geist> but... i'd love for them to add the extensions, yes
15:36:39 <vix> ok
15:37:18 <geist> i dont think anything else from that era (late 70s early 80s) had TLB broadcast instructions
15:37:24 <geist> i suspect 68k, for example, had the same problem
15:37:39 <geist> first one in the risc space i can think of is POWER, and that was more like a late 80s thing
15:38:14 <lachlan_s> Got some of the abi interface implemented
15:38:50 <doug16k> I'm thankful that the TLB is so lazy and aggressive on x86. it would be awfully expensive to make it automatically coherent like main memory is
15:39:12 <geist> oh but it already is
15:39:39 <vix> I am reading tlb.c in linux and it is a pain
15:39:49 <geist> there are a lot of thigns it could be much lazier about, but since it has to be backwards compatible it does
15:41:00 <geist> for example, the page table cache itself is largely invisible
15:41:22 <geist> AMD actually has a control bit to expose it, but intel basically dumps the entire page table cache when you invlpg to make it appear transparent
15:41:34 <geist> on ARM you have to manage that in addition to TLB flushes
15:42:46 <geist> though it's nto difficult, just something else you have to think about
15:43:30 <geist> that was a case where x86 implementatinos added the page table cache later on, so they couldn't break backwards compatibility so they had to make it magically coherent
15:43:34 <vix> PCID has some impact on this?
15:43:42 <geist> unclear
15:44:10 <geist> intel docs are not very clear about precisely how the mechanism works behind the scenes. AMD is a bit better about documenting what happens behind the scenes, but then they dont support PCID
15:44:46 <doug16k> I've had "no shootdown on free" on my todo for a while. plan is to avoid actually freeing memory until all cpus have had an opportunity to do their flush lazily. any cpus with stale entries may continue to write to the not-actually-freed-but-maybe-in-another-tlb physical-pages
15:44:55 <vix> shit... why intel is still the most cpu used? :)
15:45:55 <vix> doug16k: does not it break things?
15:46:07 <doug16k> vix, why would it break things?
15:46:17 <vix> I mean, you have some not coherence tlb state among the cpus
15:46:30 <geist> trouble there willb e when you want to do a page modificatino, not an unmap
15:46:41 <geist> or, user space unmaps and then maps on top of it
15:47:01 <geist> it's an optimization for unmapping where the address space doesn't get reused any time soon, which is probably worth it, but only a piece of the picture
15:47:01 <vix> if a cpu change the perms of a page, for example
15:47:07 <doug16k> yeah won't work reliably for downgrading permissions
15:47:14 <geist> changing perms of a page in the long run is actually the most hit of them, really
15:47:38 <geist> once you have a full vm up thats tracking dirty/accessed, etc you're going to be twiddling perms a lot
15:48:20 <vix> I was thinking about CoW, but maybe it is not affected
15:48:34 <geist> cow is exactly where you get a page modification
15:48:42 <doug16k> cow is affected. you need to tell the other cpus to flush because the TLB caches the permissions
15:48:54 <geist> but even then if you're going through and tweaking pages for the accessed bit and whatnot you're going to be constantly fiddling with them
15:49:27 <doug16k> if you profile linux in fork-heavy workload (like a big parallel make) then you see that it spends more time in page faults than it does compiling
15:49:58 <vix> but if a cpu fork/exec a process, the remap is local on that cpu, so cow happens on that cpu only, right? so why flush others?
15:50:01 <doug16k> because most source files are super easy to compile and finish almost instantly
15:50:39 <clever> doug16k: https://www.sqlite.org/amalgamation.html solves that,and also can improve runtime perf
15:50:40 <bslsk05> www.sqlite.org: The SQLite Amalgamation
15:50:51 <geist> single threaded processes dont tend to induce much TLB shootdown, no., since most OSes at least avoid doing a TLB shootdown if the other core doesn't have the same address space mapped
15:51:42 <vix> geist: yeah, it is the same till CoW
15:52:02 <geist> most stuff like that vfork/execs to avoid that
15:52:27 <vix> so why CoW should send a remote flush?
15:52:33 <geist> it probably wont
15:52:37 <doug16k> clever, manually doing fwhole-program? it's nice to have file-scope stuff though
15:53:00 <vix> clever: how it works with 'static' functions?
15:53:04 <clever> doug16k: and i just noticed point 3 on the page, some debuggers can only deal with 32k lines in a file, lol
15:53:30 <clever> vix: i'm guessing they just avoid collisions between diferrent files in the project, for that reason
15:54:27 <vix> anyway, intel makes me crazy when I have to work on TLB/mm stuff..
15:54:39 <vix> I should write my code for ARM only
15:54:40 <doug16k> geist, your project maintains some kind of list of which cores have a certain address space mapped?
15:55:10 <clever> doug16k: it seems fairly simple to keep track of every thread that has ran on a core since the last TLB wipe
15:55:26 <clever> and then just get a list of cores that have ran a thread in a given addr space
15:55:27 <vix> doug16k: isn't this information in page tables? :)
15:55:47 <doug16k> vix, which CPU(s) have it cached? no
15:56:06 <vix> oh, cached.. ok
15:56:12 <doug16k> in the TLB I mean
15:56:12 <geist> doug16k: yes
15:56:22 <vix> how?
15:56:33 <clever> knowing if its in the cache or not is harder, but knowing it if CAN be cached is easy, just track every pagetable tree it has ran since the last wipe
15:56:38 <vix> you record every TLB hit?
15:56:51 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:56:52 <geist> every possibility of a hit
15:56:55 <geist> as in, was it ever mapped
15:57:04 <doug16k> vix, you can record which cpus *could* have it in their TLB, not necessarily certainly in their TLB
15:57:14 <geist> this is where PCID makes it a lot more complicated
15:57:20 <vix> a sort of of TLB dump
15:57:21 <geist> because now it's possible for it to stick around a lot longer
15:57:50 <doug16k> yeah I started implementing PCID and backed out because it made shootdown extremely difficult to manage
15:57:58 <geist> in the case of arm, for example, which has a proper ASID (their equivalent of PCID) it more or less requires that you have broadcast TLB invalidates, because functionally all cpus that have ever mapped an ASID could have live entries
15:58:08 --- join: zlsyx (~zlsyx@193.2.224.100) joined #osdev
15:58:45 <vix> geist: ASID has some limit number like PCID?
15:58:47 <geist> and the TLB invalidate instructions that you use in this case take the ASID:vaddr pair, so you can target a shootdown across all cores for just that asid
15:58:50 <doug16k> KPTI uses PCID though. does it just have two PCIDs and invpcid the whole address space to emulate the old mov cr3 behaviour?
15:58:54 <geist> vix: 16bits
15:59:00 --- join: aalm (~aalm@37-219-100-76.nat.bb.dnainternet.fi) joined #osdev
15:59:17 <geist> doug16k: i haven't fully grokked it yet. i figured i'd wait for it all to settle and then see what the best solution is
16:01:14 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
16:03:53 <vix> https://www.usenix.org/system/files/conference/atc17/atc17-amit.pdf
16:03:55 <vix> good read
16:06:18 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:09:27 --- quit: vix (Quit: Page closed)
16:23:40 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
16:26:37 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
16:31:09 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
16:35:23 <graphitemaster> you can also optimize TLB shootdowns by disabling cache completely!
16:35:42 <graphitemaster> it'll be optimal because everything else will be super slow so it won't matter
16:46:30 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-djrkblyxmaavxowf) joined #osdev
16:58:37 --- join: freakazoid0223_ (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
16:59:46 --- quit: freakazoid0223 (Ping timeout: 268 seconds)
17:01:06 --- quit: xenos1984 (Quit: Leaving.)
17:03:38 --- quit: stephennnn (Ping timeout: 252 seconds)
17:04:02 --- join: stephennnn (~stephen@142.134.91.153) joined #osdev
17:06:45 --- join: matlock (~matlock@2600-6c5a-6e7f-e7d2-a0b2-f38e-3e81-2676.dhcp6.chtrptr.net) joined #osdev
17:08:30 --- quit: m_t (Quit: Leaving)
17:14:34 --- quit: AverageJ0e (Ping timeout: 268 seconds)
17:29:36 --- join: promach__ (~promach@2001:e68:4427:94e4:d26c:21ca:18b3:9623) joined #osdev
17:33:13 --- quit: ALowther_ (Remote host closed the connection)
17:34:49 --- nick: promach__ -> promach2
17:36:03 <promach2> I have open access to Xillybus linux driver coding at https://github.com/torvalds/linux/tree/master/drivers/char/xillybus and https://www.kernel.org/doc/Documentation/xillybus.txt
17:36:05 <bslsk05> github.com: linux/drivers/char/xillybus at master · torvalds/linux · GitHub
17:36:26 <promach2> do you think I should debug on my own instead of relying on the Xillybus author ?
17:36:38 <promach2> bcos_
17:41:10 <Mutabah> promach2: Did you end up confirming that the device saw the data you sent, and that it sent data back?
17:41:21 --- part: soulisson left #osdev
17:41:44 --- quit: isd (Quit: Leaving.)
17:42:33 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
17:43:39 <promach2> Mutabah: the FPGA did not see ALL the data I sent
17:44:00 <promach2> see http://forum.xillybus.com/viewtopic.php?f=4&p=1602#p1602
17:44:02 <bslsk05> forum.xillybus.com: The Xillybus Forum • View topic - problem with user_w_write_128_wren
17:46:43 * klys tickles teh xillybus
17:46:51 --- quit: ALowther (Ping timeout: 245 seconds)
17:47:45 --- quit: pisculichi (K-Lined)
17:55:30 <Mutabah> promach2: You should figure out the sequence of operations you expect to see in hardware, find the first deviation, then determine why that deviation appears (by first checking the documentation, then checkin the implementation)
17:55:38 <Mutabah> 99% chance this is a bug on your side
17:57:29 <promach2> I also hope that this is the case
17:59:47 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
18:03:02 --- quit: Tazmain (Ping timeout: 252 seconds)
18:03:18 --- quit: bemeurer (Ping timeout: 276 seconds)
18:04:23 --- quit: ALowther (Ping timeout: 248 seconds)
18:09:01 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
18:10:13 --- quit: variable (Quit: /dev/null is full)
18:13:19 --- quit: ALowther (Ping timeout: 240 seconds)
18:16:17 --- join: hmmmmm (~sdfgsf@pool-72-79-163-221.sctnpa.east.verizon.net) joined #osdev
18:18:36 <matlock> Intel is looking at bringing their super-fast Linux distro, Clear Linux, to WSL https://github.com/clearlinux/distribution/issues/74
18:18:38 <bslsk05> github.com: Package Clear Linux for WSL · Issue #74 · clearlinux/distribution · GitHub
18:18:54 --- quit: hmmmm (Ping timeout: 256 seconds)
18:19:43 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
18:21:28 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
18:21:43 --- quit: Fatalnix (Ping timeout: 264 seconds)
18:21:48 --- join: FatalNIX_ (~FatalNIX@caligula.lobsternetworks.com) joined #osdev
18:23:59 <promach2> Mutabah: I do not have direct control over both user_w_write_128_wren and user_r_read_128_rden signals
18:24:29 <promach2> these two control signals are what cause my problems
18:25:41 <Mutabah> But, you have documentation for them, which will state what causes them to change state.
18:25:55 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
18:30:30 --- quit: ALowther (Ping timeout: 248 seconds)
18:32:13 --- join: ljc (~ljc@unaffiliated/ljc) joined #osdev
18:39:02 --- join: bemeurer (~bemeurer@185.236.200.67) joined #osdev
18:41:30 --- quit: matlock (Read error: Connection reset by peer)
18:43:02 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
18:43:23 --- join: millerti (~millerti@cpe-66-24-91-119.stny.res.rr.com) joined #osdev
18:49:14 --- quit: ALowther (Ping timeout: 252 seconds)
18:52:24 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
18:55:27 --- quit: zwliew (Quit: Connection closed for inactivity)
18:56:51 --- quit: ALowther (Ping timeout: 245 seconds)
18:57:36 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
18:58:47 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
18:59:18 --- quit: drakonis (Ping timeout: 245 seconds)
19:01:07 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
19:02:15 --- quit: promach2 (Quit: WeeChat 2.1)
19:05:22 --- quit: ALowther (Ping timeout: 252 seconds)
19:12:44 --- quit: bemeurer (Ping timeout: 256 seconds)
19:14:15 --- quit: NaNkeen (Quit: leaving)
19:14:53 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
19:18:42 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
19:22:58 --- quit: ALowther (Ping timeout: 252 seconds)
19:25:47 --- quit: tacco| ()
19:32:01 --- quit: NaNkeen (Ping timeout: 256 seconds)
19:32:32 --- quit: drakonis_ (Remote host closed the connection)
19:34:35 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
19:36:17 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
19:37:35 --- quit: variable (Quit: /dev/null is full)
19:40:55 --- quit: ALowther (Ping timeout: 264 seconds)
19:43:51 --- quit: ljc (Quit: ayy)
19:44:31 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
19:46:27 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
19:53:29 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
19:56:58 --- quit: zlsyx (Quit: Leaving...)
19:58:01 --- quit: ALowther (Ping timeout: 260 seconds)
20:02:43 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
20:03:22 --- join: frolv (~frolv@CPE00fc8d4905d3-CM00fc8d4905d0.cpe.net.cable.rogers.com) joined #osdev
20:04:55 --- quit: JusticeEX (Ping timeout: 264 seconds)
20:06:02 --- nick: FatalNIX_ -> Fatalnix
20:06:21 --- quit: rpcope (Quit: ZNC - http://znc.in)
20:06:28 --- quit: Fatalnix (Changing host)
20:06:28 --- join: Fatalnix (~FatalNIX@unaffiliated/fatalnix) joined #osdev
20:06:38 --- join: rpcope (~GOTZNC@muon.copesystems.com) joined #osdev
20:06:51 --- quit: ALowther (Ping timeout: 245 seconds)
20:07:12 --- quit: rpcope (Client Quit)
20:15:25 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:20:14 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
20:20:54 --- quit: nj0rd (Ping timeout: 252 seconds)
20:24:34 --- quit: ALowther (Ping timeout: 252 seconds)
20:29:06 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
20:29:28 --- quit: Sonicbit (Quit: My iMac has gone to sleep. ZZZzzz…)
20:33:43 --- quit: ALowther (Ping timeout: 264 seconds)
20:36:46 --- join: nj0rd (~nj0rd@i577BC09A.versanet.de) joined #osdev
20:37:48 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
20:40:30 --- join: zlsyx (~zlsyx@193.2.224.100) joined #osdev
20:41:08 --- quit: regreg_ (Ping timeout: 256 seconds)
20:42:17 --- quit: ALowther (Ping timeout: 245 seconds)
20:42:22 --- join: bemeurer (~bemeurer@104.200.135.125) joined #osdev
20:46:16 --- quit: freakazoid0223_ (Quit: For Sale: Parachute. Only used once, never opened, small stain.)
20:46:38 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
20:50:49 --- quit: ALowther (Ping timeout: 240 seconds)
20:56:19 --- quit: NaNkeen (Ping timeout: 240 seconds)
21:04:12 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
21:06:53 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
21:07:28 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:08:54 --- quit: ALowther (Ping timeout: 256 seconds)
21:11:52 --- quit: NaNkeen (Ping timeout: 252 seconds)
21:13:23 --- quit: lachlan_s (Quit: Connection closed for inactivity)
21:13:52 --- join: scorpionillumin (~webmaster@cpe-24-193-187-73.nj.res.rr.com) joined #osdev
21:13:57 --- quit: `Guest00000 (Ping timeout: 240 seconds)
21:14:07 <scorpionillumin> how do i install i686-elf-as?
21:19:29 <scorpionillumin> the ./configure thing doesn't work and i already have binutils installed
21:21:49 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
21:24:38 <Mutabah> In what way does it not work? What's the command you ran and what was the output?
21:26:13 --- quit: scorpionillumin ()
21:26:41 --- quit: ALowther (Ping timeout: 260 seconds)
21:30:39 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
21:35:02 --- quit: ALowther (Ping timeout: 248 seconds)
21:39:31 --- join: lain0n (~lain0n@24-159-4-77.dhcp.smrt.tn.charter.com) joined #osdev
21:40:29 --- quit: janemba (Read error: Connection reset by peer)
21:43:45 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
21:48:07 --- join: hmmmmmm (~sdfgsf@pool-72-79-166-72.sctnpa.east.verizon.net) joined #osdev
21:48:12 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
21:51:07 --- quit: hmmmmm (Ping timeout: 260 seconds)
21:52:41 --- quit: ALowther (Ping timeout: 245 seconds)
21:56:37 --- quit: Dreg (Quit: Dreg)
21:57:00 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
21:57:15 --- join: Dreg (~Dreg@fr33project.org) joined #osdev
22:01:22 --- quit: ALowther (Ping timeout: 252 seconds)
22:05:43 --- join: wearingpants1 (~hassmilo@103.250.73.8) joined #osdev
22:06:14 --- quit: wearingpants1 (Remote host closed the connection)
22:07:21 --- join: wearingpants1 (~hassmilo@190-78-76-5.dyn.dsl.cantv.net) joined #osdev
22:11:46 <wearingpants1> there was a question about hazards by glauxosdever aside from RFA in hw fifo hazards are handled in the following way, when you have instances or for loop which is the same thing, evaluation of the loop is done sequentially, execution of those instances are at another hand handled in parallel, so if the values did not change ti will skip, if the had, the inputs are sequentially feed
22:12:22 <geist> uh?
22:12:28 <wearingpants1> which means hw takes care of the hazards, when port is ooccupied, it will skip
22:14:33 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
22:18:26 --- quit: drakonis (Remote host closed the connection)
22:18:46 --- quit: eremitah (Ping timeout: 248 seconds)
22:19:07 --- quit: ALowther (Ping timeout: 260 seconds)
22:19:43 --- join: eremitah (~int@unaffiliated/eremitah) joined #osdev
22:20:57 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
22:28:55 <wearingpants1> RAW hazards can not happen, cause compiler does not allow this to happen and WAW hazards are taken care of this sequential evaluation phenomen, that is inherent verilog hw language property, depending whether the hw is vliw or SIMD, then first pixel is handled either by scoreboard or compilers static scheduling, when they land into flops they are from there on handled without issues like i said
22:30:40 --- join: Rodya_ (~Rodya_@64.62.224.29) joined #osdev
22:32:13 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
22:36:33 <wearingpants1> i went to toilet, lemme come again i messed up, i meant not RAW, but WAR, RAW hazards are handled in the fifo
22:36:44 --- quit: ALowther (Ping timeout: 256 seconds)
22:37:04 <wearingpants1> by register file that do not eecute until write is commited, cause of otherwise the value did not change and it will skip
22:37:35 --- mode: ChanServ set +o Mutabah
22:38:01 --- kick: wearingpants1 was kicked by Mutabah (This is off-topic for this channel)
22:40:53 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
22:44:41 --- join: cockypervo (~maestro@209.141.152.195) joined #osdev
22:45:11 --- quit: ALowther (Ping timeout: 245 seconds)
22:45:35 <cockypervo> Mutabah: you still think your perverse puke not handling the defeat pretending to be all winners, is only ontopic in the world of programming?
22:46:07 <cockypervo> i advise a defeat to be learned from to anyone really, to come out stronger next time
22:46:17 <cockypervo> defeats happen in any competitive
22:46:26 <cockypervo> event, to anyone really
22:46:38 <cockypervo> it is how you learn btw.
22:48:29 --- kick: cockypervo was kicked by Mutabah (Really, because no matter how many times you're kicked, you never learn)
22:50:51 --- join: aussies_screwd (~probable@gprs-inet-65-55.elisa.ee) joined #osdev
22:51:12 --- mode: Mutabah set +q aussies_screwd!*@*
22:51:38 --- quit: aussies_screwd (Client Quit)
22:52:48 --- join: hasmailrebon (~rabusto@202.58.176.52) joined #osdev
22:53:33 <variable> Mutabah: thanks
22:53:35 <hasmailrebon> yeah sure, but this isn't a defeat either, it is bunch of cockblockers cheating and violating from australia, being suicidal cows saying about how the play in sandbox and stalk and lure my home address at the same time
22:53:50 <variable> (and its back)
22:54:00 --- mode: Mutabah set +q *!*@202.58.176.52
22:55:17 --- quit: hasmailrebon (Client Quit)
22:58:33 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
23:03:36 --- quit: ALowther (Ping timeout: 268 seconds)
23:05:59 --- join: rebustosanches (~chinasfou@187.138.33.145) joined #osdev
23:06:44 <rebustosanches> all you cockyblocky Mutabah can do is manipulate weaker women if even that, in mens class you are entire outsider.
23:06:55 <klys> boing
23:07:00 <rebustosanches> powergang dude
23:09:28 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
23:11:35 --- mode: Mutabah set +q rebustosanches!*@*
23:11:50 <klys> http://ichef.bbci.co.uk/news/976/mcs/media/images/82378000/jpg/_82378090_dog2thinkstock.jpg
23:12:32 <Mutabah> d'aww cute pupper
23:12:38 <klys> :)
23:14:58 --- quit: rebustosanches (Quit: Leaving)
23:16:06 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
23:20:43 --- quit: ALowther (Ping timeout: 260 seconds)
23:24:50 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
23:29:22 --- quit: ALowther (Ping timeout: 252 seconds)
23:30:09 --- quit: Guest46587 (Changing host)
23:30:09 --- join: Guest46587 (~user@unaffiliated/mrush) joined #osdev
23:30:51 --- nick: Guest46587 -> mrush
23:41:44 <variable> klys: tis not a platypus
23:44:03 --- join: oaken-source (~oaken-sou@p5DDB5EE8.dip0.t-ipconnect.de) joined #osdev
23:45:22 --- join: bemeurer_ (~bemeurer@50-0-205-242.dsl.dynamic.sonic.net) joined #osdev
23:46:48 --- quit: lain0n (Quit: Leaving)
23:47:31 --- quit: bemeurer (Ping timeout: 264 seconds)
23:50:17 --- join: dbe (~dbe@h-141-38.A336.priv.bahnhof.se) joined #osdev
23:51:15 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
23:55:27 --- quit: ALowther (Ping timeout: 240 seconds)
23:56:57 --- join: Asu (~sdelang@52.82.136.77.rev.sfr.net) joined #osdev
23:59:59 --- log: ended osdev/18.05.26