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=19&m=8&d=2
04:12:04 <cloudowind> do you need to be invited to join a channel now?this is something new
04:14:09 <cloudowind> i can't even join linux
04:15:04 <cloudowind> got it i supposed to put second # , srry for the mass:) how are yous all
04:29:26 <johnjay> some channels are invite only
04:29:40 <johnjay> it's an optional mode to deal with flooding
04:35:12 <Mutabah> and others require nickserv registration
04:53:43 <ybyourmom> I don't rock chanel I rock channel; and naw this ain't a purse -- it's a satchel
05:19:54 * ybyourmom just finally decided to bit the bullet and buy a linode to host his mail and IRC
05:20:10 <ybyourmom> I'm tired of gmail always locking me out of my devices
05:20:12 <ybyourmom> Like, stop
05:25:03 <Matt|home> hm. im tired of having trouble understanding tech manuals.
05:25:48 <Matt|home> reading this is like reading something by a computer pretending to be a human pretending to be a computer.
05:26:17 <ybyourmom> Our problems are not on the same level bro, I'm up here
05:26:20 <ybyourmom> ^^^^
05:26:26 <ybyourmom> And your problems are down here
05:26:28 <ybyourmom> _____
05:26:58 <ybyourmom> My problems are like climate change compared to your pothole in the road bro
05:27:14 <Matt|home> perhaps you'd be so kind as to lend me your vast and infinite wisdom. im told intelligent people are often kinder to those creatures beneath them :\
05:27:43 <ybyourmom> rofl, dunno, I'm not the smartest cookie in the bakery -- I'm just a troubled man
05:42:35 <aalm> .theo
05:42:35 <glenda> You are showing inexperience.
05:45:25 <ybyourmom> K, logging out and logging in from my new linode server
05:45:28 <ybyourmom> hype
05:46:09 <klange> *And ybyourmom was never seen again*
05:47:21 <Matt|home> sigh.. i suppose it would be too much to ask for a more technically-capable person than myself of translating this into language a five year old can understand
05:48:02 <Matt|home> im sure if i paid them enough they'd do it..
05:53:33 <Mutabah> You'd probably get more luck just getting someone else to read/interpret it with you
05:54:11 <Matt|home> im just trying to wrap my head around memory models and how segmentation and crap works in x86.. i don't know why i have such a mental block here :\
05:55:00 <Mutabah> What processor mode? And what's the purpose?
05:55:22 <ybyourmom> Processor is in 64 bit mode
05:55:35 <ybyourmom> and my purpose is to use it as an irc server
05:55:40 <Mutabah> Should be able to 100% ignore segmentation then
05:55:41 <ybyourmom> y a h y e e t
05:55:52 <Mutabah> Wait... you're not Matt
05:56:03 <ybyourmom> sorry xD Felt excited
05:56:18 <Matt|home> well yeah that's the whole point. Mutabah , for instance: earlier i read you can have 'flat' and 'segmented'. but it's completely different between real and protected mode, and in both modes even 'flat' has segmentation, it's just.. tripping me up. either the wording my own stupidity or both
05:56:23 * Matt|home is done bitching
05:56:59 <Mutabah> "flat" just means that all segments have been set such that they have no impact on memory access rules
05:58:53 <ybyourmom> fg
05:59:26 <Mutabah> Matt|home: Feel free to ask questions in here, someone will probably be able to answer
05:59:43 <Mutabah> x86 is a backwards-compatability beast
05:59:54 <Matt|home> how do i get smarter..
06:04:27 <Matt|home> actually
06:04:51 <ybyourmom> sjobs
06:05:13 <ybyourmom> jobs
06:05:16 <Matt|home> i do have a legitimate question, a style choice :\ is there a particular reason why you would cover memory models in protected mode -first- when it seems real mode is simpler and designed to lead into it? i certainly hope there is a reason anyway.. :\
06:06:28 <ybyourmom> mtmux ls
06:06:43 <Mutabah> ybyourmom: You do know that this is IRC, not your shell?
06:08:10 <ybyourmom> My terminal messed up -- odn't mind me for a bit, sorry
06:08:59 <klange> rm -f ybyourmom
06:11:34 <immibis> probably because nobody uses real mode
06:13:38 <immibis> i don't know the context but if it's an x64 tutorial, do you really need to cover alternative memory models in very much detail?
06:13:54 <klange> Nothing about x86's real mode is "designed to lead into" protected mode.
06:14:12 <klange> Teaching history isn't as important as teaching current best-practice.
06:14:18 <immibis> maybe MS-DOS is designed to lead into windows
06:15:26 <Matt|home> im working on a bootloader for my kernel and covering an older intel chip :\
06:15:34 <Matt|home> they don't explain until like
06:15:36 <Matt|home> much later
06:15:41 <klange> who is "they"?
06:15:43 <Matt|home> how it actually works
06:15:48 <Matt|home> the authors of the manual, some intel guys
06:15:56 <klange> If you want to read about how old Intel CPUs work, read the old Intel CPUs work.
06:16:03 <Matt|home> anyway.. ignore me, im done complaining.
06:16:04 <klange> Also, the manuals are not structured.
06:16:12 <klange> They are not designed for you to read them from the front to the back.
06:17:03 <immibis> can you even get the old intel manuals from intel?
06:17:25 <Matt|home> https://css.csail.mit.edu/6.858/2014/readings/i386.pdf <-- have fun.
06:23:01 <klange> I would imagine the 386 manual in particular pushes real-mode information towards the back as it would be targetted primarily at devs who want to use the new features
06:44:36 <olsner> hm, according to that manual the 8086 doesn't implement the 15 byte instruction size limit, does that mean you can fill a code segment with 64kB of prefixes and have your 8086 just loop around it without ever executing a complete instruction?
08:27:37 <klys> olsner, well yeah. the instruction size limit isn't intrinsic to 808x intel processors like that; it's just a matter of enforcing to not treat prefixes as individual instructions. so if I go in and unassemble code with a prefix in ms-dos debug, it'll put prefixes on their own line. no surprises here.
08:58:38 <mrvn> olsner: are you allowed to have a prefix more than once?
08:59:53 <mrvn> can you exceed the 15 byte limit with the prefixes 808x had?
14:42:43 * mrvn should start a company: Silver linings - because every Cloud needs one.
15:26:55 <geist> re: x86 prefixes. i think the limitation came along later in 286 or 386
15:27:08 <zid> limitation?
15:27:11 <geist> probably when they started implementing an optimization to fetch a block of bytes and then pick the instructions out of it
15:27:16 <zid> 15 bye?
15:27:35 <geist> though iirc, 8086 was a teensy bit pipelined in that it did a bit of prefetching
15:27:36 <zid> didn't even the 8086 have a fetch buffer though
15:27:37 <geist> zid: yah
15:27:42 <zid> 6 bytes or something
15:27:51 <zid> I could imagine being able to handle a 6 byte instruction in 8086
15:27:56 <geist> something yah. the 15 byte instruction limit did ome along [retty early though
15:28:08 <zid> and then it being raised to 15 later in the 286 or something and staying there
15:28:18 <geist> may have been needed to be specced out in 386 because of 32bit instructions
15:28:23 <zid> I doubt it'd stricly matter these days now though, with the uop cache and stuff
15:28:25 <geist> that would have pushed the size
15:28:33 <zid> but it's nice to have constraints
15:28:35 <zid> for things like tooling
15:28:49 <geist> zid: well, sort of. i think the moment cache lines and whatnot showed up as an architectural detail it starts to matter a lot
15:29:00 <geist> ie, can't have instructions cross more than one cache line, that sort of thing
15:29:42 <zid> 15 being less than 16 is probably helpful implementation wise
15:29:49 <zid> 16 byte buffer with a tag or something
15:30:14 <geist> yah at most you get one buffer crossing that way
15:31:03 <zid> It might just consume the prefixes as instructions though
15:31:12 <zid> and it's actually having to keep track of how many and error at 15
15:31:20 <zid> rather than it being easier, it might be more work, how they've designed it
15:31:21 <zid> who knows
15:31:43 <geist> oh absolutely, it's a hard limit as of a while ago (386 i believe) so it's an architectural detail that you will fail at 16
15:32:11 <zid> geist lemme consume ur prefixes bb
15:32:13 <geist> i think it's fairly easy to hit with something like AVX (or maybe it was SSE)
15:32:30 <geist> since the base opcode is already 2 or 3 bytes long, then you get a few mods on it, then you have a lot of data
15:32:31 <zid> afaik you still need massive stacking to do it for a legal instruction
15:32:40 <zid> and avx doesn't do prefixes
15:32:47 <geist> maybe it was SSE, and AVX fixes it
15:33:01 <geist> i seem to remember it was actually possible to hit it with 'legit' instructions
15:33:18 <geist> but it was some vector class thing
15:34:31 <zid> lwpins rax, [fs:eax+ebx+disp32], imm32 is 8
15:34:43 <zid> but you can do 66 66 66 66 66 .. for mov
15:35:20 <geist> VAX has a similar instruction length limit i think
15:35:33 <geist> even with a much more highly regular instruction format
15:35:42 <geist> you can legitimately encode an instruction too long
15:36:38 <zid> geist: Given that instruction decoding silicon is not at a premium anymore
15:36:39 <geist> zid: ah you're looking at the same stack overflow
15:36:49 <geist> well, it still needs to be fast
15:36:54 <zid> and making the instructions too riscy slows you down because you have to re-fuse in hardware
15:37:08 <zid> when are we inventing an ISA with huffman encoded instructions
15:37:09 <geist> it's really the depth of the decision tree, since you usually have to do it in a cycle (at least for simple instructions)
15:37:33 <zid> nobody's going to notice if *every* instruction has 1 extra latency though, in a superscalar
15:37:38 <geist> so given a block of 32 bytes or so, picking out 4 or 5 instruction boundaries and first level decoding it in a single cycle is pretty complicated
15:37:51 <geist> sure but you have to free up the decoder for the next cycle
15:39:44 <geist> just deciding the instruction boundaries is already a pretty deep and parallel decoding tree
15:39:55 <zid> yea but I really don't think it matters at all
15:40:30 <geist> een if you can hide it under a few cycles of latency, any given stage is still tasked with getting it done in a cycle
15:40:47 <zid> when we're grabbing 64 bytes of icache way in advance and decomposing it into uops etc, as long as it's faster than we can run 64 bytes of instructions, we're good
15:40:52 <geist> and yeah i think it does take 2 or 3 stages to fully decode a simple x86 instruction on both intel an amd
15:41:08 <zid> we just have to have the *next* buffer available before the first one finishes
15:41:18 <zid> if there's any instruction in there with high latency: see *real* code, we're fine
15:41:20 <geist> well, look at zens back end, it can handle up to 11 different things
15:41:29 <zid> the only time we'd struggle is when we're decoding pages of nops imo
15:41:35 <geist> even picking out 5 instructions at a time its still fairly hard to light up the entire back end
15:41:43 <zid> because we'd execute the previous 64 bytes very quickly and the new 64bytes would need to be ready
15:42:30 <zid> I bet there's absolutely no difference between 1 clock of latnecy and like.. 5 clocks of latency, in practice. All icache is grabbed in advance (we hope) and decoded ahead of time
15:42:52 <geist> of course. i'm not arguing that pipelining doesn't work
15:43:07 <geist> but one of the stages of the decoder is literally 'find the boundaries of all the instructions'
15:43:08 <zid> yea but we *are* pipelined, so let's ignore it and huffman encode :p
15:43:25 <geist> which is itself pretty complicated, and has traditionally been a bottleneck
15:43:38 <zid> does huffman work in hardware
15:43:41 <geist> and something that uop and i cache tagging can help
15:44:08 <geist> even if you dont uop cache it you can store a little piece of metadata that says where the instruction boundaries are next time around
15:45:27 <zid> oh.. I could have just googled it
15:45:33 <zid> "Superscaler Huffman decoder hardware design"
15:46:18 <zid> possible at least then
15:46:27 <geist> sure
15:47:17 <mrvn> zid: the problem comes when you have a branch or exception or anything else that stops the linear code flow.
15:47:34 <mrvn> zid: you feel the 4 extra cycles every time.
15:48:23 <mrvn> As for 15 bytes. Aren't there mem->mem operations? If you do that in long mode that would be 16 bytes for the addresses alone.
15:49:12 <zid> oh I bet branches would be fun in a huffman coded instruction stream
15:49:17 <zid> you'd need to be able to jump on bit boundaries
15:49:59 <zid> It might be fun to design an ISA with compiler control over icache.
15:50:04 <mrvn> zid: would that realy make sense though? Maybe use a base 4 system (2 bit boundaries)
15:50:13 <zid> So you can load 64 64byte functions into some slots or whatever
15:50:19 <mrvn> zid: or require jump targets to be aligned (as they are now too for best speed)
15:50:28 <zid> then you had a special call that called one of the slots
15:50:55 <mrvn> zid: so basically JIT in hardware?
16:14:59 <geist> yah that alignment of branches and branch target thing has traditionally been related to instructions lining around cache lines and different limitations of decoders to deal with odd boundaries
16:15:28 <geist> i think modern x86s are fairly immune to that, except perhaps crossing a cache line, but i remember there being some mid 2000s era tweaks about how many branches you can have in a cache line, etc
16:15:45 <geist> due to limitations in how tightly the branch predictor could store metdata within a cache line
16:22:50 <zid> x86 really doesn't give a shit about cache lines anymore
16:22:55 <zid> it's almost impossible to get it to care
16:23:03 <zid> even sse is just as fast unaligned as aligned
16:23:26 <bcos_> monitor/mwait?
17:10:10 <zid> geist: oh, my friend is on your team apparently, til
20:36:11 <mrvn> It should help keeping loops inside a single cache line.
20:36:36 <mrvn> fewer lines needed for the hot set
20:45:36 <zid> which one of you is a network engineer, I broke my ipv6 and I can't fix it
20:47:19 <adu> zid: do you have 2001:4860:4860::8888 in your list of DNS servers?
20:47:26 <zid> shut up adu
20:48:56 * john_cephalopoda . o O ( Young people today with their bad memory, using DNS because they can't even remember the IPs of the sites they visit every day! )
20:50:22 <adu> just trying to help
20:53:31 <zid> yes but you don't know how so it's not particularly useful is it
20:53:55 <zid> you're the guy arguing with the paramedics
22:03:23 <ox6> but zid