< 1613347261 372620 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613347515 372272 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 246 seconds < 1613347619 359395 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613347667 379546 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Read error: Connection reset by peer < 1613347699 454631 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613348045 330475 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613351177 869169 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :These are my ideas so far of the mirror protocol: http://sprunge.us/GZT9QV < 1613351210 68589 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Please make a comment of it. < 1613351282 814833 :oerjan!oerjan@sprocket.nvg.ntnu.no JOIN :#esoteric < 1613351305 112892 :arseniiv!~arseniiv@136.169.205.6 QUIT :Ping timeout: 256 seconds < 1613351528 728705 :privateger!~privatege@94.31.82.151 QUIT :Quit: Leaving. < 1613351657 472372 :clog!~nef@bespin.org JOIN :#esoteric < 1613351918 371748 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613351929 112224 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hey, I have a ridiculous question, so this seemed like a good channel to ask it < 1613351952 220764 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm trying to mmap over NULL to make my process's virtual address 0 a valid address; it seems that by default you can do this as root, but not as a regular user < 1613351979 308372 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I vaguely remember there's a kernel setting that makes doing that legal even for regular users; does anyone here happen to know/remember what it is, or should I go hunting for it? it's hard to search for < 1613352076 9688 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esoteric :i vaguely remember that was a possible security hole? < 1613352081 404133 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I don't know what it is; I have not heard of that before, though. < 1613352088 12917 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, it's the vmsplice security hole from 2008, now patched < 1613352101 989919 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(the context is a code-golfing-like situation, I'm wondering how many bytes / uops it's theoretically possible to save in a hot loop, and it crosses my mind that you can simplify things by having the loop end at address 0 so that the check for the loop end is simpler) < 1613352119 5725 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esoteric :heh < 1613352133 940373 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esoteric :ACTION doesn't know the answer, anyway < 1613352141 721127 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Yeah, there was a sysctl for it, right? < 1613352159 137450 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I already found the solution where you just add a SIB byte to every memory access containing a nonzero value, and use that as a "virtual zero" < 1613352160 813159 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :vm.mmap_min_addr? < 1613352163 653365 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also the solution using segment registers < 1613352169 665217 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but both of those add at least one additional byte < 1613352189 949141 :hendursa1!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613352197 897200 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :`` cat /proc/sys/vm/mmap_min_addr < 1613352198 875495 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :4096 < 1613352209 384376 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Sounds plausible to me. < 1613352210 833372 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds < 1613352220 856398 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yep, looks right < 1613352237 36675 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :thanks, I wasn't 100% sure that someone would know it off the top of their head, but this place seemed as likely as any < 1613352266 192901 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I had a faint recollection you had to change that to make dosemu work right. < 1613352297 324750 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the funny thing is, this is the sort of code that a) wants to map over NULL, *and* b) wants to use vmsplice < 1613352305 790381 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I bet at the time of the fix, nobody thought that was a legitimate combination < 1613352437 390627 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this isn't documented in either proc(5) nor mmap(2) (and the return value is EPERM which isn't supposed to be caused by this) < 1613352454 363573 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, Linux's userspace/kernel-interface documentation is rather more lacking than I'd hoped < 1613352469 183304 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I had to read about four files of kernel source code to figure out what vmsplice actually does < 1613352526 599321 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(what it does is to take a page of memory from your process, flag it as copy-on-write, then mmap it directly into a pipe buffer so that reads from the pipe will read from your process's memory if you don't change it before the read, or from a copy of the memory if you do) < 1613352586 931922 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so vmsplice to the write end of a pipe, followed by another process reading from the read end, only copies the data once (in read); if you write rather than vmsplice, the data gets copied twice (on both write and read) < 1613352612 97041 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the caveat is that if you modify the page in question at all before the pipe gets read, the kernel has to copy the entire page containing the data you wrote, rather than just the data itself (and also adjust page tables, which is slow) < 1613352640 149563 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: sorry for my connection < 1613352652 344170 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613352688 629314 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the kernel devs were hoping to implement vmsplice for the read end of a pipe, too, but couldn't think of a good way to handle the mapping *into* user space, so right now it's effectively just an alias for readv that only works on pipes < 1613352825 812933 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :maybe I should just use a %fs: prefix, although there's little documentation as to how expensive those are; my guess would be that they're cheap due to the need to support backwards compatibility for 32-bit programs, but I may be wrong < 1613352903 417315 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Actually, I also found the documentation for some Linux features (including stuff in /proc) to be incomplete < 1613352939 882896 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I don't even think there's an official piece of documentation anywhere for how you make a system call from userspace < 1613352948 112395 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in terms of calling convention and ABI < 1613352979 65007 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Use %fs for what? < 1613352981 446144 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(although there seems to be a consensus that all registers are call-preserved, including the flags and argument registers, with the exception of %rcx and %r11, and the return value %rax) < 1613352992 784137 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Isn't it used for thread-local storage on Linux nowadays? Or is that gs? < 1613353012 238588 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: so the idea is that you have a loop with a pointer that points to useful memory, but also doubles as the loop counter < 1613353020 786092 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and the loop ends when the pointer hits 0 < 1613353081 306962 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in order to use this pointer usefully, you can either a) make it an index rather than a pointer (requiring a base register and a SIB byte); b) mmap over NULL so that 0 is a valid address; or c) use a segment override so that the pointer with value 0 actually points to some part of virtual memory other than the bottom < 1613353098 562224 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :segment overrides used to be much more complex in 16-bit and 32-bit x86 < 1613353128 838293 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but in x86-64, there are only two segment overrides that do anything (%fs: and %gs:), and their effect is unrelated to the actual value in the %fs or %gs registers < 1613353192 266967 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :each of them just adds a constant offset to the address it modifies; there are a few different ways to specify the constant (but typically, you tell the kernel what constant you want and it sets up the processor according to the offsets you requested during context switches) < 1613353259 215942 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :thread-local storage takes advantage of the fact that each thread is context-switched to separately by the kernel, so each thread is given its own %fs base by the threading library, which points to the start of the thread's thread-local storage < 1613353283 777824 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Isn't the constant offset the value in the %fs register? < 1613353287 398704 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which means that at the assembly level, accessing (say) the 33rd byte of TLS is as simple as %fs:(32) < 1613353289 387553 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: no < 1613353299 23319 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that would be the logical thing to do, but they're actually unrelated < 1613353303 817990 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in most cases, the value in the register is 0 < 1613353357 200938 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(the exception is that writing to the register will write the offset, too; but the relationship between the value you write and the offset that is loaded is not the identity function, it's actually calculated using a lookup table that on Linux, you can specify using the modify_ldt system call) < 1613353372 861760 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :only the values in the lookup table are only 32 bits long for some reason < 1613353404 335704 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613353406 422366 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so in general, you don't ever write to %fs or %gs directly < 1613353420 175105 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can write to the offset registers, %fsbase and %gsbase, directly on some recent Intel processors < 1613353426 173870 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which is what you probably actually wanted to do < 1613353429 797464 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I see, fsbase and fs are different things? < 1613353433 801705 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1613353473 774122 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And these are set by some MSR. < 1613353488 703709 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I learned the other day that both Linux and Windows swapped the segment override they're using for TLS when going from x86-32 to x86-64; since they started out using the opposite registers, they still do. < 1613353505 716248 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right, if you don't have wrfsbase/wrgsbase instructions, you need to use an MSR to set them (which is why you need a system call to set them in Linux, because only the kernel can write MSRs) < 1613353533 796248 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fizzie: I have no idea why you'd pick %fs or %gs in particular for this < 1613353536 322311 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If I remember correctly it's also impossible to even get the fsbase/gsbase value directly. < 1613353550 794785 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :ais523: There's a SWAPGS instruction, but no SWAPFS counterpart, that's what I was given as the reason. < 1613353559 113183 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And so Linux stores the value of gsbase at %gs:0 or something like that. < 1613353563 555957 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: it *was*, but Intel added RDFSBASE recently < 1613353584 527758 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think there are still lots of processors that don't have it, though, it's fairly new < 1613353607 969994 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Will the instruction be emulated on computers that don't have it? < 1613353619 384774 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fizzie: I realise that, but it's unclear what the performance properties are < 1613353620 636846 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You might hope that nowadays something like lea %fs:0, %rax would be valid. < 1613353640 553897 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm mov %fs:0, %rdx < 1613353641 936443 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 64 48 8b 14 25 00 00 00 00 mov %fs:0x0,%rdx < 1613353655 107797 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm lea 0, %rdx < 1613353656 135480 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 48 8d 14 25 00 00 00 00 lea 0x0,%rdx < 1613353665 343771 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613353674 115592 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: lea ignores segment registers < 1613353681 195958 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I was curious about this myself, so decided to test it < 1613353689 935902 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and gas actually produced a warning telling me that it doesn't work < 1613353706 436601 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm rdfsbase %rdx < 1613353707 480656 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: f3 48 0f ae c2 rdfsbase %rdx < 1613353709 469218 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, but you might hope otherwise, in long mode. < 1613353738 196095 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :wow, the "f3 48 0f" prefix seems so dirty < 1613353741 294827 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613353746 328334 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :even though that is the only legal ordering for the prefixes < 1613353774 576939 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm .byte 0x64, 0x48, 0x14, 0x25, 0, 0, 0, 0 < 1613353775 505760 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 64 48 14 25 fs rex.W adc $0x25,%al \ 4: 00 00 add %al,(%rax) \ ... < 1613353789 356179 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm .byte 0x64, 0x48, 0x8d, 0x14, 0x25, 0, 0, 0, 0 < 1613353790 442974 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 64 48 8d 14 25 00 00 00 00 lea %fs:0x0,%rdx < 1613353814 263212 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So it is encodable, it just ignores it. < 1613353822 990861 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that's a totally valid instruction, but its actual effect is to write 0 to %rdx < 1613353843 411659 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm lea 0, %fs:0(%rdx) < 1613353844 376079 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: too many memory references for `lea' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: junk `:0(%rdx)' after expression < 1613353851 974097 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613353854 30628 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm lea %fs:(0), %rdx < 1613353855 35398 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 64 48 8d 14 25 00 00 00 00 lea %fs:0x0,%rdx < 1613353857 674259 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there we go < 1613353861 469606 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Well, it's named after "load effective address", and the effective address is by definition before segments. < 1613353875 528797 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :That's what distinguishes it from the linear address. < 1613353877 286936 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you'd need a "load linear address" to get the post-segmentation value < 1613353895 240319 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :maybe even a "load physical address" to get a complete set < 1613353948 961482 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, I wouldn't expect to get physical addresses in userspace. < 1613353949 830513 :hendursa1!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds < 1613353964 753186 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it doesn't seem that ridiculous of a thing to be able to do at CPL 0 < 1613353990 520269 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the implementation of vmsplice needs to get physical addresses, for example < 1613354009 400104 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the kernel has to do a page walk in order to figure it out, duplicating the work that the processor does in hardware < 1613354027 287956 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 272 seconds < 1613354031 807728 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(a side effect of this is that vmsplice runs faster if you're using hugepages) < 1613354108 839684 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so basically, what I'm saying is that LPA should probably be restricted to kernel space, but there are plenty of processor instructions that are restricted to kernel space < 1613354288 238205 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Yes, I think so < 1613354347 666326 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Does x86-64 have emulation of invalid instructions (either not implemented or not allowed)? < 1613354395 619749 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: indirectly; an invalid instruction causes a #UD trap, which the kernel gets an opportunity to react to < 1613354425 293558 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :on physical hardware, most kernels will react to this by causing a SIGILL instruction; however, a kernel could if it wanted to emulate the instruction then return (there is sufficient information in the trap for this) < 1613354456 658362 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :It can help then, if a program uses instructions that your computer doesn't have, the kernnel can emulate it, or if it uses a privileged instruction that the user program has sufficient privilege to use < 1613354463 442463 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I remember reading that Windows used to use illegal instructions to do system calls, because they were faster than a regular interrupt for some reason. < 1613354486 320368 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the "canonical illegal instruction" that you're supposed to use for intentional SIGILLs is ud2, and I vaguely remember that the reason for the name is that there was once also a ud1 instruction, intended to "soft extent" the instruction set by having the kernel handle the #UD trap < 1613354504 547766 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but I can't find documentation for ud1 in either the Intel or AMD guides, so maybe it was removed < 1613354531 526188 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(that said, if the kernel is going to be assigning a meaning to ud1 combinations, maybe they aren't a good suggestion for intentionally illegal instructions) < 1613354558 979611 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :https://www.felixcloutier.com/x86/ud also talks about ud0 < 1613354601 360431 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I remember this subtlety about decoding ud0 without the modrm byte. < 1613354764 919082 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0x0f, 0xff, 0x00 < 1613354767 345358 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f ff 00 ud0 (%rax),%eax < 1613354777 231433 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0x0f, 0xb9, 0x00 < 1613354778 195422 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f b9 00 ud1 (%rax),%eax < 1613354782 809939 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0x0f, 0xf1, 0x00 < 1613354783 903779 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f f1 00 psllw (%rax),%mm0 < 1613354794 586795 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0x0f, 0x1f, 0x00 < 1613354795 588757 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1f 00 nopl (%rax) < 1613354798 218694 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there we go < 1613354808 818236 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so it seems that ud0 and ud1 take two arguments each < 1613354843 450699 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :incidentally, I recently realised that it's possible to at least encode a vectorized NOP, by following the normal rules for vectorising other instructions < 1613354847 652215 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but I got a SIGILL when I tried < 1613354853 869550 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :was disappointing < 1613354868 368123 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :along similar lines you can write a vectorized ud0 or ud1 or ud2 < 1613354894 511641 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :these will presumably also give a SIGILL, and there may be some debate about whether they're real instructions or not because a SIGILL is the expected effect :-) < 1613355190 655680 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :isn't there at least one OS that uses ud2 as its syscall instruction? < 1613355220 2102 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I actually had a crazy idea of using pagefaults as a system call instruction < 1613355225 474763 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :lol < 1613355226 433500 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this would allow for things like memory-mapped pipes < 1613355260 131259 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the advantage is that you could remove a lot of loop logic from the userspace side, whereas the kernel side may well not be any slower < 1613355279 553961 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(although, I think `syscall` is meant to be faster than all the other ways of doing system calls) < 1613355307 662368 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :hmm, if a store causes a pagefault, can the handler get access to the value which was to be written? < 1613355313 514987 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :on x86 i don't think it can :/ < 1613355369 890569 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :can you get the exact bytes of the instruction which faulted in order to emulate it? of course you can get %rip and read the program memory but that might have a race condition in some crazy circumstance < 1613355421 640761 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think you're supposed to just read %rip, although I can imagine the crazy circumstance in which the race condition occurs < 1613355469 722302 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :at least the plus side is that the race condition can be handled by looking at the bytes to see if they're an instruction that could have produced the sort of fault you see, emulating if so, and just returning and rerunning the instruction otherwise < 1613355483 523036 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :yeah it's not that crazy really. just multithreading + self modifying code < 1613355497 643099 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because that won't produce any results that you couldn't have seen with a slightly different method < 1613355503 849752 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, a slightly different timing < 1613355508 760307 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :mhm < 1613355516 321668 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this isn't self-modifying code, but other-modifying code < 1613355572 929446 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :from the processor's point of view, it would show up as an RFO for L1c data, which is not a path that's going to be used pretty much ever < 1613355580 711431 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :wtf is rdfsbase? < 1613355584 885399 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :i thought the long mode fs base was in a msr < 1613355595 22177 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it returns the "value of the msr" < 1613355614 489968 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :so why not use rdmsr < 1613355618 381266 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, from various discussion of MSRs, I have the strong suspicion that they don't actually exist as separate entities within the processor < 1613355625 201774 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :rdmsr is privileged, and possibly slower? < 1613355634 777966 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :what do you mean by "separate entities" < 1613355651 300673 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :rdmsr and wrmsr seem to be processor-level system calls, they're basically just function calls < 1613355659 983309 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :are you saying that they're microcoded < 1613355669 634805 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, and they can apparently be microcoded to do anything < 1613355687 42259 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :that's fair < 1613355694 922907 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :one of the workarounds for one of the spectre vulnerabilities was to add a new MSR that emptied the branch target buffer when written < 1613355698 336343 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :wrmsr is to opcodes as ioctl is to syscalls :P < 1613355702 84773 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and which returns 0 when read < 1613355704 200044 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :mm < 1613355750 786447 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it strikes me as very unlikely that Intel would have added a physical register with that specific behaviour to the processors they'd actually released and not told anyone out of it, so it's probably some sort of virtual register that exists only in microcode < 1613355761 321315 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :* not told anyone about it < 1613355808 769671 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, if rdmsr is microcoded, I can easily imagine that a hardwired rdfsbase would be faster < 1613355830 745311 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :fair enough < 1613355843 529313 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :and the fs base does pretty much have to be in a hardware register < 1613355871 659982 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :i mean also all the user visible registers are virtual in some sense < 1613355898 848569 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :there's not an actual specific set of 64 flip flops corresponding to RAX, not anymore < 1613355914 344142 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :with out of order and speculative execution the ISA registers are assigned to physical registers on the fly < 1613355928 49261 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :but that's still different from executing arbitrary microcode of course < 1613355954 966199 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, there are tens or hundreds of actual physical registers, and the only purpose register names like rax is to let the processor know which outputs of which instructions should be connected to which inputs of which other instructions < 1613356010 712058 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, there *is* an actual register rax, but it isn't used most of the time (its purpose is to remember what data is in the register the programmer thinks of as "rax" in the case that rax isn't mentioned for a very long time but its value becomes relevant again in some later code, without being overwritten) < 1613356054 754332 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if a register isn't used for so long that it falls out of the register allocation table, the processor needs some way to remember where it's storing the value of the register in question, that's why there's a permanent register file < 1613356061 92409 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ah < 1613356107 725441 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :apparently old Intel processors had a bandwidth limitation on the permanent register file, and the processor would stall if you suddenly accessed three registers simultaneously that hadn't been accessed for ages, although that's been fixed in more recent processors < 1613356199 661845 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :does the VT-x VMCS contain MSRs? it must have some < 1613356201 874249 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :like the FS base < 1613356218 572747 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :so those are sort of promoted to ISA registers and are not really "model specific" in the same way < 1613356226 519079 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I don't know, I haven't looked into how virtualisation is implemented < 1613356230 831780 :oerjan!oerjan@sprocket.nvg.ntnu.no QUIT :Quit: Later < 1613356237 845723 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :arguably, the virtualisation is itself a model < 1613356242 140 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I wonder if it can define its own MSRs < 1613356265 517820 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 240 seconds < 1613356273 43774 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :I think you can set it to trap to the hypervisor on all MSR access < 1613356279 15646 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, something else aggravating that I discovered recently is that Intel and AMD encode their cache information differently in the CPUID output < 1613356281 480439 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :probably intended so that you can emulate MSRs that don't exist on your physical CPU < 1613356312 211733 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1613356339 134183 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fortunately, the value you care most about in code is normally the size of the L2 cache, and although you get almost entirely zeroes if you use AMD's method for accessing cache information on an Intel processor, the value for the L2 cache size specifically is filled in in the same format that you get on an AMD processor < 1613356350 384000 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so you just get a few random L2 cache parameters in a sea of zeroes < 1613356362 524115 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :presumably, Intel had to implement that to avoid breaking existing software < 1613356371 841581 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :huh < 1613356381 857015 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(this is documented, too, as a guarantee that you can find the L2 cache information there) < 1613356461 417299 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :looks like it's L2 cache line size, L2 cache size, L2 cache associativity, and the other 29 values that the cpuid call is meant to return are all zeroes, and this is documented behaviour < 1613356480 831920 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :at least this makes it easy to write L2-cache-aware programs that function on both Intel and AMD processors < 1613356584 430812 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :cpuid is another wastebasket taxon of an instruction < 1613356590 104260 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :wasn't it used as a memory fence on some CPUs?? < 1613356619 23493 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :still is < 1613356623 382399 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :not memory fence, though < 1613356626 823098 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :instruction ordering fence < 1613356641 746102 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :all the instructions before the cpuid are guaranteed to run before any instruction after the cpuid does < 1613356652 788864 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are a few other instructions with that property, cpuid might be the fastest though? < 1613356660 717616 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's vaguely useful for things like cycle-accurate benchmarking < 1613356682 865068 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you want a proper memory fence you need mfence, not cpuid, because I don't think cpuid guarantees things like stores having reached memory < 1613356787 332968 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, it's also worth noting that most stores on x86 have an implicit sfence on them (you need to jump through hoops to get an un-sfenced store) < 1613356796 141614 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so mfence and lfence are useful, but sfence is virtually useless < 1613357000 360142 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613357256 376139 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613357464 329790 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613357725 335304 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613358783 96748 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh wow, browsing instruction lists, I just discovered why LDDQU exists (when MOVDQU also exists) < 1613358799 369956 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :oh? < 1613358811 707387 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :x86 is so stupidly complicated :( < 1613358819 936601 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's a different-performance-properties variant: LDDQU is designed to have high throughput for unaligned data which isn't being written at the time < 1613358838 961224 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ah < 1613358841 297080 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :whereas MOVDQU is designed to have low latency, especially when the data has been written recently or is about to be written back < 1613358849 93564 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :interesting < 1613358857 181791 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :does that mean lddqu bypasses some caches? < 1613358877 911987 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also LDDQU can over-read on either side and is explicitly allowed to read the same memory twice < 1613358884 394759 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :my guess is that LDDQU is bypassing the store-forwarding buffer < 1613358924 724643 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(which you can think of as the "L0 cache") < 1613358939 191452 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it only caches writes, not reads < 1613360712 876886 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613360998 815420 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 256 seconds < 1613362249 453176 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613362466 443273 :spruit11!~unknown@86.82.44.193 QUIT :Read error: No route to host < 1613362505 410705 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613364009 378808 :craigo!~craigo@144.136.206.168 JOIN :#esoteric < 1613365091 426592 :mich181189!sid268336@gateway/web/irccloud.com/x-kingoalphuaqblae QUIT :Read error: Connection reset by peer < 1613365106 301831 :mich181189!sid268336@gateway/web/irccloud.com/x-mrsdbhgohtsgugmv JOIN :#esoteric < 1613365174 176627 :sftp!~sftp@unaffiliated/sftp QUIT :Quit: leaving < 1613365191 309094 :sftp!~sftp@unaffiliated/sftp JOIN :#esoteric < 1613365484 373761 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613365526 946479 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Did you read the document I linked? Maybe you have some idea for improvement, too. < 1613365743 399016 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 246 seconds < 1613366881 346805 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613367068 97772 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 QUIT :Ping timeout: 272 seconds < 1613367321 334117 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 264 seconds < 1613367864 417689 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613368105 403800 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds > 1613369715 320850 PRIVMSG #esoteric :14[[07PRINTASKSWITCHINPUTCASEXGOTOACASEYGOTOBELSEGOTOC14]]4 10 02https://esolangs.org/w/index.php?diff=80736&oldid=80723 5* 03Quintopia 5* (+2019) 10Add implementation > 1613369906 547739 PRIVMSG #esoteric :14[[07User:Quintopia14]]4 M10 02https://esolangs.org/w/index.php?diff=80737&oldid=80090 5* 03Quintopia 5* (+55) 10python impls < 1613370170 388154 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613370426 375510 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 246 seconds < 1613370799 363875 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613370879 429893 :tromp_!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613370879 561882 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Read error: Connection reset by peer < 1613371136 365953 :tromp_!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613371286 144497 :sprock!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 272 seconds < 1613371311 478904 :sprock!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1613371933 374305 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613371976 179047 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: quit < 1613372132 407302 :spruit11!~unknown@86-82-44-193.fixed.kpn.net JOIN :#esoteric < 1613372925 458278 :sprock!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 240 seconds < 1613375566 942766 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1613377296 388674 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1613379830 738749 :LKoen!~LKoen@96.252.88.92.rev.sfr.net JOIN :#esoteric < 1613379955 887357 :hendursa1!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613379997 825425 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds < 1613380143 918762 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613380256 821926 :hendursa1!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds < 1613380619 118302 :imode!~imode@unaffiliated/imode QUIT :Quit: Sleepy sheepy.. < 1613380830 497345 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine < 1613380910 573007 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1613381746 196317 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613382965 879666 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613383167 118236 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Ping timeout: 265 seconds < 1613386134 970183 :x201!~Administr@101.93.81.125 JOIN :#esoteric < 1613386202 876787 :x201!~Administr@101.93.81.125 PART :#esoteric < 1613387084 372709 :craigo!~craigo@144.136.206.168 QUIT :Quit: Leaving < 1613388336 423869 :arseniiv!~arseniiv@136.169.205.6 JOIN :#esoteric < 1613392245 376332 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :Ping timeout: 246 seconds < 1613392293 340604 :sftp!~sftp@unaffiliated/sftp QUIT :Ping timeout: 272 seconds < 1613392356 712936 :sftp!~sftp@unaffiliated/sftp JOIN :#esoteric < 1613394198 621738 :LKoen_!~LKoen@96.252.88.92.rev.sfr.net JOIN :#esoteric < 1613394318 804084 :LKoen!~LKoen@96.252.88.92.rev.sfr.net QUIT :Ping timeout: 256 seconds > 1613395171 466199 PRIVMSG #esoteric :14[[07Assignless14]]4 M10 02https://esolangs.org/w/index.php?diff=80738&oldid=52732 5* 03PythonshellDebugwindow 5* (+60) 10Cats, stub < 1613396034 71751 :rain1!~rain1@unaffiliated/rain1 JOIN :#esoteric < 1613396067 235630 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613397135 348469 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613397851 387904 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1613398866 762317 :xelxebar_!~xelxebar@gateway/tor-sasl/xelxebar JOIN :#esoteric < 1613398867 875368 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar QUIT :Ping timeout: 268 seconds < 1613399136 353560 :arseniiv!~arseniiv@136.169.205.6 QUIT :Ping timeout: 240 seconds < 1613399143 855701 :rain1!~rain1@unaffiliated/rain1 QUIT :Quit: Leaving < 1613400128 341848 :arseniiv!~arseniiv@136.169.205.6 JOIN :#esoteric < 1613400146 23603 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Quit: hendursaga < 1613400190 887484 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613404131 406075 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Ping timeout: 246 seconds < 1613407295 568992 :LKoen_!~LKoen@96.252.88.92.rev.sfr.net QUIT :Remote host closed the connection > 1613407447 611591 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80739&oldid=80692 5* 03Digital Hunter 5* (+829) 10/* Example programs */ added a pi calculator program > 1613407508 563980 PRIVMSG #esoteric :14[[07Parse this sic14]]4 M10 02https://esolangs.org/w/index.php?diff=80740&oldid=80739 5* 03Digital Hunter 5* (+53) 10/* Deadfish interpreter */ < 1613407582 837786 :LKoen!~LKoen@96.252.88.92.rev.sfr.net JOIN :#esoteric < 1613407802 130713 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1613408803 735312 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :fungot: in English, do people really pronounce "chassis" with the final "s" silent? if so, why? < 1613408804 560614 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :b_jonas: madam president, i should just like to say that this problem cannot be available. mr bolkestein, i should like to take this stand because of certain wordings such as " the farmer's privilege'. i also think it is very important that this trend must now be incorporated into the constitution in its entirety to the whole of africa is dramatic. i am an optimist: this situation also has benefits. for in the final analysis, t < 1613408891 538643 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :hmm < 1613408896 736268 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I don't think that answers my question < 1613409013 709387 :int-e!~noone@int-e.eu PRIVMSG #esoteric :. o O ( faux francaise ) < 1613409131 477825 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613409340 904933 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Client Quit < 1613409359 497651 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613410253 453526 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Remote host closed the connection < 1613410266 593451 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613410953 349996 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Ping timeout: 264 seconds < 1613411023 312229 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613411190 782735 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613411441 379080 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613412111 506691 :ocharles!sid30093@musicbrainz/user/ocharles QUIT :Read error: Connection reset by peer < 1613412122 417513 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613412125 563602 :ocharles!sid30093@musicbrainz/user/ocharles JOIN :#esoteric < 1613412256 345754 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Ping timeout: 240 seconds < 1613412338 479727 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613412572 830653 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613412848 838465 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 256 seconds < 1613414392 76933 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613414715 460585 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 246 seconds < 1613414780 485200 :sprock!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1613415190 484361 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613415647 382290 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1613416108 144078 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613416444 309331 :LKoen!~LKoen@96.252.88.92.rev.sfr.net QUIT :Read error: Connection reset by peer < 1613416472 160372 :LKoen!~LKoen@96.252.88.92.rev.sfr.net JOIN :#esoteric < 1613416932 130901 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613417335 397953 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613417838 797947 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca QUIT :Remote host closed the connection < 1613417882 575017 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca JOIN :#esoteric < 1613419117 223060 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I called the customer service of a fast-food restaurant because they put fewer food into my delivery than I payed for. They gave me a coupon for my next order. The customer service rep on the phone told me that he'd talk to the restaurant and then call me back. fungot, do you think he really talked to the restaurant before calling me back, or is this just something they say? < 1613419117 944649 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :b_jonas: mr president, presidents of parliament pass by, honourable members, who will not, in the case of these condemned women. speaking fnord, the indiscriminate use of force and that is perhaps even more significant than others and it has the resources. the rapporteur has had to do was to protest about the electronics here. i am therefore favourable to these amendments on board, but they are some of the discussions on intern < 1613419146 835324 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :this euparl or brexit style isn't really suitable for these sorts of questions < 1613419148 931029 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :^style < 1613419148 999676 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :Available: agora alice c64 ct darwin discworld enron europarl* ff7 fisher fungot homestuck ic irc iwcs jargon lovecraft nethack oots pa qwantz sms speeches ss wp ukparl youtube < 1613420056 521007 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613420100 683533 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :^style qwantz < 1613420100 778579 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :Selected style: qwantz (Dinosaur Comics transcriptions 2003-2011) < 1613420104 127954 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I called the customer service of a fast-food restaurant because they put fewer food into my delivery than I payed for. They gave me a coupon for my next order. The customer service rep on the phone told me that he'd talk to the restaurant and then call me back. fungot, do you think he really talked to the restaurant before calling me back, or is this just something they say? < 1613420105 141164 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :b_jonas: here, i'll prove it, too, will take what i can get a little of that back with them, dromiceiomimus what's up, champ! here, have some lego. if people wanted traditional! they want new and sexy > 1613420558 156182 PRIVMSG #esoteric :14[[07Divrac14]]4 M10 02https://esolangs.org/w/index.php?diff=80741&oldid=80710 5* 03Quintopia 5* (+0) 10fix truth-machine > 1613420771 202933 PRIVMSG #esoteric :14[[07Divrac14]]4 10 02https://esolangs.org/w/index.php?diff=80742&oldid=80741 5* 03Quintopia 5* (+2207) 10impl > 1613420784 423237 PRIVMSG #esoteric :14[[07Divrac14]]4 M10 02https://esolangs.org/w/index.php?diff=80743&oldid=80742 5* 03Quintopia 5* (-1) 10/* Python 3 */ > 1613420811 754250 PRIVMSG #esoteric :14[[07Divrac14]]4 M10 02https://esolangs.org/w/index.php?diff=80744&oldid=80743 5* 03Quintopia 5* (+0) 10/* Python 3 */ > 1613420856 750600 PRIVMSG #esoteric :14[[07User:Quintopia14]]4 10 02https://esolangs.org/w/index.php?diff=80745&oldid=80737 5* 03Quintopia 5* (+13) 10 < 1613421818 130653 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric > 1613421853 396683 PRIVMSG #esoteric :14[[07Divrac14]]4 M10 02https://esolangs.org/w/index.php?diff=80746&oldid=80744 5* 03PythonshellDebugwindow 5* (+57) 10/* Semantics */ Fix typo; "clarify" n<2 < 1613421981 390073 :scoofy!~scoofy@catv-89-135-21-225.catv.broadband.hu QUIT :Ping timeout: 246 seconds < 1613422315 198076 :arseniiv!~arseniiv@136.169.205.6 PRIVMSG #esoteric :I’m reading “DSP tutorial for the braindead”. Some lore there < 1613422364 637579 :arseniiv!~arseniiv@136.169.205.6 PRIVMSG #esoteric :I cornered myself up in trying to generate a sine wave most effectively, using nothing more than numpy < 1613422544 61467 :arseniiv!~arseniiv@136.169.205.6 PRIVMSG #esoteric :also I want to experiment with noisy tonal oscillators and try to use convolution with a fake gaussian for that (piecewise quadratic for large sigmas and binomial for small ones, which I hasn’t implemented yet, and both I haven’t yet tested) < 1613422644 51823 :arseniiv!~arseniiv@136.169.205.6 PRIVMSG #esoteric :the end goal is to mess with timbres with harmonics with various irrational rations between them, like golden ratio or sqrt(2). I’m a tad slow and lazy with all that though < 1613422665 437387 :arseniiv!~arseniiv@136.169.205.6 PRIVMSG #esoteric :too many diverse subtasks < 1613422797 755930 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :fun fun < 1613423081 381129 :scoofy!~scoofy@catv-89-135-21-225.catv.broadband.hu JOIN :#esoteric > 1613423711 270616 PRIVMSG #esoteric :14[[07Divrac14]]4 M10 02https://esolangs.org/w/index.php?diff=80747&oldid=80746 5* 03PythonshellDebugwindow 5* (+40) 10/* Implementations */ See resources > 1613423751 486136 PRIVMSG #esoteric :14[[07Divrac14]]4 M10 02https://esolangs.org/w/index.php?diff=80748&oldid=80747 5* 03PythonshellDebugwindow 5* (+121) 10/* External resources */ GitHub < 1613424333 371016 :scoofy!~scoofy@catv-89-135-21-225.catv.broadband.hu QUIT :Ping timeout: 246 seconds < 1613424787 820025 :aloril!~aloril@mobile-access-56737e-89.dhcp.inet.fi QUIT :Ping timeout: 260 seconds < 1613425363 857237 :arseniiv!~arseniiv@136.169.205.6 PRIVMSG #esoteric :kmc: I thought you might like this topic yeah :) < 1613425677 353868 :arseniiv!~arseniiv@136.169.205.6 QUIT :Ping timeout: 264 seconds < 1613426146 796115 :aloril!~aloril@mobile-access-5d6af7-206.dhcp.inet.fi JOIN :#esoteric < 1613431280 665916 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection > 1613431895 107580 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80749&oldid=80740 5* 03Digital Hunter 5* (-15) 10/* Fibonacci numbers */ shorter one .. < 1613432020 802481 :mmmattyx!uid17782@gateway/web/irccloud.com/x-urgxqrzuotzhrnhk JOIN :#esoteric > 1613432423 5564 PRIVMSG #esoteric :14[[07C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)14]]4 N10 02https://esolangs.org/w/index.php?oldid=80750 5* 03CatCatDeluxe 5* (+4256) 10Created page with "C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(C) is a C-like programming language created to be very hard and annoying to read and write. It has the same langua..." > 1613432476 902343 PRIVMSG #esoteric :14[[07C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)14]]4 10 02https://esolangs.org/w/index.php?diff=80751&oldid=80750 5* 03CatCatDeluxe 5* (+8) 10 > 1613432715 888804 PRIVMSG #esoteric :14[[07C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)14]]4 10 02https://esolangs.org/w/index.php?diff=80752&oldid=80751 5* 03CatCatDeluxe 5* (+66) 10 > 1613432897 398475 PRIVMSG #esoteric :14[[07User:CatCatDeluxe14]]4 10 02https://esolangs.org/w/index.php?diff=80753&oldid=79923 5* 03CatCatDeluxe 5* (+162) 10 > 1613432921 670843 PRIVMSG #esoteric :14[[07User:CatCatDeluxe14]]4 M10 02https://esolangs.org/w/index.php?diff=80754&oldid=80753 5* 03CatCatDeluxe 5* (+66) 10 > 1613432960 138688 PRIVMSG #esoteric :14[[07C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)14]]4 10 02https://esolangs.org/w/index.php?diff=80755&oldid=80752 5* 03CatCatDeluxe 5* (+64) 10 > 1613433037 155837 PRIVMSG #esoteric :14[[07C = theNextIntegerThatComesAfterAnotherIntegerWithTheValueOf(c)14]]4 10 02https://esolangs.org/w/index.php?diff=80756&oldid=80755 5* 03CatCatDeluxe 5* (+67) 10 < 1613433049 180834 :LKoen!~LKoen@96.252.88.92.rev.sfr.net QUIT :Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.” < 1613433412 371749 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric