Search logs:

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=23

Wednesday, 23 May 2018

00:00:00 --- log: started osdev/18.05.23
00:11:12 --- quit: Sonicbit (Ping timeout: 252 seconds)
00:21:30 --- quit: sdk93 (Quit: Connection closed for inactivity)
00:23:20 --- quit: mrush (Ping timeout: 276 seconds)
00:24:37 --- join: mrush (~user@64.72.212.39) joined #osdev
00:25:00 --- nick: mrush -> Guest20673
00:25:28 --- join: bemeurer (~bemeurer@185.236.200.72) joined #osdev
00:28:04 --- quit: epony (Quit: QUIT)
00:32:42 --- quit: MDude (Ping timeout: 245 seconds)
00:34:00 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
00:41:17 --- quit: Goplat (Remote host closed the connection)
00:41:47 --- quit: bemeurer (Quit: WeeChat 2.1)
00:44:07 --- join: dijksterhuis (~dijksterh@cpc103046-sgyl39-2-0-cust267.18-2.cable.virginm.net) joined #osdev
00:45:57 --- join: `Guest00000 (~user@37.113.160.44) joined #osdev
00:48:15 --- quit: dijksterhuis (Client Quit)
00:50:04 --- join: bemeurer (~bemeurer@185.236.200.72) joined #osdev
00:53:07 --- quit: mavhq (Read error: Connection reset by peer)
00:54:21 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
00:55:51 --- quit: Salek (Ping timeout: 260 seconds)
00:56:38 --- join: bauen1 (~bauen1@ANancy-655-1-125-48.w90-6.abo.wanadoo.fr) joined #osdev
00:57:39 --- join: oaken-source (~oaken-sou@p5DDB4E7A.dip0.t-ipconnect.de) joined #osdev
00:58:43 --- join: sympt (~sympt@209.58.139.34) joined #osdev
01:01:39 --- quit: AverageJ0e (Ping timeout: 256 seconds)
01:16:23 --- quit: doug16k (Ping timeout: 260 seconds)
01:17:13 --- join: Kimundi_ (~Kimundi@dynip-129-217-067-155.wifi.tu-dortmund.de) joined #osdev
01:25:28 --- quit: bemeurer (Quit: WeeChat 2.1)
01:27:57 --- quit: oaken-source (Ping timeout: 240 seconds)
01:29:42 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
01:30:04 --- quit: sympt (Remote host closed the connection)
01:30:36 --- join: sympt (~sympt@209.58.139.34) joined #osdev
01:30:51 --- quit: sympt (Remote host closed the connection)
01:32:13 --- join: epony (~nym@77-85-143-102.ip.btc-net.bg) joined #osdev
01:35:33 --- quit: NaNkeen (Ping timeout: 245 seconds)
01:35:37 --- join: JonRob (jon@gateway/vpn/privateinternetaccess/jonrob) joined #osdev
01:42:46 --- join: usiad (c287984a@gateway/web/freenode/ip.194.135.152.74) joined #osdev
01:42:52 <usiad> Hey
01:43:05 <usiad> A primary opcode can be 1, 2, or 3 bytes in length. An additional 3-bit opcode field is sometimes encoded in the ModR/M byte
01:43:13 <usiad> That's what volume 2 of Intel SDM says
01:43:39 <usiad> Does it mean that sometimes opcode itself can be 3 byte + 3 bit
01:43:55 <usiad> So that it overflows into where ModR/M normally is?
01:44:37 <usiad> Rest of the paragraph: "Smaller fields can be defined within the primary opcode. Such fields define the direction of operation, size of displacements, register encoding, condition codes, or sign extension. Encoding fields used by an opcode vary depending on the class of operation."
01:44:38 --- quit: hmmmm (Remote host closed the connection)
01:44:58 <usiad> Can someone help me understand what the hell opcode field is please?
01:46:56 <Mutabah> From my reading of that, they're overloading 'opcode' to refer to the instruction-identifing bits/numbers, and also to refer to the bytes of the instruction
01:47:35 <usiad> Aren't both instruction-identifying bits?
01:47:36 <Mutabah> The "3-bit opcode field" is part of the ModR/M byte (iirc it's the `rrr` portion), used when the instruction doesn't need to specify a second operand
01:47:58 --- join: vaibhav (~vnagare@125.16.97.123) joined #osdev
01:48:33 <Mutabah> depends on your point of view
01:48:57 <usiad> What picture are you looking at where it's marked with 'rrr'?
01:49:25 <Mutabah> There's some instructions (POP r iirc is one) where the opcode is the top five bits, and the target register is the bottom three (of the first and only byte)
01:49:52 <Mutabah> usiad: Not sure where I got that from, they're the bottom three bits of the modr/m byte if my memory serves correctly?
01:50:21 --- quit: gxt (Ping timeout: 276 seconds)
01:50:23 --- quit: ampotos (Ping timeout: 256 seconds)
01:52:04 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
01:52:19 <usiad> You mean like POP - as 1 byte opcode - encodes both the operation type itself and the target register
01:52:54 <Mutabah> Yes.
01:53:13 <geist> http://sandpile.org/x86/opc_enc.htm mayyyy help, but it may also confuse
01:53:14 <bslsk05> ​sandpile.org: sandpile.org -- x86 architecture -- opcode encoding
01:53:16 <geist> it's dense
01:53:20 <usiad> So it's not really encoded in the "ModR/M byte"
01:53:44 <Mutabah> usiad: Those were two different caes
01:54:15 <Mutabah> usiad: x86 is NOT orthogonal, some instructions are one byte, others can be 9 bytes
01:54:28 <usiad> Is manual trying to say that, sometimes 3 bytes is not enough so it overflows 3 bits into place of ModR/M?
01:54:29 <Mutabah> (the architectural limit is 13 bytes, including prefixes)
01:54:36 <Mutabah> Kinda, yeah
01:54:38 --- join: ampotos (~ampotos@lew31-1-78-247-114-197.fbx.proxad.net) joined #osdev
01:54:45 <geist> yah that page i just linked has essentially all the combinations
01:54:58 <geist> and links to the opcode tables and layout of modr/m and sib byte
01:55:18 <geist> if you go a little ways down to 'instruction encoding' it starts to lay out the structure for 1 and more byte opcodes
01:55:23 <usiad> I have hard time understanding those tables
01:55:35 <geist> that's because it's very complicated
01:58:24 --- quit: nj0rd (Quit: WeeChat 2.1)
01:58:27 --- join: mra90 (~Martin@host-85-202-159-241.sta.tvknaszapraca.pl) joined #osdev
01:59:34 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
01:59:45 --- join: ljc (~ljc@unaffiliated/ljc) joined #osdev
02:01:00 --- quit: Burgundy (Remote host closed the connection)
02:01:59 --- join: nj0rd (~nj0rd@mue-88-130-48-053.dsl.tropolys.de) joined #osdev
02:11:00 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
02:14:15 --- quit: Guest20673 (Ping timeout: 260 seconds)
02:15:02 --- join: mrush (~user@64.72.212.39) joined #osdev
02:15:26 --- nick: mrush -> Guest32769
02:16:52 --- quit: azonenberg (Ping timeout: 245 seconds)
02:17:35 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
02:19:22 --- join: azonenberg (~azonenber@chat.dmz.bainbridge.antikernel.net) joined #osdev
02:21:59 --- quit: ALowther (Ping timeout: 248 seconds)
02:22:14 --- quit: usiad (Quit: Page closed)
02:26:09 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
02:28:14 --- join: KidBeta (~textual@61.68.91.220) joined #osdev
02:35:02 --- quit: Guest32769 (Ping timeout: 256 seconds)
02:36:58 --- join: mrush_ (~user@64.72.212.39) joined #osdev
02:38:05 --- quit: Kimundi_ (Remote host closed the connection)
02:38:12 --- join: Kimundi_ (~Kimundi@dynip-129-217-067-155.wifi.tu-dortmund.de) joined #osdev
02:39:22 --- join: Kimundi__ (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
02:41:31 --- quit: awordnot (Ping timeout: 264 seconds)
02:41:52 --- join: awordnot (~awordnot@67.184.137.130) joined #osdev
02:42:42 --- quit: Kimundi_ (Ping timeout: 245 seconds)
02:53:51 --- join: Arcaelyx (~Arcaelyx@2604:2000:f14a:2500:8589:27c8:f0fc:b731) joined #osdev
02:55:19 --- quit: Arcaelyx_ (Ping timeout: 260 seconds)
02:59:03 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
03:06:54 <ljc> makefiles are hard
03:07:20 <ljc> but so satisfying when they work
03:08:25 <klange> Makefile is a powerful tool that has been abused for years by autoconf.
03:08:41 <klange> Make*
03:08:55 <rain1> i got sick of make one day and decided not to use it again
03:09:34 <ljc> what do you use rain1 ?
03:09:54 * klange uses Make with some help from an automatic generator
03:10:04 <ljc> oh?
03:10:07 <klange> https://github.com/klange/toaru-nih/blob/master/Makefile + https://github.com/klange/toaru-nih/blob/master/util/auto-dep.py
03:10:08 <bslsk05> ​github.com: toaru-nih/Makefile at master · klange/toaru-nih · GitHub
03:10:10 <bslsk05> ​github.com: toaru-nih/auto-dep.py at master · klange/toaru-nih · GitHub
03:10:16 <rain1> https://github.com/rain-1/makes i made this but I may mkae something in future that can do parallel builds too
03:10:17 <bslsk05> ​rain-1/makes - replacement for make (1 forks/6 watchers)
03:11:23 --- quit: aalm (Ping timeout: 245 seconds)
03:13:49 --- join: aalm (~aalm@37-219-100-76.nat.bb.dnainternet.fi) joined #osdev
03:19:12 <bauen1> make is awesome, I read somewhere someone made an init system based around make but couldn't find any more info
03:21:52 <ybden> someone made an init system around systemd, does that make it awesome? ;)
03:22:04 <_mjg_> you are waiting for a unikernel
03:22:09 <_mjg_> don't do that
03:28:58 --- join: stav (~stavvvv@athedsl-13130.home.otenet.gr) joined #osdev
03:30:16 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
03:31:10 --- quit: cirno_ (Remote host closed the connection)
03:31:33 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
03:38:48 --- quit: jordyd (Quit: Bye!)
03:39:08 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
03:41:17 --- join: jordyd (~jordyd@pampanic/co-maintainer/jordyd) joined #osdev
03:43:34 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
03:44:33 --- join: nur (~hussein@175.142.120.67) joined #osdev
03:58:00 --- join: FMan (~fooman@82-203-185-31.bb.dnainternet.fi) joined #osdev
03:58:23 --- quit: ljc (Quit: ayy)
04:00:53 --- quit: cirno_ (Remote host closed the connection)
04:01:27 --- join: SwiftMatt (~Objective@2601:282:4300:3e:4cf9:b04e:a11b:e772) joined #osdev
04:01:36 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:04:15 --- quit: SwiftMatt (Client Quit)
04:09:18 <variable> hihi
04:17:46 <lkurusa> lmao unikernels
04:20:42 --- join: cirno__ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:21:35 --- join: cirno___ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:23:53 --- quit: cirno_ (Ping timeout: 250 seconds)
04:24:16 <Love4Boobies> Why are unikernels funny?
04:24:27 <Love4Boobies> They seem well-suited for specialized tasks.
04:24:41 --- quit: spare (Quit: leaving)
04:24:56 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:25:08 <Love4Boobies> All soutions are context-sensitive.
04:25:11 --- quit: cirno__ (Ping timeout: 250 seconds)
04:25:58 --- join: cirno__ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:27:00 --- join: cirno____ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:27:47 --- quit: cirno___ (Ping timeout: 250 seconds)
04:29:07 <izabera> they're funny because people are stupid
04:29:31 --- quit: cirno_ (Ping timeout: 250 seconds)
04:30:23 --- quit: cirno__ (Ping timeout: 250 seconds)
04:30:53 --- quit: cirno____ (Remote host closed the connection)
04:30:54 <rain1> r/iamverysmart
04:31:32 --- join: cirno____ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:36:02 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
04:41:00 --- join: Shikadi (~Shikadi@cpe-98-10-34-205.rochester.res.rr.com) joined #osdev
04:42:41 --- quit: Humble (Ping timeout: 276 seconds)
04:45:52 --- join: GhelloWorld (d5223903@gateway/web/freenode/ip.213.34.57.3) joined #osdev
04:46:56 --- quit: GhelloWorld (Client Quit)
04:52:05 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
04:54:49 --- join: Humble (~hchiramm@2405:204:d185:211c:c110:7230:2af0:f958) joined #osdev
04:55:33 --- quit: mra90 (Read error: Connection reset by peer)
04:57:57 --- quit: Naabed-_ (Ping timeout: 240 seconds)
04:58:03 --- quit: Griwes (Ping timeout: 260 seconds)
04:58:31 --- quit: aiwakura (Ping timeout: 268 seconds)
05:00:54 --- quit: cirno____ (Remote host closed the connection)
05:01:29 --- join: cirno____ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
05:02:35 --- quit: rain1 (Remote host closed the connection)
05:04:28 --- join: Kimundi_ (~Kimundi@dynip-129-217-067-155.wifi.tu-dortmund.de) joined #osdev
05:05:52 --- join: Griwes (~griwes@znc.reaver-project.org) joined #osdev
05:05:54 --- join: aiwakura (~aiwakura@163.172.213.86) joined #osdev
05:06:27 --- quit: Humble (Ping timeout: 260 seconds)
05:06:39 --- quit: awang (Ping timeout: 276 seconds)
05:07:09 --- quit: Kimundi__ (Ping timeout: 268 seconds)
05:07:29 --- join: Naabed- (~Naabed-@ams-1.poolp.org) joined #osdev
05:17:04 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
05:18:17 --- join: Humble (~hchiramm@2405:204:d208:6e17:1372:80cc:8eb2:3296) joined #osdev
05:19:54 --- join: lijero (~lijero@unaffiliated/lijero) joined #osdev
05:21:05 --- quit: jakogut (Quit: jakogut)
05:21:32 --- join: jakogut (~jakogut_@68.116.64.178) joined #osdev
05:24:54 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
05:25:36 --- quit: jakogut (Client Quit)
05:26:03 --- join: jakogut (~jakogut_@68.116.64.178) joined #osdev
05:26:04 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
05:27:43 --- quit: awang (Ping timeout: 264 seconds)
05:28:18 --- quit: cirno____ (Quit: WeeChat 2.1)
05:34:22 --- quit: lijero (Remote host closed the connection)
05:35:21 --- join: regreg (~regreg@85.121.54.224) joined #osdev
05:35:51 --- quit: oaken-source (Ping timeout: 260 seconds)
05:40:23 --- join: awang (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
05:41:53 --- join: gxt (~gxt@2a02:908:e851:4020:ba27:ebff:fe06:f1a0) joined #osdev
05:49:51 --- join: Boreeas (~mu@boreeas.net) joined #osdev
05:50:08 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:51:15 --- quit: jmill (Ping timeout: 260 seconds)
05:51:44 --- join: findsomebrain (~randioso@ip133.ip-192-99-88.net) joined #osdev
05:53:17 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
05:55:49 <findsomebrain> i would depart from everywhere including life it's own, cause of so many idiots who have regulated my stuff, but i care about technology and the fact that there is some higher intelligents where future victims like me can take part, however i dissapointingly find that you for instance have not got any sense behind what you do, on all biggest freenode programming channels, and that in particular needs to change, you can not ruin the
05:55:49 <findsomebrain> momentum and code of the allready enough violated special people
05:56:05 <findsomebrain> they also need to have some chanche of what to do
05:58:28 --- quit: banisterfiend (Ping timeout: 256 seconds)
05:58:35 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
05:59:58 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
06:00:54 --- quit: findsomebrain (Quit: Leaving)
06:01:14 <bauen1> that guy lasted 9 minutes and 10 seconds
06:02:08 <stav> lol
06:06:30 <variable> [04:24:46] <Love4Boobies> All soutions are context-sensitive.
06:06:31 <variable> this so much
06:09:18 --- join: glauxosdever (~alex@ppp-94-66-39-88.home.otenet.gr) joined #osdev
06:10:09 --- join: dennis95 (~dennis@mue-88-130-61-236.dsl.tropolys.de) joined #osdev
06:18:33 --- join: oaken-source (~oaken-sou@p5DDB4E7A.dip0.t-ipconnect.de) joined #osdev
06:20:11 <Love4Boobies> Wbat the hell was that nonsense above.
06:20:22 <Mutabah> mard
06:20:24 <Love4Boobies> He should listen to his nickname.
06:23:58 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
06:27:24 <bauen1> a troll without patience but an IRC client
06:27:36 <bauen1> *with an
06:28:09 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:29:47 --- quit: regreg (Ping timeout: 268 seconds)
06:33:25 --- join: Guest4630 (4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72) joined #osdev
06:44:43 --- join: Burgundy (~yyomony@86.121.78.25) joined #osdev
06:47:32 --- join: regreg (~regreg@85.121.54.224) joined #osdev
06:50:22 --- join: warrshrike (af6e44c0@gateway/web/freenode/ip.175.110.68.192) joined #osdev
06:50:32 --- part: warrshrike left #osdev
06:53:38 --- join: jmill (~textual@2605:6000:1019:3ff:9026:8dd0:6b0b:837a) joined #osdev
06:54:27 --- quit: X-Scale (Ping timeout: 268 seconds)
06:56:07 --- quit: bauen1 (Ping timeout: 260 seconds)
06:59:31 --- join: freakazoid0223_ (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
06:59:54 --- quit: return0e_ (Read error: Connection reset by peer)
07:01:02 --- quit: freakazoid0223 (Ping timeout: 245 seconds)
07:03:35 --- quit: Kimundi_ (Ping timeout: 260 seconds)
07:06:31 --- join: Kimundi_ (~Kimundi@dynip-129-217-067-155.wifi.tu-dortmund.de) joined #osdev
07:08:51 --- quit: Guest4630 (Remote host closed the connection)
07:11:03 --- quit: jmill (Ping timeout: 260 seconds)
07:16:46 --- join: X-Scale (~ARM@83.223.227.20) joined #osdev
07:19:43 --- quit: JonRob (Ping timeout: 245 seconds)
07:21:15 --- join: Asu (~sdelang@180.83.136.77.rev.sfr.net) joined #osdev
07:21:29 --- join: JonRob (jon@gateway/vpn/privateinternetaccess/jonrob) joined #osdev
07:30:23 --- quit: xenos1984 (Quit: Leaving.)
07:32:07 --- join: jmill (~textual@2605:6000:1019:3ff:9026:8dd0:6b0b:837a) joined #osdev
07:32:52 --- join: hmmmm (~sdfgsf@pool-72-79-164-159.sctnpa.east.verizon.net) joined #osdev
07:34:04 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
07:34:47 --- quit: drakonis (Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number)
07:35:14 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
07:37:57 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
07:40:54 * Vercas hasn't had his way with a good troll in ages.
07:41:09 --- quit: aalm (Quit: xyz 2.0.1)
07:46:19 --- quit: NaNkeen (Ping timeout: 264 seconds)
07:48:57 --- quit: jmill (Ping timeout: 245 seconds)
07:49:41 --- join: Asu` (~sdelang@AMarseille-658-1-70-125.w86-203.abo.wanadoo.fr) joined #osdev
07:50:15 --- quit: Asu (Ping timeout: 260 seconds)
07:51:51 --- quit: stav (Quit: Leaving)
07:53:28 --- join: light2yellow (~l2y@217.30.64.102) joined #osdev
07:56:34 --- join: jmill (~textual@2605:6000:1019:3ff:9026:8dd0:6b0b:837a) joined #osdev
07:57:03 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
08:00:31 --- quit: regreg (Ping timeout: 260 seconds)
08:00:42 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:00:55 --- quit: cirno_ (Remote host closed the connection)
08:01:40 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:02:03 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
08:21:58 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
08:27:11 --- quit: NaNkeen (Ping timeout: 260 seconds)
08:28:02 --- join: cirno__ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:30:55 --- quit: cirno_ (Remote host closed the connection)
08:30:55 --- quit: cirno__ (Remote host closed the connection)
08:31:27 --- join: cirno__ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:34:38 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
08:38:43 --- quit: grouse (Quit: Leaving)
08:42:45 --- quit: Arcaelyx (Quit: Textual IRC Client: www.textualapp.com)
08:48:49 --- quit: JusticeEX (Ping timeout: 240 seconds)
08:53:28 --- join: MDude (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
08:53:48 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
08:54:55 <pounce> t-t-t-triple-fault
08:57:28 --- join: bauen1 (~bauen1@ANancy-655-1-125-48.w90-6.abo.wanadoo.fr) joined #osdev
08:58:32 --- quit: NaNkeen (Ping timeout: 245 seconds)
09:00:42 --- join: daniele_athome (~daniele_a@5.170.128.14) joined #osdev
09:00:54 --- quit: cirno__ (Remote host closed the connection)
09:02:46 --- quit: Kimundi_ (Ping timeout: 260 seconds)
09:05:15 <pounce> What is the error code in a #GP?
09:09:12 <pounce> so if I don't set the DPL for a interrupt and try to invoke it (in ring zero) will it fault?
09:10:05 --- quit: nur (Remote host closed the connection)
09:15:22 --- quit: drakonis (Remote host closed the connection)
09:16:26 --- quit: daniele_athome (Ping timeout: 252 seconds)
09:18:55 --- quit: jmill (Ping timeout: 260 seconds)
09:22:11 --- join: daniele_athome (~daniele_a@5.170.120.157) joined #osdev
09:23:40 --- join: m3nt4L (~asvos@2a02:587:a023:f000:3285:a9ff:fe8f:665d) joined #osdev
09:27:53 --- join: nur (~hussein@175.142.120.67) joined #osdev
09:30:49 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
09:34:08 --- quit: tylerdmace (Ping timeout: 260 seconds)
09:34:17 --- join: Kimundi_ (~Kimundi@i577A9054.versanet.de) joined #osdev
09:36:18 --- join: tylerdmace (~tylerdmac@pool-98-116-102-65.nycmny.fios.verizon.net) joined #osdev
09:39:26 --- join: rain1 (~rain1@unaffiliated/rain1) joined #osdev
09:46:23 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
09:48:04 --- quit: AverageJ0e (Quit: Leaving)
09:49:22 --- quit: JusticeEX (Ping timeout: 245 seconds)
09:49:58 <jjuran> pounce: Sounds like the final end of the System Shock series
09:50:30 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
10:03:42 --- quit: dbittman_ (Ping timeout: 276 seconds)
10:15:12 --- join: usiad (~user@194.135.153.94) joined #osdev
10:23:21 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
10:28:53 --- join: jmill (~textual@2605:6000:1019:3ff:9026:8dd0:6b0b:837a) joined #osdev
10:34:59 --- join: sdk93 (uid290141@gateway/web/irccloud.com/x-jgmdspkhnvxgylci) joined #osdev
10:35:54 --- quit: vaibhav (Quit: Leaving)
10:40:33 --- quit: davxy (Ping timeout: 245 seconds)
10:41:21 --- join: davxy (~davxy@unaffiliated/davxy) joined #osdev
10:44:55 --- quit: daniele_athome (Ping timeout: 248 seconds)
10:47:22 --- quit: `Guest00000 (Ping timeout: 252 seconds)
10:50:05 --- join: daniele_athome (~daniele_a@5.170.128.2) joined #osdev
10:54:42 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
10:59:28 --- quit: NaNkeen (Ping timeout: 252 seconds)
10:59:34 --- join: `Guest00000 (~user@37.113.160.44) joined #osdev
11:00:08 --- quit: bauen1 (Ping timeout: 245 seconds)
11:04:58 --- quit: `Guest00000 (Ping timeout: 252 seconds)
11:04:58 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
11:08:20 --- join: lnnb (~weechat@unaffiliated/icetooth) joined #osdev
11:14:20 --- join: return0e (~return0e@5-198-102-244.static.kc.net.uk) joined #osdev
11:16:59 --- quit: divine (Ping timeout: 260 seconds)
11:17:38 --- quit: usiad (Quit: WeeChat 2.1)
11:23:03 --- quit: baschdel (Ping timeout: 245 seconds)
11:23:40 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
11:25:53 --- quit: glfernando (Quit: Leaving)
11:27:52 <doug16k> pounce, you don't set the DPL of an interrupt, you set the code segment selector for that vector in the IDT, and that code segment selector selects a GDT descriptor that has a DPL
11:28:52 <doug16k> you must mean software interrupts though
11:29:12 <doug16k> that DPL indicates the privilege required to invoke that interrupt
11:30:06 <doug16k> in other words, the DPL in the IDT determines how much privilege is required to invoke that interrupt. once invoked, the code segment selector in the IDT determines the privilege at which the handler runs
11:35:03 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-aalfrxtxxoujmvvs) joined #osdev
11:35:07 <pounce> doug16k: yeah, I'm working on scheduling and I want to make a yield interrupt. I set this to vector `0x22` and ran `int 0x22` but then I got a 0x22, 0xD,0xD, 0x8 in quick succession and it triple-faulted
11:35:32 <pounce> also none of my ISRs actually ran, the faulting address in QEMU for each of the interrupts was the address of the `int 0x22`
11:36:16 <pounce> (I don't see how it could triple-fault at all, I have a #DF handler with a separate stack and everything)
11:36:27 <doug16k> what value are you putting in the segment selector field in the idt?
11:36:43 <pounce> my current cs
11:37:11 <doug16k> ya, what value is that though?
11:37:30 <pounce> Also I thought it could be the code segment, so I swapped some things around and set up the IDT after the gdt, but that didn't change it
11:38:50 <pounce> oh...
11:38:59 <doug16k> #GP is often a segment problem
11:39:20 <doug16k> the error code to GP is the problem selector when it is a segment problem
11:39:41 <doug16k> otherwise, it is #GP(0)
11:40:00 <pounce> doug16k: I init scheduling before interrupts, so I didn't have an idt loaded...
11:40:05 <pounce> sorry for wasting your time
11:40:14 --- join: glfernando (glfernando@nat/google/x-zlbkwkwyaebxgzja) joined #osdev
11:40:36 <pounce> doug16k: but yeah, that was weirding me out because the error code was something like 222
11:40:37 --- quit: daniele_athome (Ping timeout: 245 seconds)
11:41:37 <pounce> In other news, successfully context switched to a new thread!
11:41:49 --- join: daniele_athome (~daniele_a@5.170.128.2) joined #osdev
11:43:02 <doug16k> makes sense: "If the fault condition was detected while loading a segment descriptor, the error code contains a segment selector to or IDT vector number for the descriptor; otherwise, the error code is 0"
11:43:56 <doug16k> ^ #GP docs
11:48:41 <pounce> ah, makes sense
11:49:32 --- quit: robert_ (Read error: Connection reset by peer)
11:49:32 --- join: robert_|disconne (~hellspawn@24.96.111.33) joined #osdev
11:55:37 --- quit: bork (Ping timeout: 245 seconds)
11:56:27 --- join: korans (~korans@5.42.131.31) joined #osdev
11:56:31 --- part: korans left #osdev
11:56:39 --- join: korans (~korans@5.42.131.31) joined #osdev
11:57:10 --- join: zenix_2k2 (~zenix_2k2@1.52.39.165) joined #osdev
11:58:51 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
11:59:00 --- part: zenix_2k2 left #osdev
12:00:09 --- quit: bork (Excess Flood)
12:00:20 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
12:00:26 --- quit: pounce (Quit: WeeChat 2.1)
12:00:49 --- join: josuedhg (~josuedhg_@192.55.54.42) joined #osdev
12:03:13 --- join: divine (~divine@2001:470:8247:2::1000) joined #osdev
12:03:23 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
12:09:16 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
12:09:18 --- join: tacco| (~tacco@i59F4AFEF.versanet.de) joined #osdev
12:10:32 --- join: zeus1 (~zeus@h11ed.n1.ips.mtn.co.ug) joined #osdev
12:21:37 --- quit: spare (Quit: leaving)
12:22:33 --- quit: jakogut (Remote host closed the connection)
12:25:41 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
12:26:21 --- quit: daniele_athome (Ping timeout: 260 seconds)
12:26:29 --- quit: elevated (Quit: bye)
12:30:09 --- quit: return0e (Ping timeout: 256 seconds)
12:30:48 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
12:31:58 --- quit: elevated (Client Quit)
12:32:44 --- join: attah (~attah@h-155-4-135-114.NA.cust.bahnhof.se) joined #osdev
12:34:31 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
12:37:30 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
12:42:06 --- quit: JusticeEX (Ping timeout: 260 seconds)
12:48:15 --- join: daniele_athome (~daniele_a@5.170.121.95) joined #osdev
12:51:30 <Ameisen> So... any thoughts on how Intel plans on rectifying the issues they're having security-wise?
12:51:41 <Ameisen> it appears a few of them are intrinsic to how they're handling out-of-order execution?
12:52:37 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
12:53:42 <graphitemaster> we take all intel cpus right, put them in a big vat of lava, let all of those minerals mix in with the lava, and recycle it all, the first step is getting the lava for the vat, for that we get all the AMD cpus, put them in an empty vat but power them.
12:54:06 <graphitemaster> that's my idea, do you have a better one Ameisen ?
12:54:15 <lnnb> it's not just intel, other arch's affected
12:54:44 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
12:55:15 <geist> throw it in the molten steel like at the end of T2
12:56:23 <graphitemaster> I love the terminator argument the best, "it can't be that bad because if it was someone from the future would've come back to warn us about the judgement day"
12:56:39 <graphitemaster> no stacy, that's not how any of this works!
12:56:52 <graphitemaster> terminatory was not a documentary
12:56:57 <graphitemaster> it was an action film
12:56:59 <graphitemaster> dammit stacy
12:57:03 <graphitemaster> *terminator
12:58:19 --- quit: NaNkeen (Ping timeout: 264 seconds)
13:01:28 --- join: user10032 (~Thirteen@2a02:c7d:314e:b300:499e:523d:ed98:c288) joined #osdev
13:03:14 <Ameisen> lnnb - I know
13:03:17 <Ameisen> IIRC, Intel was a bit worse
13:03:22 <Ameisen> since they were doing less checking for protected instructions
13:03:29 <Ameisen> I have a Skylake X
13:03:36 <Ameisen> I'm dismayed to see it slowly get slower as microcode updates come out
13:03:40 <Ameisen> :(
13:03:54 --- join: `Guest00000 (~user@37.113.160.44) joined #osdev
13:04:32 <lnnb> lol tell me about it, i'm running a core2 grep performance is shot
13:06:14 --- join: baschdel_ (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
13:07:18 <Ameisen> I'm surprised that there aren't any class-action suits about it
13:07:26 <Ameisen> I mean... a lot of people have to be rather unhappy
13:08:00 --- quit: hiei (Ping timeout: 256 seconds)
13:08:03 --- quit: baschdel (Read error: Connection reset by peer)
13:08:34 --- quit: SlashLife (Ping timeout: 256 seconds)
13:09:03 --- join: SlashLife (~slashlife@aperturescience.tech) joined #osdev
13:09:42 --- quit: light2yellow (Quit: light2yellow)
13:10:31 --- join: hiei (jinzo@gateway/shell/elitebnc/x-fexoicetujstdiis) joined #osdev
13:11:16 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
13:17:20 --- join: ryoshu (~kamil@netbsd/developer/kamil) joined #osdev
13:17:21 <ryoshu> hi
13:17:21 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:17:46 <ryoshu> is there a good replacement for syscall()?
13:21:48 --- quit: daniele_athome (Ping timeout: 245 seconds)
13:23:53 --- quit: baschdel_ (Ping timeout: 245 seconds)
13:24:11 --- join: daniele_athome (~daniele_a@5.170.121.95) joined #osdev
13:24:23 --- quit: attah (Remote host closed the connection)
13:27:36 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
13:28:51 <izabera> what
13:29:12 <izabera> what's the problem with syscall() and what environment do you want to replace it in?
13:30:24 <ryoshu> UNIX environment
13:30:41 --- quit: m3nt4L (Quit: Leaving)
13:30:43 <ryoshu> some people thing that it's broken to use
13:31:08 <ryoshu> and convert 32/64 arguments
13:31:13 <ryoshu> or split them
13:32:14 <ryoshu> I wonder is there is a replacement
13:32:35 <izabera> syscall is a good way to throw away the type safety of all the other libc functions
13:32:39 <ryoshu> to get indirect system call
13:33:04 <izabera> (there's not even that much type safety to begin with)
13:33:46 <ryoshu> are there alternatives?
13:33:59 <izabera> yes the libc functions
13:34:26 <izabera> there are some syscalls that are clearly unsafe to use from c code
13:34:27 <ryoshu> on the system call layer
13:34:39 <izabera> you just can't make them safe to use
13:34:50 <izabera> e.g. clone or vfork on linux
13:35:04 <izabera> well vfork arguably by clone definitely
13:35:09 <izabera> s/by/but
13:35:29 <ryoshu> is there something safer?
13:35:37 <ryoshu> with the indirect system call property
13:36:03 <izabera> you can't make the syscall function safe because some syscalls aren't safe to use directly
13:36:30 --- join: robwgla (~robwgla@62-47-195-35.adsl.highway.telekom.at) joined #osdev
13:36:30 <izabera> if you limit yourself to write/read/open/close... those are safe to use with syscall()
13:37:15 --- quit: robwgla (Client Quit)
13:37:46 --- quit: user10032 (Quit: Leaving)
13:43:31 --- quit: hppavilion[1] (Ping timeout: 260 seconds)
13:52:22 <ryoshu> ok
13:52:25 <ryoshu> are there alternatives?
13:52:42 <ryoshu> without ABI or Endian issues
13:55:38 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
13:56:56 --- quit: sixand (Ping timeout: 252 seconds)
13:56:57 --- nick: sixand1 -> sixand
13:58:53 --- quit: tylerdmace (Ping timeout: 245 seconds)
14:00:42 --- quit: daniele_athome (Ping timeout: 256 seconds)
14:01:43 --- join: tylerdmace (~tylerdmac@pool-98-116-102-65.nycmny.fios.verizon.net) joined #osdev
14:03:13 <doug16k> Ameisen, I read somewhere that intel is facing 32 lawsuits over meltdown
14:03:40 <doug16k> is/was
14:03:46 <izabera> why 32
14:04:04 <doug16k> yeah, funny that it is a power of two
14:05:03 <ryoshu> "was" - are they over?
14:05:21 <doug16k> I don't know how many, if any, are finished
14:05:31 <ryoshu> what is the result?
14:06:00 --- join: [X-Scale] (~ARM@83.223.227.20) joined #osdev
14:06:04 <doug16k> no idea. settlements are rarely public
14:06:15 <ryoshu> just who won
14:06:56 --- quit: X-Scale (Ping timeout: 256 seconds)
14:06:56 --- nick: [X-Scale] -> X-Scale
14:11:51 --- join: bauen1 (~bauen1@ANancy-655-1-89-94.w86-197.abo.wanadoo.fr) joined #osdev
14:12:42 --- quit: regreg_ (Ping timeout: 245 seconds)
14:17:10 --- quit: glauxosdever (Quit: leaving)
14:28:03 --- quit: lnnb (Quit: WeeChat 2.0.1)
14:28:28 --- quit: bauen1 (Ping timeout: 245 seconds)
14:30:45 <doug16k> wow, seriously? -> https://godbolt.org/g/D7FDG8
14:30:47 <bslsk05> ​godbolt.org: Compiler Explorer
14:31:20 --- join: lijero (~lijero@unaffiliated/lijero) joined #osdev
14:41:56 <izabera> is main a new option?
14:42:04 <izabera> never noticed it before but it's been a while
14:42:08 --- quit: pie_ (Ping timeout: 260 seconds)
14:42:25 --- quit: mavhq (Read error: Connection reset by peer)
14:43:40 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
14:47:22 <doug16k> crazy, why bother with ebx/ecx? -> https://godbolt.org/g/hs35Yn
14:47:24 <bslsk05> ​godbolt.org: Compiler Explorer
14:48:24 <doug16k> should be mov/mov/shrd/sar/ret
14:48:38 --- quit: oaken-source (Ping timeout: 252 seconds)
14:51:12 <doug16k> why push pop? -> https://godbolt.org/g/B2t5Yt
14:51:15 <bslsk05> ​godbolt.org: Compiler Explorer
14:51:21 <doug16k> that's some serious codegen suckage
14:52:49 --- quit: drakonis (Read error: Connection reset by peer)
14:53:46 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
14:54:06 --- quit: quc (Remote host closed the connection)
14:54:29 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
14:55:14 <JodaZ_> most of the suckage comes from 32bit
14:56:41 --- quit: Halofreak1990 (Ping timeout: 268 seconds)
14:56:47 --- quit: dennis95 (Quit: Leaving)
14:56:51 --- quit: rain1 (Quit: Leaving)
14:56:59 <JodaZ_> does anyone know if i can instruct the compiler to align a function?
14:57:41 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
14:59:09 --- quit: NaNkeen (Ping timeout: 268 seconds)
14:59:26 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
15:00:27 --- quit: FMan (Quit: Leaving)
15:01:56 --- quit: immibis (Ping timeout: 260 seconds)
15:03:44 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
15:06:01 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
15:06:02 --- quit: josuedhg (Remote host closed the connection)
15:06:57 <izabera> with the align attribute
15:06:59 <izabera> in gcc
15:07:44 <doug16k> JodaZ_, -falign-functions
15:07:54 <izabera> that's all the functions
15:08:02 <doug16k> yes
15:08:09 <doug16k> why would you align a specific one?
15:08:14 <izabera> because
15:08:17 <doug16k> ...
15:08:46 <izabera> so you can cast it to a double
15:11:25 <izabera> your imagination is the limit
15:12:28 --- quit: hppavilion[1] (Ping timeout: 252 seconds)
15:12:50 <doug16k> JodaZ_, https://godbolt.org/g/dwQUQb
15:12:51 <bslsk05> ​godbolt.org: Compiler Explorer
15:13:08 <doug16k> aligned to 32 byte boundary
15:13:34 <JodaZ_> what about msvc?
15:13:43 <doug16k> good luck
15:14:10 <JodaZ_> (for the record, putting it in its own, aligned section seems to work)
15:15:24 --- quit: Kimundi_ (Ping timeout: 252 seconds)
15:16:54 <doug16k> JodaZ_, it's just a coincidence that it aligns it then, but if that works for your scenario, go for it
15:16:55 --- quit: Asu` (Remote host closed the connection)
15:18:31 <doug16k> 16 byte aligning all functions is a big win on x86, it helps fetch bandwidth quite a bit
15:20:07 <JodaZ_> doug16k, seems well specified, you can set section alignment and pinning functions to a section is even recommended for code residency purposes by m$ for drivers
15:20:23 <izabera> i kinda feel that a tight loop that's been decoupled into separate functions could benefit from not having overalignment
15:20:49 <izabera> like, if they're really close together in the binary and fairly small
15:21:34 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:22:00 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-lnttwzuezaoghatf) joined #osdev
15:22:03 <doug16k> x86 fetches 16 (or 32 for latest architectures) bytes per cycle, at 16 byte aligned boundaries
15:22:22 <JodaZ_> izabera, shush now, you shouldn't think about such things or you'll come up with the next spectre-type vuln
15:22:32 <doug16k> you could get as little as 1 byte of code that cycle on older ones, or 17 bytes on latest architectures. as little as 1/16th or just over 50%
15:23:30 <JodaZ_> 17 bytes? sounds weird
15:23:46 <doug16k> as weird as one byte?
15:24:15 <JodaZ_> one byte just sounds old
15:24:23 <doug16k> the 32 byte window, with the first 15 bytes wasted
15:24:32 <doug16k> or the 16 byte window, with the first 15 bytes wasted
15:25:12 <doug16k> fetch is done in blocks. it doesn't nitpick
15:25:37 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
15:26:24 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
15:28:49 <doug16k> the icache delivers one 128 bit aligned, 128 bit block per cycle, or on newer ones one 128 bit aligned, 256 bit block, per cycle
15:29:55 <doug16k> if the entry to a function is not aligned, it can't use the full fetch width that cycle.
15:30:19 <doug16k> same issue with branches btw
15:30:30 <pounce> til my motherboard has a ps/2 mouse and keyboard and serial port
15:31:49 <doug16k> JodaZ_, msvc supports placing functions in specific sections so drivers can put some code in locked memory and some in pageable memory
15:32:26 <doug16k> that's the primary purpose. a secondary purpose is reduction of working set with PGO
15:34:27 <doug16k> and it is useful when a single driver supports many variations on the same device - you can place all of the code that won't be used in separate sections that will never get touched, and you can explicitly discard whole sections if you can determine at runtime that it will never get used
15:34:44 --- join: jmill (~textual@2605:6000:1019:3ff:9026:8dd0:6b0b:837a) joined #osdev
15:34:47 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
15:35:05 <JodaZ_> sounds like the driver should just load submodules instead
15:35:25 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
15:35:57 <doug16k> and cause a bunch more disk seeks? one file will be much faster
15:37:12 <geist> doug16k: wat! (the 64bit shift thing)
15:37:22 <doug16k> geist, I know right?
15:37:51 <geist> interesting that changing it to skylake causes it to do a more traditional integer shift
15:38:02 <geist> so it's purely in the tuning that it has decided the sse path is better
15:38:04 <doug16k> yeah and removing skylake ends up same code
15:38:17 <JodaZ_> seek? do devs even still care about seeks in the age of ssd's?
15:38:39 <geist> even better -march= instead of -mtunr results in it using a slightly shorter vex prefixed version
15:38:59 <geist> oh, this is -m32
15:39:10 <geist> didn't notice that part. now it makes a little more sense, this may actually be faster
15:39:19 <doug16k> did you see the nonsense push pop for the mregparm=3 version?
15:39:48 <geist> interesting: switching to gcc 8.1 switches to sar/shrd
15:39:59 <doug16k> https://godbolt.org/g/B2t5Yt
15:40:22 <doug16k> ^ wat?
15:40:56 --- quit: spare (Quit: leaving)
15:41:41 <geist> oh that's probably just the frame pointer
15:41:50 <geist> though you'd think it'd consider it to be a leaf function
15:41:52 <doug16k> ebx?
15:42:03 <geist> oh ebx. dunno
15:42:10 <geist> keep thinking of this as 64bit
15:43:56 <doug16k> JodaZ_, opening multiple files will be slower even on ssd
15:48:45 <pounce> my scheduler worked so well I thought it was broken for a sec
15:48:56 <doug16k> https://godbolt.org/g/2bHhZW <-- perfect
15:48:59 <bslsk05> ​godbolt.org: Compiler Explorer
15:51:54 <doug16k> https://godbolt.org/g/WKd4hL <-- 4.8.1 does the 32 bit one perfectly
15:51:55 <bslsk05> ​godbolt.org: Compiler Explorer
15:52:09 <doug16k> looks like they pessimized 32 bit codegen a bit lately
15:53:10 <JodaZ_> maybe they just don't care about 32bit x86 anymore since anyone on that is using obsolete stuff anyways - 32bit arm might be better?
15:53:48 <doug16k> I noticed that my kernel's LTO built is far more willing to use r8-r15. gcc used to avoid rex a bit too hard
15:53:57 --- quit: jmill (Ping timeout: 245 seconds)
15:54:12 <geist> clang in this case when yuo mean LTO?
15:54:20 <doug16k> no, gcc
15:54:34 --- quit: xenos1984 (Quit: Leaving.)
15:54:44 <geist> i guess maybe it uses the top regs more because on the average functions are inlined and larger?
15:54:49 <geist> and thus need more regs to avoid spillage?
15:54:53 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
15:55:07 <doug16k> it's O2 though, so it only inlines used-once stuff
15:55:22 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
15:57:31 <doug16k> ah I see. maybe I'm confusing issues. it might be just as willing without LTO
15:57:44 <doug16k> when I check optimized codegen I check LTO
15:58:47 <geist> yeah id'b e sur[prised unless it's just increased register pressure
15:59:06 <geist> but you're right, i dunno exactly how hard gcc tries to weight against using upper regs and REX
15:59:19 --- quit: NaNkeen (Ping timeout: 240 seconds)
15:59:25 <geist> or if it considers that if you're doing 64bit stuff and thus have to use the rex prefix anyway that the upper registers are free
15:59:39 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
16:01:40 <doug16k> yeah, that's what I constantly thought when looking at the code: it should be biased to put pointers to data that are always accessed as 64 bit in upper registers, and it should be biased to put 64 bit data in upper registers, because it has to use rex anyway
16:02:25 <doug16k> probably wouldn't make a big difference, but it wouldn't hurt
16:03:41 <geist> but it may turn out that it makes basically no difference and all else held equal optimizations that dont help aren't worth doing
16:08:23 <geist> that's why i like my trusty old first gen atom machine. it's basically the slowest x86-64 machine you can get
16:08:37 <geist> so if you have things like instructions being one byte longer making a difference, then it'll show up here
16:08:55 --- quit: Tazmain (Remote host closed the connection)
16:09:04 --- join: lutoma (~lutoma@wikipedia/lutoma) joined #osdev
16:09:05 <doug16k> is that one so old it is complete in-order?
16:09:16 <geist> yeah
16:09:21 <doug16k> nice
16:09:22 <geist> the bonnell arch i believe
16:09:40 <doug16k> basically an awesome 486
16:09:52 <geist> yeah, or pentium. it is dual issue i believe
16:09:57 <geist> jsut completely in order
16:09:59 <doug16k> ah yeah, pairing :P
16:11:04 <geist> agner's optimization manual says it's 8 bytes per cycle too
16:11:24 <geist> so there's a strong bias towards using 4 bytes or less instructions, so it can at least dual issue
16:11:52 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
16:12:17 --- join: josuedhg (~josuedhg_@192.55.54.42) joined #osdev
16:12:27 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
16:12:34 <geist> hah "A 64-bit integer division takes 207
16:12:36 <geist> clock cycles
16:12:42 <doug16k> :O
16:12:52 <geist> exactly. so it's a good test machine for slow
16:13:04 <geist> while being modernish, 64bit, hyperthreaded, and multi core
16:14:11 <chrisf> 64bit idiv is brutal even on the big cores
16:14:25 <geist> it's oddly paired too, apparently it has two full 128 bit ALUs for the vector units, though pretty hard to actually use them due to bottlenecks somewhere else
16:15:20 <chrisf> i dont have it open, but skylake something like 40-90 clocks
16:15:53 <geist> 42-95 yeah
16:16:22 <geist> interesting that it lists ryzen as 14-47
16:16:32 <geist> and 14-30 for 32bit
16:16:47 <chrisf> an odd place to spend a bunch of area
16:17:03 --- quit: Halofreak1990 (Ping timeout: 260 seconds)
16:17:27 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
16:17:57 <stephennnn> So I'm trying to interface my screen in 640x460x16
16:18:11 <geist> oh that's interesting, his instruction table lists skylake 64bit idiv as using 58 microops
16:18:44 <geist> and ryzen as 2. so i guess it's a fairly fundamental difference in the way they constructed it internally
16:18:49 <stephennnn> Would the pitch be 640, and the pixelwidth 1?
16:19:06 <stephennnn> Is 16 colour 1 byte per pixel, or would it be half a byte?
16:20:28 <doug16k> stephennnn, depends on how the video card is set up. VBE or VGA?
16:20:37 <stephennnn> VGA
16:21:08 <doug16k> in that mode you'd be using bitplanes. you can set the color of 8 pixels with one byte write
16:21:58 <stephennnn> I see
16:21:59 <doug16k> however, if you are preserving any of them, you'd have to read that byte to load the latches, and possibly do I/O to set a mask, then store a byte with a 1 bit for each pixel to set
16:22:19 <doug16k> it's been ages since I did bitplane VGA stuff. it's fading from my mind
16:22:43 <chrisf> happily faded
16:22:44 <doug16k> the behaviour of a write depends on the write mode
16:22:51 <doug16k> chrisf, yes, lol
16:23:13 <stephennnn> Would it make more sense to use something else?
16:23:34 <doug16k> stephennnn, use VBE linear framebuffer, save yourself some suffering and a bazillion I/O port accesses
16:24:36 <doug16k> then you could go to 256 or 65536 or 16.7M colors laid out as sensible 8/16/32 bit values per pixel
16:24:54 <stephennnn> Is that under VESA video modes?
16:24:58 <stephennnn> I'm very new to this
16:25:22 <doug16k> yes, lookup VESA Bios Extensions, aka "VBE"
16:25:55 <stephennnn> Excellent, thank you!
16:26:00 <doug16k> VESA = Video Electronics Standards Association
16:27:16 --- join: light2yellow (~l2y@217.30.64.102) joined #osdev
16:27:58 --- quit: Plazma (Read error: Connection reset by peer)
16:28:43 <stephennnn> Writing an OS is so much fun
16:28:58 <pounce> it is :D
16:29:42 <doug16k> osdev, where everything is your own fault, and you love that
16:32:09 <klange> nope, it's all the hardware designer's fault
16:32:40 --- quit: behalebabo (Max SendQ exceeded)
16:33:00 --- join: behalebabo (~behalebab@unaffiliated/behalebabo) joined #osdev
16:33:55 <geist> yeah computer engineers, you suck!
16:34:19 * geist retires to his ivory tower
16:39:37 <chrisf> geist: they probably have better bug rates than you do ;)
16:41:06 <doug16k> geist, yeah, it looks like ryzen just delivers 2 divide ops to the scheduler and continues decoding, and skylake delivers 36? I wonder how much sooner ryzen starts delivering the following instructions vs the skylake
16:41:27 <doug16k> unfortunately agner fog only tells the latency of invoking the same instruction back to back
16:42:38 --- quit: awang (Ping timeout: 245 seconds)
16:44:48 <geist> doug16k: yeah that seems to be the case for the bulldozer family too, so i guess it's a general different approach for divs
16:45:02 <geist> so then i wonder of the 57 ops on skylake how many of those are parallelizable
16:49:44 <stephennnn> doug16k: I've kind of implemented VBE but it isn't working
16:50:04 --- quit: CheckDavid (Quit: Connection closed for inactivity)
16:50:07 <stephennnn> mov bx, 0x4118; 1024x768x32bbp I believe
16:50:30 <stephennnn> My offset is unsigned where = x*4 + y*1024*4;
16:50:40 <stephennnn> Which may be wrong, not sure
16:51:01 <stephennnn> And I write my BGR values to screen[where], screen[where + 1], screen [where + 2]
16:54:32 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
16:58:53 <Mutabah> Did the modeset work (did the video mode change, i.e. did the emulator window resize)?
16:59:22 <Mutabah> Are you getting the framebuffer address from the information block?
17:01:05 <stephennnn> Mutabah: Yes to the first
17:01:21 <stephennnn> I haven't actually written the code to read from the BIOS, I just have a simple line to catch errors
17:02:26 <geist> is this on real hardware?
17:02:36 <stephennnn> No - qemu-system-i386
17:02:41 <geist> if so, give this a try: put in a wbinvl after it... oh never mind then
17:03:07 <geist> i seem to remebmer years ago seeing a machine that apparently mapped the framebuffer with full writeback mode and required a flush sometimes
17:03:38 <geist> generally you fix that with MTRR setupo, but it was during early os bringup and i hadn't yet set up the MTRR and/or most machines have that set up right coming uot of the bios
17:04:24 <geist> but none of that will matter on qemu
17:06:04 <Mutabah> stephennnn: Then what framebuffer address are you using?
17:06:10 <stephennnn> 0xA0000
17:06:19 <Mutabah> That's probably not correct
17:06:33 <geist> ah yes. when you go into a linear mode the framebuffer is generally mapped up 'high'
17:06:36 <geist> as in where PCI space is
17:06:49 <stephennnn> Oh no
17:07:09 <geist> or i suppose in the 15MB memory hole if it were a non PCI device that happened to support VBE
17:07:17 <Mutabah> With qemu, usually at 0xE000_0000, but you can get the actual address from the VBE information block
17:07:30 <geist> honestly have no idea what VLbus based video cards would have done, prior to PCI but post VBE coming into existance
17:07:32 <Mutabah> (That address might just be for the BGA card)
17:08:15 <geist> yah and built in gpus on the cpu probably are using stolen graphics memory
17:08:28 <stephennnn> Aha! So I have to do the thing where I talk to the BIOS
17:08:28 <geist> which typically ends up near the top of where dram would be if they didn't steal it
17:08:29 <stephennnn> I can do that
17:09:17 <stephennnn> Where should I define a struct?
17:09:23 <stephennnn> Top of my .c file?
17:10:35 <geist> sure, or a .h file
17:10:39 <geist> you just have to define it before you use it
17:13:06 <stephennnn> into .h it goes
17:15:12 <stephennnn> Input: ES:DI = Segment:Offset pointer of where to store the VESA Mode Information Structure shown below.
17:15:26 <stephennnn> Dumb question, how do I pass a pointer into inline asm like they specify above
17:15:37 --- quit: Shamar (Quit: Lost terminal)
17:17:17 --- quit: awang (Ping timeout: 245 seconds)
17:17:43 <geist> generally speaking by the tmie you're in C you're no longer making vesa calls. are you in protected mode?
17:17:53 <stephennnn> Yes
17:17:53 <geist> more specifically 32 or 64 bit protected mode?
17:17:57 <stephennnn> 32 bit
17:18:05 <geist> how are you intending to make vesa calls?
17:18:44 <stephennnn> I'm not fully sure what you mean, I just need vbe_info_structure
17:19:11 <geist> yes, but how did you make the previous vbe call? were you in real mode?
17:19:37 <stephennnn> Which previous VBE call? The one to set up the screen in VBE mode?
17:19:41 <stephennnn> Because I did that one in the bootloader
17:19:41 <geist> yes
17:19:50 <geist> via an int instruction?
17:20:04 <stephennnn> Yes
17:20:22 <geist> okay, so here's the problem. once you flip into protected mode, you cannot make those calls anymore
17:20:29 <geist> so you need to read all of that info in real mode
17:20:31 <stephennnn> Okay
17:20:40 <stephennnn> New problem, my bootloader is ful
17:20:41 <stephennnn> full
17:23:19 --- quit: Halofreak1990 (Ping timeout: 260 seconds)
17:24:55 <stephennnn> Let me see if I understand a mixed bootloader
17:25:06 <stephennnn> ; padding
17:25:06 <stephennnn> times 510 - ($-$$) db 0
17:25:06 <stephennnn> dw 0xaa55
17:25:15 <stephennnn> Do I just stick some more code after this?
17:25:20 <stephennnn> And then call it from the code beforehand
17:25:33 <stephennnn> So the bootloader can use more than one sector
17:26:03 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
17:28:27 <stephennnn> okay it did not like that
17:28:54 <geist> no. because the BIOS will only load the first sector
17:29:11 <geist> to spill your bootloader over into subsequent sectors you need to add code to read in the additional sectors before you use them
17:29:28 <geist> it's not hard though, i had to do precisely the same thing years ago
17:30:29 <stephennnn> My kernel code loads 31 sectors into memory
17:30:44 <stephennnn> Any reason why I can't run that first?
17:31:26 <geist> nope
17:31:44 <geist> or at least based on what i know of what you're doing, which is practically nothing, i see no reason why you cant
17:31:45 --- quit: lachlan_s (Quit: Connection closed for inactivity)
17:31:51 <geist> but then all the details matter, of which i have very few
17:32:31 <stephennnn> Hm, so now it gets stuck in a reboot loop
17:33:51 <Mutabah> Aaah, the good old hand-rolled beginner bootloader :)
17:34:48 <geist> yeah, it's been a while since i saw anyone come through doing that
17:35:30 <stephennnn> );
17:35:40 <stephennnn> I'm making progress
17:37:08 --- join: hppavilion[1] (~dosgmowdo@160-7-174-206.gci.net) joined #osdev
17:37:32 <stephennnn> So since I'm reading sector 2, is it safe to write that w/ a 0x200 offset?
17:37:36 <klange> bootloaders are worth skipping and revisiting in the future when you've been hacking on userland code for six years and you're bored with your life
17:37:46 <stephennnn> Since that's exactly 512 bytes
17:41:07 <Mutabah> what klange said :)
17:41:21 <Mutabah> Speaking of that, I'm tempted to go write a BIOS bootloader now :)
17:41:26 <Mutabah> I have a UEFI one
17:42:14 --- join: empy- (~l@174-21-151-5.tukw.qwest.net) joined #osdev
17:42:38 <klange> It was kinda refreshing coming in from the top and writing my CD loader.
17:42:53 --- join: hppavilion[0] (~dosgmowdo@160-7-174-206.gci.net) joined #osdev
17:43:08 <klange> I really need to burn this to a CD and see if it actually works on real hardware, I'm worried no actual BIOS will accept my giant El Torito boot payload.
17:43:23 <klange> 20 sectors!
17:45:43 --- quit: hppavilion[1] (Ping timeout: 248 seconds)
17:46:12 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
17:46:13 --- quit: empy (Ping timeout: 265 seconds)
17:46:41 <klange> what my bootloader needs is an lzma or DEFLATE implementation
17:49:02 <stephennnn> what *my* bootloader needs is to work
17:49:20 <klange> one thing at a time, man, let's start with compression, then we'll work on actually functioning :)
17:50:48 --- join: lain0n (~lain0n@24-159-4-77.dhcp.smrt.tn.charter.com) joined #osdev
17:55:55 --- quit: Halofreak1990 (Ping timeout: 264 seconds)
17:57:37 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
18:02:17 --- quit: `Guest00000 (Ping timeout: 245 seconds)
18:07:08 <stephennnn> grr this is not a fun time
18:07:43 <klange> Any time spent in real mode is not a fun time.
18:11:16 --- join: Plazma (~Plazma@freenode/staff-emeritus/plazma) joined #osdev
18:13:14 <stephennnn> Is it possible to do a memory dump in qemu?
18:16:31 <klange> all of it? dunno
18:16:45 <klange> you can use the `x` command to read addresses in the monitor
18:17:22 <klange> xp for physical, x for virtual if you've enabled paging
18:17:34 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
18:17:52 <klange> ah
18:18:02 <klange> stephennnn: `memsave <address> <size> <filename>`
18:18:22 <geist> also a fun trick you can do is tell it to use an existing file as the backing store
18:18:42 <stephennnn> so where do I use the memsave command?
18:18:45 <stephennnn> gdb?
18:18:50 <stephennnn> Or something else?
18:18:51 <klange> monitor
18:18:54 <geist> i forget the syntax, but it's handy if you also want to prepopulate ram with soemthing other than 0s
18:19:04 <stephennnn> Monitor?
18:19:06 --- quit: empy- (Quit: .)
18:19:06 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
18:19:09 <klange> ctrl-alt-2 in the SDL interface, available from the menus in the GTK interface
18:19:20 --- join: empy (~l@174-21-151-5.tukw.qwest.net) joined #osdev
18:19:21 --- quit: empy (Changing host)
18:19:21 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
18:19:31 <stephennnn> woo, thanks
18:19:31 <geist> -mem-path is i think what i'm thinking of
18:20:03 --- quit: dengke (Quit: Leaving)
18:20:52 --- nick: Halofreak1990_ -> Halofreak1990
18:21:04 <stephennnn> How peculiar
18:21:12 <stephennnn> My second sector isn't being loaded to memory
18:21:39 <exezin> bit of a dumb question, how do I tell my code (C at this point) what address its at
18:22:09 <exezin> I'm setting up a higher-half kernel in C
18:22:14 <latentprion> You mean you want the address of the current instruction?
18:22:26 <exezin> no, I want to force it to compile as if its ad X address
18:22:39 <exezin> so when I compile my kernel it thinks its at some higher-half memory address
18:22:42 <latentprion> In the bare bones tutorial, there's a linker script
18:22:53 <exezin> right, but that effects everything else as well from what I've seen?
18:22:53 <latentprion> In that linker script at the top there's a line that looks something like this
18:23:00 <exezin> currently I'm identity mapped to the first 2MB
18:23:01 <latentprion> . = 0xC0000000;
18:23:08 <latentprion> That line is how you do it
18:23:09 <exezin> yeah that would bork everything else
18:23:14 --- join: dengke (~dengke@60.247.85.82) joined #osdev
18:23:28 <exezin> that line is currently . = 1M;
18:24:05 --- quit: hppavilion[0] (Remote host closed the connection)
18:25:15 <exezin> latentprion: is that literally the only way to do it?
18:25:30 <latentprion> You can also set the addresses of specific sections
18:25:56 <exezin> so I'll need to do . = 0xC0100000;
18:26:00 <exezin> and then offset for that in my boot code
18:26:02 <latentprion> Or, more specifically you can advance the "." address later on in the script
18:26:07 <latentprion> You can only set it once
18:26:16 <latentprion> But you can increment it later on'
18:26:27 <latentprion> . += 0xC0000000;
18:27:02 <exezin> and thats the only option?
18:27:22 <latentprion> I don;t know if it's the only option, but it's the one I use
18:28:01 <doug16k> exezin, you can specify the virtual address and physical address in the linker script, they are independent, but advance together
18:28:20 <exezin> right but I want to specify it for a specific chunk of code, basically
18:28:24 <exezin> everything after my kernel_early.c
18:28:37 <exezin> because up until that, I'm in the identity-mapped 2MB
18:29:57 * exezin is confused
18:30:06 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
18:30:14 --- quit: lain0n (Quit: Leaving)
18:30:53 <doug16k> exezin, example: .text 0xC0000000 : AT(0x100000) {
18:31:08 <exezin> but then wouldnt that also do the same to all of my compiled C code?
18:31:17 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
18:31:23 <doug16k> that will make the linker produce program headers that load it at physical address 0x100000 and the code will be linked as if its addresses start at 0xC0000000
18:31:59 <exezin> yeah but like I said, I need it to not effect the early code
18:32:08 <doug16k> the startup code can be made position independent enough that it doesn't care where it is
18:32:26 <exezin> but then all of my code I've spent a day writing has been pointless?
18:32:32 <exezin> like, why identity map pages at all
18:33:34 <doug16k> you can have a startup code section that is identity mapped, then in that code, setup the proper high-half stuff, then enable paging and call into the high half code
18:34:05 <exezin> see you've lost me again
18:34:19 <exezin> because how do you have the startup section identity mapped, while the high-half kernel is in the higher half?
18:34:35 <exezin> setting that as the address in the linker script will also make the startup section be at that address no?
18:35:03 <doug16k> you can have a section for startup code that is not high half. put its virtual and physical address equal... then another section of the actual (non-startup) kernel code. in the identity mapped startup code section, setup paging for high half, then enable paging and call high half code (and abandon startup code)
18:35:24 <exezin> I think you're missing my point
18:35:40 <exezin> if I compile my higher-half kernel code right now, it will compile as if its at the low 1MB address with my startup code
18:35:43 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-ybivyqrhrsakgdyi) joined #osdev
18:35:45 <doug16k> I just said how to. different output sections
18:35:54 <lachlan_s> `error: aborting due to 6 previous errors`
18:35:58 <exezin> you just said .text?
18:36:16 <exezin> .text also covers the startup code though
18:36:16 <lachlan_s> Yes, rustc, I am doing very not-rusty things, just let me, goddammit
18:36:20 --- quit: tacco| ()
18:36:33 <doug16k> exezin, yes but you can control it
18:37:04 <exezin> doug16k: with the section __attribute__?
18:37:28 <doug16k> you can have a .startup section that is identity mapped (virtual==physical) and another section called .text that is at virtual=0xC0000000 AT(0x100000+SIZEOF(.startup))
18:37:59 <exezin> would my . = 1M; still be the same?
18:38:01 <doug16k> with attributes, or .section assembly directive
18:39:28 <doug16k> you don't need the dot thing if you specify the addresses in the output section
18:40:03 <exezin> hella confused lol
18:40:04 <doug16k> .text A : AT(B) puts it at physical address B, virtual address A
18:40:29 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
18:40:44 <doug16k> it's like you're saying "this car sucks if you don't control the steering wheel, it goes off into the weeds"
18:40:44 <stephennnn> Okay, my stupid bootloader won't work
18:40:46 <stephennnn> https://paste.scd31.com/view/2f9f60a7
18:40:47 <bslsk05> ​paste.scd31.com: Untitled - SCD Paste
18:40:56 <stephennnn> It prints "Loading kernel into memory"
18:40:58 <exezin> I never said that
18:41:00 <stephennnn> But then it should print wow
18:41:00 <exezin> I just said I was confused
18:41:02 <stephennnn> And it never does
18:42:01 <doug16k> exezin, is your linker script on github or something?
18:42:18 <exezin> https://hastebin.com/raw/gigayorate
18:43:07 --- quit: empy (Ping timeout: 260 seconds)
18:45:39 <stephennnn> this makes no sense
18:45:59 <stephennnn> when I remove "call KERNEL_OFFSET" the memory at kernel_offset is fine and has the second half of my bootloader
18:46:10 <stephennnn> but when I put that line back in and do a memory dump, kernel_offset is blank
18:48:20 <doug16k> exezin, https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/kernel.ld#L17
18:48:22 <bslsk05> ​github.com: dgos/kernel.ld at master · doug65536/dgos · GitHub
18:48:34 <doug16k> in my case, it's easier, my bootloader sets up paging
18:48:45 <exezin> mine doesnt :s
18:48:58 <exezin> I use grub, and set up paging/switch to long mode
18:48:59 <doug16k> in your case, you'd have another .startup section, and it would have .startup 0x100000 : AT(0x100000) {
18:49:13 <geist> ME KILLS THE WHITE WHALE
18:49:19 <exezin> doug16k: what about my bss section?
18:49:43 <doug16k> exezin, how many source files are involved with startup?
18:49:45 <exezin> and rodata, etc
18:49:50 <exezin> 3
18:50:03 <exezin> the multiboot header, boot, and then the long mode file
18:50:05 <doug16k> you can pull the code/data from those files into .startup
18:50:21 <doug16k> you know how linker scripts say things like *(.text) ?
18:50:23 <exezin> hm
18:50:27 <exezin> y
18:50:43 <doug16k> that * means any object file... you can put an object file filename there instead of * and it will pull in stuff from that file
18:50:45 <exezin> but I've also got my C code
18:50:52 <exezin> oh ok
18:51:43 --- quit: zeus1 (Ping timeout: 264 seconds)
18:51:57 <exezin> doug16k: like *(somefile.o)?
18:52:10 <doug16k> so you could just whack everything from startup.c into .startup like this: .startup 0x100000 : AT(0x100000) { startup.o(*); . = align(4096); }
18:53:02 <doug16k> or more carefully, with .startup 0x100000 : AT(0x100000) { startup.o(.text); startup.o(.data); startup.o(.bss); . = ALIGN(4096); }
18:53:32 <doug16k> then .text 0xC0000000 : AT(0x100000 + SIZEOF(.startup)) { ... }
18:53:39 <exezin> if I set a section to 1M, is every section after that, after 1M?
18:54:37 <doug16k> yes if you omit those addresses it continues from where it left off
18:54:55 <doug16k> so .data : { ... } will put .data after .text
18:55:05 <exezin> I sort of get it
18:55:06 <doug16k> though you'd probably want .data ALIGN(4096) : { ....
18:55:10 <exezin> but I dont really get how to deal with rodata and bss
18:55:26 <exezin> I have 3 asm files that I want at 1M, and then a C file that I want (now) at the higher half
18:56:52 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
18:59:54 --- join: Arcaelyx (~Arcaelyx@cpe-184-152-29-2.nyc.res.rr.com) joined #osdev
19:01:51 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
19:02:26 <doug16k> exezin, ok, but what you probably really want is those startup code files in the identity mapped .startup section, and everything else in the high half .text/.data/etc
19:02:39 <exezin> alright
19:02:51 <exezin> im trying to add all of the .o files to the boot section of the linker script that sets it to 1M
19:02:57 <exezin> syntax error so far lol
19:03:10 <doug16k> paste?
19:03:35 <exezin> https://hastebin.com/raw/jeyeboveya
19:04:06 <doug16k> use 0x100000 instead of 1M
19:04:17 <doug16k> idk if AT is required to be uppercase
19:04:46 <exezin> it is
19:04:48 <exezin> im an idiot
19:05:13 <exezin> it cant actually find the files, ffffff
19:06:02 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
19:06:52 <exezin> I shouldnt need to give it the actual path to the files should I?
19:06:55 <exezin> ld gets that already
19:07:22 <doug16k> I don't know if you need to use paths, haven't tried it before
19:07:36 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
19:07:57 <exezin> *file.o(*); seems to work?
19:07:59 <exezin> I wonder why
19:08:15 <doug16k> ah maybe that is pattern matching the path
19:08:26 --- quit: light2yellow (Quit: light2yellow)
19:08:36 <doug16k> try it with a path and no leading *. does that work? I'm curious
19:08:48 <doug16k> use /
19:09:01 <exezin> it does
19:09:05 <exezin> oh
19:09:11 <exezin> only with dir/
19:09:13 <exezin> not /dir/
19:09:18 <doug16k> of course
19:09:24 <doug16k> /dir means the root
19:09:26 <exezin> yeah
19:09:38 <doug16k> I meant don't use \ :D
19:09:38 <exezin> I thought maybe relative to where ld is called from :p
19:09:42 <exezin> lol sure sure
19:09:44 <exezin> so yeah, that works
19:09:55 <exezin> super weird considering ld is already given the path
19:10:28 <exezin> doug16k: so after boot, I want it to be at 0xC0000000 virtual but stay where it is in the physical
19:10:30 <exezin> would I do
19:10:33 <exezin> .text 0xC0000000 :
19:10:43 --- nick: Halofreak1990_ -> Halofreak1990
19:10:44 <exezin> and the physical addr will just continue after the .boot section?
19:10:55 <doug16k> yes, but you'd need to AT that too - else it will send the physical address into the weeds
19:11:07 <exezin> uuh
19:11:23 <doug16k> if you advance the virtual address it will also advance the physical address that much
19:11:30 <exezin> .text 0xC0000000 : AT (0x100000 + SIZEOF(.boot))
19:11:37 <doug16k> yes
19:11:40 <doug16k> that should work
19:12:08 <exezin> I think it does
19:12:14 <exezin> need to setup higher-half paging to actually find out lol
19:12:26 <doug16k> not necessarily
19:13:22 <doug16k> objdump -p yourexecutable
19:14:19 <exezin> https://hastebin.com/raw/nadusocula
19:14:28 <doug16k> you should see a program header with vaddr 0x100000 and paddr 0x100000 then another at 0xc0000000 ...
19:14:28 <exezin> I think thats correct
19:14:46 <doug16k> looks good
19:14:51 --- join: SwiftMatt (~Objective@2601:282:4300:3e:b992:c91f:963:e1a3) joined #osdev
19:14:57 <exezin> whats going on with the funky align numbers?
19:15:08 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
19:15:38 <doug16k> now you need your paging code to know the physical address of the beginning high half. you can add symbols to .boot and in your code subtract end from start
19:16:16 <exezin> uh
19:16:22 <doug16k> so inside .boot's braces, add __boot_st = .; at the top, and add __boot_en = .; right after the . = ALIGN...
19:16:30 <doug16k> oh
19:16:40 <doug16k> add another . = ALIGN(4096) at the end of .boot
19:16:53 <exezin> yeah I did :D
19:17:25 <doug16k> then in your paging init, you can look at __boot_en - __boot_st to get the size of boot, and adjust the physical address of 0xC0000000 and onward
19:17:30 <exezin> so I can reference those symbols in the assembly?
19:17:34 <doug16k> yes
19:17:41 <exezin> dope, thanks
19:17:49 --- quit: Kazinsal (Read error: Connection reset by peer)
19:18:08 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
19:18:37 <exezin> my linker script skills have always been lacking, I should really put time into improving them
19:19:11 <doug16k> you can infer that the physical address of 0xC0000000 is at 0x100000 + (__boot_en - __boot_st)
19:19:20 <doug16k> then just work upward from there in your loop
19:19:22 --- join: empy (~l@174-21-95-161.tukw.qwest.net) joined #osdev
19:19:22 --- quit: empy (Changing host)
19:19:22 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
19:19:58 <exezin> added that as a comment to the script so I dont forget it :p
19:20:25 --- join: Kazinsal (~Kazinsal@unaffiliated/kazinsal) joined #osdev
19:20:27 <exezin> so now I'll need to setup paging for the higher half and jump to it
19:20:30 <doug16k> if you get errors, you'll probably need to load __boot_en into a register then sub __boot_st from that register
19:20:41 <exezin> ah ok
19:21:02 <exezin> doug16k: I can figure out how much I need to map with pages by using more symbols like that cant I?
19:21:09 <doug16k> in gnu assembly it'd be $__boot_en, etc
19:21:18 <doug16k> yes
19:21:27 <doug16k> you can make lots of symbols at different places that way
19:21:31 <exezin> awesome
19:21:44 <exezin> its so convenient :p
19:21:58 <doug16k> ya, that's what makes linker scripts so good
19:22:13 <doug16k> besides having god-like control over addresses :D
19:22:37 <exezin> calculate space needed for kernel via symbols -> map pages -> jump to it -> done \o/
19:24:31 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
19:31:49 <exezin> doug16k: I think the syntax for addressing symbols in nasm is a little different
19:31:58 <exezin> $__boot_en is undefined
19:32:09 <doug16k> try $(__boot_en)
19:32:18 <exezin> nope
19:32:24 <doug16k> or just lea __boot_en
19:32:28 <exezin> nope :p
19:32:50 <doug16k> which assembler? gnu or nasm?
19:32:53 <exezin> nasm
19:33:06 <doug16k> then just say __boot_en
19:33:36 <exezin> nasm
19:33:38 <exezin> nope*
19:33:48 <exezin> it's telling me its an undefined symbol
19:33:59 <doug16k> might need EXTERN
19:34:21 <doug16k> I haven't used nasm for decades
19:34:23 <exezin> yep, I'm a double idiot
19:34:29 <exezin> makes sense that it would
19:38:53 --- quit: JusticeEX (Ping timeout: 245 seconds)
19:46:51 <jjuran> Don't worry, on x86 you have to be a triple idiot before it kills you. :-)
19:55:34 <xiphias> hi
19:58:55 --- quit: empy (Ping timeout: 264 seconds)
19:58:56 <drakonis> https://blog.erratasec.com/2018/05/c-is-too-low-level.html
19:58:57 <bslsk05> ​blog.erratasec.com: Errata Security: C is to low level
19:59:23 <drakonis> hmm, how do they say in video games drama circles?
19:59:27 <drakonis> hmmm... shots fired?
20:06:10 --- quit: regreg_ (Ping timeout: 252 seconds)
20:08:39 --- join: phax (~phax@unaffiliated/phax) joined #osdev
20:10:10 <klys> would help i they could spell too
20:10:13 --- quit: rafaeldelucena (Remote host closed the connection)
20:10:22 <klys> would help if they could spell too
20:11:04 --- quit: sixand (Quit: sixand)
20:12:54 <exezin> anyone know how to make a linker script symbol indicate physical address and not virtual?
20:13:06 <exezin> if I add __kern_en = .; to the end of my script, its setting to to the virtual address and not the physical
20:13:22 <Mutabah> Just subtract the known offset?
20:13:57 <exezin> that would give me 0x2000 which is very wrong
20:14:19 <exezin> hm
20:15:14 <exezin> got it
20:15:21 <exezin> __kern_en = (. - 0xC0000000 + 0x100000 + SIZEOF(.boot));
20:15:27 <exezin> Didn't even think of that :p
20:17:00 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
20:19:26 --- join: empy (~l@174-21-159-234.tukw.qwest.net) joined #osdev
20:19:26 --- quit: empy (Changing host)
20:19:26 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
20:21:46 --- quit: empy (Client Quit)
20:23:11 --- join: empy (~l@174-21-159-234.tukw.qwest.net) joined #osdev
20:23:11 --- quit: empy (Changing host)
20:23:11 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
20:24:19 <doug16k> exezin, that won't give the size of the kernel. that will give kernel base plus size of boot
20:24:29 <doug16k> plus 1MB
20:25:10 <exezin> doug16k: thats not for size
20:25:17 <exezin> I wanted __kern_en to point to the end address of the kernel
20:25:20 <doug16k> ah
20:25:25 <exezin> (in phyical space :p)
20:25:29 <exezin> I'm calculating in asm
20:26:34 <doug16k> oh, I realized that __boot_en is the physical address of the base of the kernel (assuming you haven't changed it too much).
20:26:51 <exezin> lol yeah it would be
20:26:51 <doug16k> you could take that plus __kern_en - __kern_st if you later find you want that too
20:27:11 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
20:27:31 <doug16k> you're going to need the very end of the kernel to initialize your memory manager anyway
20:27:42 <exezin> the end?
20:27:57 <doug16k> yeah, the address of the very end of the last section
20:28:02 <doug16k> 0xC00?????
20:28:07 <exezin> oh
20:28:35 --- quit: Halofreak1990 (Ping timeout: 260 seconds)
20:28:36 --- nick: Halofreak1990_ -> Halofreak1990
20:30:20 <doug16k> didn't you say this was a 64 bit kernel?
20:31:23 <doug16k> if so, a "high half" kernel should be based at 0xFFFFFFFF80000000
20:31:46 <exezin> oh
20:31:48 <exezin> really?
20:31:50 <exezin> fuk
20:31:52 <doug16k> and compiled with -mcmodel=kernel
20:32:08 <doug16k> you can keep going with what you have for now though
20:32:14 <exezin> well I changed it to that ^
20:32:15 <doug16k> it is not a big difference to change it
20:32:19 <exezin> it was only a 2-line change
20:32:19 --- quit: SwiftMatt (Ping timeout: 260 seconds)
20:32:52 <exezin> trying to get my head around setting up page tables for it now
20:32:59 <doug16k> that number is -2GB
20:33:42 <doug16k> x86_64 addressing modes sign extend the offset, and offsets are 32 bit, so it can efficiently represent a kernel offset with a 32 bit sign extended offset in mcmodel=kernel
20:34:13 <doug16k> a 32 bit 0x80000000 offset sign extends to 0xFFFFFFFF80000000
20:34:17 <exezin> its just occured to me that I have no real idea how to setup page tables if they're not identity mapped lol
20:34:58 <doug16k> yeah, it's a bit of chicken-and-egg problem at first. "how do I access the page tables if I have to update the page tables to update the page tables" :D
20:35:11 <exezin> well I know how many 2MiB page tables I need
20:35:19 <exezin> I've honestly just forgotten how they work
20:35:26 <exezin> like, what part defines the virtual address
20:35:28 <exezin> .-.
20:35:51 <doug16k> 64 bit page tables split the address into 4 9-bit parts, plus the low 12 bits
20:35:56 <exezin> yeah
20:36:02 <exezin> I mean logically, in the tables themselves
20:36:09 <exezin> not sure how I'll calculate what page tables I need to allocate
20:36:38 <exezin> I've got the physical addresses calculated just fine
20:36:53 <doug16k> are you planning to use 2MB page tables to map the kernel?
20:36:59 <exezin> yeah
20:37:10 <geist> well sounds like you need to go back and read any number of tutorials and guides intended to teach you this stuff
20:37:17 <doug16k> then you have to align the physical address of the beginning of the kernel to a 2MB boundary
20:37:28 <exezin> oh good point
20:42:28 --- quit: awang (Ping timeout: 252 seconds)
20:42:28 <exezin> alright I got it
20:42:49 <exezin> figure out what p3 the virtual addr resides in, map that to a p2, and then map out the 2MiB tables in p2
20:43:08 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
20:44:31 <geist> the key is figuring out what index into what level of the table each range of an address corresponds to
20:44:36 <geist> after a while it'll be second nature
20:45:11 <geist> it's not complicated at all, because it has to be implemented in hardware very quickly
20:45:12 --- quit: freakazoid0223_ (Ping timeout: 245 seconds)
20:45:36 <exezin> right, just a bit shift really
20:46:01 <exezin> not having to go down to p1 makes it a bit easier
20:48:28 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
20:51:45 --- quit: lachlan_s (Quit: Connection closed for inactivity)
20:52:26 --- quit: phax (Quit: phax)
20:52:47 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
20:53:46 --- nick: Halofreak1990_ -> Halofreak1990
20:58:31 --- quit: nj0rd (Ping timeout: 260 seconds)
21:01:17 --- quit: Halofreak1990 (Ping timeout: 256 seconds)
21:03:18 <variable> https://pbs.twimg.com/media/Dd7uB8QU8AEcIBl.jpg:large
21:03:44 <doug16k> lol
21:04:41 --- quit: drakonis (Read error: Connection reset by peer)
21:08:16 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
21:12:54 --- join: nj0rd (~nj0rd@i577BC0FB.versanet.de) joined #osdev
21:13:16 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
21:13:47 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
21:15:01 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
21:16:58 --- join: oaken-source (~oaken-sou@p5DDB53DF.dip0.t-ipconnect.de) joined #osdev
21:18:57 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
21:19:27 --- quit: awang (Ping timeout: 260 seconds)
21:20:00 --- quit: lijero (Remote host closed the connection)
21:20:03 <klange> so cute when virtualbox starts like this https://i.imgur.com/nPJIosA.png
21:22:12 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
21:26:50 --- quit: bcos (Ping timeout: 252 seconds)
21:27:15 * latentprion gets a cute little fun idea
21:29:47 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
21:31:13 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
21:33:03 --- quit: Salek (Ping timeout: 245 seconds)
21:36:43 --- quit: Halofreak1990 (Ping timeout: 264 seconds)
21:37:17 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
21:50:12 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
21:54:14 --- quit: pounce (Quit: WeeChat 2.1)
22:04:47 --- quit: mrush_ (Changing host)
22:04:47 --- join: mrush_ (~user@unaffiliated/mrush) joined #osdev
22:04:56 --- nick: mrush_ -> mrush
22:20:24 --- quit: freakazoid0223 (Quit: If you can't laugh at yourself, make fun of other people.)
22:30:37 --- quit: Humble (Ping timeout: 245 seconds)
22:35:12 --- quit: josuedhg (Ping timeout: 245 seconds)
22:40:54 <variable> dumb Q: what's the difference between PTE Coalescing and "superpages" ?
22:41:20 <variable> the former is a newish AMD term
22:41:26 <variable> the latter is an intel term?
22:42:46 --- join: Humble (~hchiramm@2405:204:d207:1d9f:2e83:78a:8e70:4f8) joined #osdev
22:42:59 <variable> https://twitter.com/you_wouldnt_bot/status/999518727816261632 - um, I would
22:42:59 <bslsk05> ​twitter: <you_wouldnt_bot> You wouldn't interrupt an open
22:48:13 <geist> variable: what's the context?
22:48:27 <variable> "The two new instructions are CLZERO and PTE Coalescing."
22:48:45 <geist> ah yes. yeah that's some AMD thing. unclear how well the PTE coalescing works
22:49:01 <geist> _mjg_ had something to say about clzero. doesn't necessarily seem to be an overall good idea
22:49:01 <variable> PTE (Page Table Entry) Coalescing is the ability to combine small 4K page tables into 32K page tables,
22:49:05 <geist> yep
22:49:18 <variable> geist: yeah, we were chatting about that in #otherchan
22:49:21 <geist> what's unclera bout it is exactly when it kicks in, how you can tell it's working, etc
22:49:45 <variable> geist I'm unsure if AMD PTE == Intel PSE
22:49:58 <geist> dunno about intel superpages. i haven't heard of that
22:50:01 <variable> wait, not PSE
22:50:10 <variable> that's the old thing
22:50:19 <geist> yah that's page size extensions
22:50:26 <variable> I'm thinking of "huge pages
22:50:28 <geist> i thin kthat's just 4MB pages, etc
22:50:30 <variable> I hate naming
22:51:12 <_mjg_> it was not me per se
22:51:18 <_mjg_> i was repeating after dillon@dfly
22:51:23 --- quit: Halofreak1990 (Ping timeout: 260 seconds)
22:51:24 <geist> kk
22:51:27 <variable> geist: so, ignoring that can't remember the name of ting
22:51:32 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
22:51:38 <variable> I'm wondering if its just that AMD now supports large pages
22:51:41 <variable> or if its something else
22:51:45 <_mjg_> tl;dr clzero does non-temporal stores and when used for something like page zeroing it ran into severe memory bandwidth issues
22:51:52 <_mjg_> during concurrent pf test
22:51:58 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
22:52:04 <_mjg_> another note is that linux does not use the sintruction for page zeroing either
22:52:05 <geist> i suppose if you only clzeroed stuff on the local node...
22:52:09 * variable was trying to avoid the clzero discussion here...
22:52:12 <variable> bleh
22:52:38 * geist is watching A Bridge Too Far
22:52:43 <geist> so now i know where the phrase is from
22:53:26 <latentprion> https://www.dropbox.com/s/gte1jjvj2iy50gf/20180524_150636.jpg?dl=0
22:53:28 <bslsk05> ​www.dropbox.com: Dropbox - 20180524_150636.jpg
22:53:45 <geist> ponies
22:53:47 * latentprion put the ponyos livecd image on a flash drive
22:53:49 <variable> latentprion: I like your nick
22:53:49 <klange> why have you done this
22:53:54 <latentprion> and put it in the middle of my workplace
22:54:08 <klange> you should see if you can coax the bios into give you native resolution
22:54:08 <variable> latentprion: PonyOS is nice
22:54:08 <latentprion> Should be fun, little bit of team good times
22:54:09 <variable> do it more
22:54:23 <latentprion> Yea, I'll do that, make it look nicer
22:54:32 <klange> though for the best experience I would say run it in a full screen VM with the right hardware for the network and audio to work
22:54:41 <klange> then you can install vim and Quake and pretend to do actual work on it
22:54:43 <latentprion> Which emultator?
22:55:10 <klange> VirtualBox will work on defaults, qemu will want `-soundhw ac97` to get the audio working
22:55:29 <klange> qemu you'll need to manually mode set, VirtualBox will do its automatic thing
22:55:29 <_mjg_> geist: well it was an issue for the local node :>
22:55:34 <_mjg_> with multiple threads zeroing
22:55:36 <latentprion> Right-o :O
22:55:51 <geist> yeah cross nodes it'd saturate the inter node traffic
22:56:30 <geist> it's kinda similar to the fs having these nice queues and buffers and caches and then having someone come along and do a O_SYNC read from the disk
22:56:45 <geist> NEED DATAS NAOW
22:57:26 <geist> anyway, here's my theory: ryzen core was originally designed for the K12 arm, and arm has a clzero
22:57:54 <geist> similarly ARM v8.1 has a new set of atomics that look basically the same as x86..... as if AMD pressured ARM to add them so that they could implement it easier
22:58:13 <geist> similarly ARM has combined pages, just like what ryzen does, as per what variable was talkinga bout
22:58:26 <geist> aaaaaand arm cores are typically clusters of 4.... just like what a ryzen zeppelin looks like
22:58:47 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
22:59:11 <geist> so my guess is they pivoted fairly late back to x86 and largely swapped the front end out of the K12 back to x86 and ryzen was born
23:00:35 <variable> lol
23:08:18 --- join: sympt (~sympt@209.58.137.94) joined #osdev
23:09:18 --- join: sympt_ (~sympt@209.58.137.94) joined #osdev
23:12:48 --- quit: sympt (Ping timeout: 252 seconds)
23:15:37 --- quit: oaken-source (Ping timeout: 245 seconds)
23:19:42 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
23:27:47 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-phxrakknfusspdea) joined #osdev
23:27:49 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
23:29:47 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
23:29:49 --- nick: Halofreak1990_ -> Halofreak1990
23:30:34 <_mjg_> geist: do you have a p4 box?
23:33:13 <_mjg_> I'm looking for a volunteer to do benchmark spelunking
23:33:42 <_mjg_> take a pentium 4 box and perform multiple kernel build tests with and without non-temporal stores for page zeroing
23:33:56 <_mjg_> i can provide relevant patches, "just" need someone to do the work
23:34:26 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
23:34:49 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
23:39:04 --- join: bcos (~bcos@58.170.204.44) joined #osdev
23:45:14 <geist> _mjg_: 32 or 64bit?
23:45:44 <geist> ie, i have a 32bit P4. an early one, first genwith HT
23:47:22 <klange> I forgot they made 64-bit P4s...
23:47:47 <geist> yeah, last versions. first intel 64bit i believe
23:48:02 <geist> dunno if those made it to consumer bits or they were the servers versions, or vice versa
23:49:16 <geist> yeah looks like it trickled out in the last batches according to https://en.wikipedia.org/wiki/List_of_Intel_Pentium_4_microprocessors
23:49:17 <bslsk05> ​en.wikipedia.org: List of Intel Pentium 4 microprocessors - Wikipedia
23:49:27 <geist> i have no idea if they had terrible 64bit errata or whatnot
23:49:55 <geist> i seem to remember there were some differences in the first versions from AMD, as if they had gone off an earlier spec given to them by AMD or something
23:50:06 --- quit: Halofreak1990 (Ping timeout: 268 seconds)
23:51:03 <geist> thens imilarly the first core processors were not 64bit, even if they came out logically after P4. took the core2 microarch to pick it up
23:52:30 <geist> oh i see. yeah it was the Yonah cpu which was really pentium M that was briefly launched and named Core
23:52:44 <geist> and then like a year later intel released the Core microarch and called them core too. yay intel
23:52:51 <geist> core microarch had 64bit, yonah did not
23:52:59 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
23:53:13 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
23:53:49 <geist> well,a ctually maybe the core microarch stuff was always named core 2 marketing wise. either way. confusing!
23:53:53 <_mjg_> geist: 32. i'm looking for something with sse2
23:54:00 <_mjg_> geist: can be single-treaded
23:54:05 <geist> yah i have one of those
23:54:15 <_mjg_> up for benchmarking kernel build?
23:54:30 <geist> not today, but can probably do it over the next few days
23:54:39 <geist> it's a freebsd build i assume, right?
23:54:42 <_mjg_> totally no rush, will harass you later
23:54:43 <_mjg_> yea
23:55:09 <_mjg_> zeroing with nt stores was dded around 2003
23:55:18 <_mjg_> in the tree
23:55:27 <_mjg_> curious if it helps on this cpu
23:55:32 <geist> ah i see
23:55:41 <_mjg_> this is total perf spelunking
23:55:59 <geist> will be curious to see how fast it does sysenter too (which i assume freebsd uses for 32bit syscalls)
23:56:03 <_mjg_> i suspect it does provide some win, but i'm interesting in hard data
23:56:05 <geist> on P4 iirc it was a disaster
23:56:14 <_mjg_> interested
23:57:07 <geist> i remember way years ago when i was momentarily using it as a target machine for doing newos dev once i had moved on to a K8 machine as my main i had benchmarked syscall performance and it was predictably crazy slow
23:59:07 <_mjg_> so a little bit of background is that some important perf-based decisions where *not* revisited after the amd64 port was created
23:59:12 <_mjg_> and just were taken from i386
23:59:39 <geist> iirc i went from the dual p3 500 i got in 99 to a K7 based machine, probably about 1.5Ghz in 2001 or so, then this HT P4 2.4 in about 2003, then i think a year later or so i switched to a dual 2Ghz G5 powermac as my main up until 2006 or so
23:59:59 --- log: ended osdev/18.05.23