< 1613433699 371718 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 246 seconds > 1613434287 836424 PRIVMSG #esoteric :14[[07Befunge14]]4 10 02https://esolangs.org/w/index.php?diff=80757&oldid=80726 5* 03Quintopia 5* (+38) 10quine 2 needs a lot of trailing spaces to be a true quine > 1613435331 446462 PRIVMSG #esoteric :14[[07Befunge14]]4 10 02https://esolangs.org/w/index.php?diff=80758&oldid=80757 5* 03Quintopia 5* (+191) 10/* Quine */ > 1613435871 454988 PRIVMSG #esoteric :14[[07Befunge14]]4 10 02https://esolangs.org/w/index.php?diff=80759&oldid=80758 5* 03Quintopia 5* (-44) 10/* Quine */ > 1613435904 512956 PRIVMSG #esoteric :14[[07Befunge14]]4 M10 02https://esolangs.org/w/index.php?diff=80760&oldid=80759 5* 03Quintopia 5* (-1) 10/* Quine */ > 1613436119 355102 PRIVMSG #esoteric :14[[07Befunge14]]4 M10 02https://esolangs.org/w/index.php?diff=80761&oldid=80760 5* 03Quintopia 5* (-2) 10/* Quine */ < 1613436693 492188 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613436896 912894 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Quit: metcalf < 1613436945 452883 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613437170 512346 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613437518 472272 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :zzo38: oh! I found the third root. "http://zzo38computer.org/sql/" < 1613437847 368720 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 JOIN :#esoteric < 1613438938 63247 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613439340 80932 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 265 seconds > 1613441552 723835 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80762&oldid=80749 5* 03Digital Hunter 5* (+906) 10/* Example programs */ added a phi calculator program > 1613441619 769410 PRIVMSG #esoteric :14[[07Parse this sic14]]4 M10 02https://esolangs.org/w/index.php?diff=80763&oldid=80762 5* 03Digital Hunter 5* (+0) 10/* Phi calculator */ < 1613442275 372363 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613442449 489635 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 QUIT :Quit: Leaving < 1613442519 375046 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 246 seconds < 1613442741 402087 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 264 seconds < 1613442811 838631 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1613445885 886706 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613445952 418496 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I figured out a solution that doesn't involve mapping over NULL: put the block of memory you're iterating over at 0x80000000 exactly, use 32-bit arithmetic on your 64-bit pointers (this zero-extends the top 32 bits but they're all zeroes anyway), and then the sign flag will contain bit 31 rather than bit 63 < 1613445971 302895 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so you know you've gone below the bottom of your block when the 8 borrows down to a 7 < 1613446000 378789 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(you can also do this the other way, counting upwards and making your memory block end at 0x7fffffff) < 1613446093 828567 :tromp_!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613446121 977534 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you could also use any address where bit 16 is a 1 and bits 15..0 are all zeroes, then use 16-bit arithmetic, but there are potential performance hazards with 16-bit arithmetic < 1613446141 857279 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :a false dependency probably wouldn't be too bad for this sort of application, but partial register merge stalls would be horrible < 1613446150 329646 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(also, it costs an extra byte) < 1613446372 791146 :tromp_!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 256 seconds < 1613446375 367878 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :b_jonas: There are some additional files too. What is your opinion about the format I mentioned for mirroring (that I linked the document that I wrote)? < 1613446430 287177 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(For transfer purposes, it may be helpful for the request and response to be compressed, too) < 1613446443 72585 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : fungot: in English, do people really pronounce "chassis" with the final "s" silent? if so, why? ← yes, they do, also the initial "ch" is pronounced "sh", and the "i" is pronounced as a long "e" < 1613446443 252772 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :ais523: a good choice, then i'm going to make mistaks so bad that they kill me, and a parallel! they're not writing stories about what life would be like, if only you made some decisions okay < 1613446488 509831 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :apparently it's a loanword from French (châssis), and English often borrows approximate pronunciations of loanwords < 1613446715 867396 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Yes, although some people pronounce some words differently, so sometimes there is more than one way in the dictionary < 1613446754 584004 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(Sometimes one way to pronounce it is only applicable to one meaning of the word) < 1613447077 910511 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ACTION vaguely wonders if loanwords ever get returned to their original languages < 1613447152 42004 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you're going to keep it, it's more like theft than borrowing < 1613447243 739275 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Many words are still used in their original languages, I think. < 1613447438 581938 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca QUIT :Remote host closed the connection < 1613447463 169446 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca JOIN :#esoteric < 1613447783 579938 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(Although, sometimes there are already good English words, sometimes the one that isn't so common now, though. And, sometimes, should have to make up the new word; sometimes no language has the suitable words already.) < 1613447990 151496 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1613448062 354379 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613448199 936947 :mmmattyx!uid17782@gateway/web/irccloud.com/x-urgxqrzuotzhrnhk QUIT :Quit: Connection closed for inactivity < 1613449307 30731 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1613449364 345190 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613449381 128495 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613449653 336365 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 264 seconds < 1613449802 188274 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1613449875 452234 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613452597 355008 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613452893 345194 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 264 seconds < 1613453147 456554 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 JOIN :#esoteric < 1613453250 379773 :olsner!~salparot@c83-249-186-43.bredband.comhem.se QUIT :Ping timeout: 246 seconds < 1613453641 507303 :olsner!~salparot@c83-249-186-43.bredband.comhem.se JOIN :#esoteric < 1613455342 349498 :scoofy!~scoofy@catv-89-135-21-225.catv.broadband.hu JOIN :#esoteric < 1613457807 510551 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I watched Murdoch Mysteries; they mentioned that the mathematician proved they could not solve the puzzle with the last two letters reversed (it is a puzzle like the 15 puzzle). But, they failed to consider, there are many duplicate letters. Is that deliberate? Did they know that is relevant? < 1613457965 323359 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Ping timeout: 240 seconds < 1613459465 324442 :sprock!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 240 seconds < 1613461260 348830 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613462697 899020 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: quit < 1613464076 68312 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1613465904 927017 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613466622 368322 :hendursa1!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613466725 831872 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds < 1613466789 323605 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613467194 159485 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1613467789 168866 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :Ping timeout: 265 seconds < 1613468148 634622 :LKoen!~LKoen@96.252.88.92.rev.sfr.net JOIN :#esoteric < 1613468287 127324 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1613474168 383397 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523 re mapping over NULL, I believe you have to pass the MAP_FIXED_NOREPLACE flag to the fourth arg of mmap, but that might not be enough. I thought there was a process-wide prctl setting that protects you from mapping to 0 address by default, but didn't require privilege to override. you might want to check sources of old versions of dosemu (or possibly other real mode emulators) that use virtual < 1613474174 650206 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :8086 mode under an x86_32 kernel, because I think that will map to the zero page. < 1613474339 132893 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :but I never really experimented with it, because I don't want a page mapped at zero address. < 1613474399 336164 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ah, fizzie found the solution < 1613474589 108224 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" maybe I should just use a %fs: prefix" => I think that's reserved for libc and similar to implement thread-local variables, so you have to be careful < 1613474646 162264 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" I don't even think there's an official piece of documentation anywhere for how you make a system call from userspace" => man 2 syscall mostly documents it. some details about connection with signal handlers might be undocumented for all I know < 1613474685 926520 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :but for the syscall numbers themselves, you have to look them up in the header or include the header < 1613474702 335663 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :and the ABI of some syscalls might not be documented, so you may have to look them up in libc source code < 1613474708 419997 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :it is documented for some of them < 1613474792 601860 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613474816 407626 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I assume you already know that, rather than using the counter as an index, incrementing both the counter and pointers in two/three/four separate registers is often the best, and you're just doing weird golf here < 1613474865 841089 :hendursa1!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds < 1613475069 69480 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ah I see, the following conversation details how the fs and gs segment descriptors are used on x86_64. < 1613475073 973897 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I didn't know most of that. < 1613475108 906875 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I didn't even know that you can use _both_ fs and gs, with nontrivial effect, on x86_64. I thought only one of them was available. < 1613475403 443531 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu 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)" => it won't, or at least there's a certain undefined instruction that is used to always trigger an error and so won't be assigned meaning, because gcc emits it in some cases for abort() or less optimized unreachable paths < 1613475438 208582 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :but there are plenty of system mode only instructions that will raise privilage faults, and so can be used to assign some meaning. < 1613475540 755 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :plus there's also syscall and int and int 3 all those things for when you want to assign meaning to an instruction that will be handled by either the kernel or a signal handler, plus you can use an access to an invalid address or other faults < 1613476027 356102 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :zzo38: I'm not sure it's useful to define a mirror protocol from your side. you just use the protocol by archive.org or debian or github or MS Onedrive or Google Drive, because they're the ones with the warehouses full of hard disks and mirroring stuff from you. < 1613476962 823829 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613479985 179675 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :Read error: Connection reset by peer < 1613480005 372313 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric > 1613480096 545754 PRIVMSG #esoteric :14[[07Imeight14]]4 10 02https://esolangs.org/w/index.php?diff=80764&oldid=78625 5* 03Kekcsi 5* (+500) 10added details < 1613481127 964268 :ArthurStrong!~ArthurStr@178-133-168-104.mobile.vf-ua.net JOIN :#esoteric < 1613481159 376381 :spruit11!~unknown@86-82-44-193.fixed.kpn.net QUIT :Ping timeout: 246 seconds < 1613481418 173485 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613481526 346730 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613481792 378270 :arseniiv!~arseniiv@136.169.205.6 JOIN :#esoteric < 1613482029 172717 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 QUIT :Read error: Connection reset by peer < 1613482049 371256 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 JOIN :#esoteric < 1613482615 645810 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613482794 117381 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613485243 337939 :spruit11!~unknown@86-82-44-193.fixed.kpn.net JOIN :#esoteric < 1613486113 838918 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds < 1613487309 971981 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1613489330 842025 :razetime!31cfdc5c@49.207.220.92 JOIN :#esoteric < 1613489510 253739 :razetime!31cfdc5c@49.207.220.92 PRIVMSG #esoteric :beer < 1613489984 228103 :ArthurStrong!~ArthurStr@178-133-168-104.mobile.vf-ua.net QUIT :Quit: leaving < 1613490441 91463 :razetime!31cfdc5c@49.207.220.92 QUIT :Quit: Connection closed < 1613490955 234361 :spruit11!~unknown@86-82-44-193.fixed.kpn.net QUIT :Read error: Connection reset by peer < 1613490981 911939 :spruit11!~unknown@86-82-44-193.fixed.kpn.net JOIN :#esoteric < 1613493381 388108 :Melvar!~melvar@dslb-088-070-039-190.088.070.pools.vodafone-ip.de QUIT :Ping timeout: 246 seconds < 1613494349 354331 :Melvar!~melvar@dslb-088-070-039-190.088.070.pools.vodafone-ip.de JOIN :#esoteric < 1613494830 418580 :arseniiv!~arseniiv@136.169.205.6 QUIT :Ping timeout: 246 seconds < 1613496088 358381 :arseniiv!~arseniiv@136.169.205.6 JOIN :#esoteric < 1613498076 347045 :arseniiv!~arseniiv@136.169.205.6 QUIT :Ping timeout: 240 seconds < 1613498777 392128 :arseniiv!~arseniiv@136.169.205.6 JOIN :#esoteric < 1613499359 949728 :TheLie!~TheLie@business-24-134-17-157.pool2.vodafone-ip.de JOIN :#esoteric < 1613499373 96756 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613499915 920092 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613501255 308085 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613502148 438171 :xelxebar_!~xelxebar@gateway/tor-sasl/xelxebar QUIT :Remote host closed the connection < 1613502167 863456 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar JOIN :#esoteric < 1613502811 370002 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613502833 181888 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: yes, this is definitely well into "weird golf" territory, this sort of thing would be insane to do for other reasons < 1613502855 812573 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I am basically planning to define my own ABI for the program, and am not using libc < 1613502886 866967 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(even so, you have to turn off gcc stack protectors because they assume that %fs:(0x28) is a piece of thread-local storage not used by anything else) < 1613503233 216050 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613503656 197744 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: yes. that gets difficult. < 1613503682 681375 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm entirely willing to write this completely in asm if necessary < 1613503700 359103 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :currently torn about whether the non-performance-sensitive parts should be in asm or in C < 1613503727 146625 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :gcc lets you reserve a register for your own use program-wide, which is pretty useful for defining your own ABIs (it does, however, spout warnings if library functions overwrite it) < 1613503827 427865 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :"gcc lets you reserve a register for your own use program-wide" => I wonder for what architecture they added that < 1613503828 108729 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613503842 373734 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613503905 896775 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I think it's for people doing very low level high-performance asm stuff where they want to keep global variables in registers < 1613503975 27616 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: sorry for my connection < 1613503987 911459 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613504020 617881 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: but keeping a global variable constantly in a register is weird, even for a high-performance asm stuff. keeping a global variable in a register temporarily during a function or hot loop, that makes sense, but ordinary compiler optimizations can already do that. < 1613504070 423416 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :and doing it locally has much fewer problems with ABI compatibility < 1613504103 744816 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: there are some platforms where the number of registers is large compared to the size of RAM < 1613504138 272892 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and some algorithms where you don't want to touch memory at all < 1613504304 584644 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :really, having a large number of global variables is normally an issue with your program in the first place, and if you have only a small number, keeping them in registers might make sense depending on how widely they're used < 1613504343 320342 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I actually ran into a problem like this in aimake – its C output contains a lot of functions that call each other, and gcc seems unwilling to change the ABI of a function that isn't inlined < 1613504364 455485 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: number of registers is large => MMIX is one of them, 6502 may be one if you count the zero-page bytes as registers. maybe x86_64 with AVX512 and its 32 vector registers could count as one, but the problem is, you can't guarantee that they're preserved through callers < 1613504374 957368 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it would make sense for all the internal state of the parsing automaton to be in global variables for just that source file < 1613504384 888685 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which I think could be accomplished via that gcc feature < 1613504386 238661 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :"some algorithms where you don't want to touch memory at all" => in a hot loop. not in a whole program. < 1613504421 707634 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :some registers, like %r14, are hardly ever used as it is < 1613504454 672020 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613504470 840120 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, I was thinking of the PIC microcontrollers, which normally have around 100 or so bytes of registers, and often fewer bytes of general-purpose memory (40 or so) < 1613504489 400683 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the documentation goes into a lot of detail on what registers you can use as extra memory under which circumstances < 1613504529 727704 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(the whole purpose of the PIC is to have a lot of register-mapped hardware available, so most of the registers have side effects when read and/or written) < 1613504633 549802 :sprock!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1613504651 610871 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: re parsing, just put that internal state to the first argument (or first few arguments) of all your function, then the ABI will force them to be in registers (%rdi then %rsi for linux, or %xmm0 then %xmm1 depending on type), at least in the boundaries of those functions. whether it's a C function argument or a C++ *this argument is mostly irrelevant. < 1613504665 873730 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613504680 762667 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :what's the syntax for globally reserving a register in GCC? < 1613504681 764579 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: that was my first idea, but C isn't call-by-name and much of the internal state is writable < 1613504709 885764 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :kmc: register type varname asm("registername"); < 1613504717 929303 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ok < 1613504722 219974 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: hmm, so you want to return the modified state in the same register? that might be harder, yes. < 1613504737 510570 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :I think GHC's old C backend used that < 1613504764 649334 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I guess you could write a specialized backend to the parser generator that writes x86_64 assembly directly < 1613504791 334097 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I was working on that but stalled on it < 1613504860 580980 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :there were actually two flavors of the C backend, "registerized" and "unregisterized" < 1613504907 945512 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: I also have a hard time imagining that this parser register thing is an optimization that will solve an actual bottleneck < 1613504911 581702 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :the unregisterized backend outputted something reasonably close to standard C, and was good for portability, but bad for performance < 1613504929 411464 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :among other things it used a "mini interpreter" for computed tail calls < 1613504955 37668 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I would imagine that the bottlenecks on parsing would be one of L1 read, L1 write, instruction decode, or instruction issue < 1613504974 874153 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and putting the important parser variables into registers would seem to reduce pressure on all four of those? < 1613505000 716255 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :something like void *(*f)(); while (1) { f = f(); } < 1613505035 485824 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :so a computed tail call / jump (which are the main ubiquitous form of control flow in compiled haskell code) compiled to a return and a call, which is not very efficient < 1613505046 677194 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :of course, the *real* bottleneck is probably reading the file that stores the information you're parsing, it wouldn't help with that bottleneck at all < 1613505063 733634 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :then there was the registerized backend, which output horribly GCC-dependent code and mangled the resulting assembly further with a huge perl script < 1613505069 112753 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :and was only ever implemented for a few architectures < 1613505089 586521 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :kmc: it's not that inefficient (2-3 clock cycles on most processors) unless mispredicted < 1613505091 272794 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :in that case the advantage of producing C was not portability but rather the ability to use GCC codegen and optimizations < 1613505116 141708 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ais523: well, it may have been worse in the early days when this was first implemented < 1613505120 598346 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but an unconditional jump costs ¼ of a clock cycle, so is faster < 1613505129 982552 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(assuming that you don't space them too tightly) < 1613505195 101439 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :what do you mean by 1/4 of a clock cycle? i can see that being meaningful for arithmetic (if you can execute 4 instructions at once) but how does it work for control flow < 1613505231 748658 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :kmc: on Intel processors, there are four main execution units for arithmetic, etc., 0, 1, 5, and 6 (AMD processors also have four but they're named differently) < 1613505241 63756 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :each can handle a subset of instructions < 1613505267 733493 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :jumps tie up port 6 for a cycle, probably so that they can be reversed if they turn out to have been mispredicted < 1613505286 764609 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(6 is also usable for very basic arithmetic/logic, things like adds and xors) < 1613505287 968659 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: dunno. maybe. < 1613505307 808151 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: there is probably at least some esoteric valid optimization use for this global register thing < 1613505323 992465 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and everything else about a jump happens in parallel with your arithmetic and logic, so it costs no time at all as long as jumps aren't too densely packed as it isn't on the critical path of the processor < 1613505324 776722 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ok < 1613505342 952870 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :jumps also cost one instruction issue and one instruction retire, but Intel processors handle those at the rate of 4 per cycle < 1613505365 158156 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so it's taking up almost exactly ¼ of the resources that you get each clock cycle < 1613505381 35759 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :/away for a little while < 1613505383 873556 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ok < 1613505457 167763 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613505506 324469 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :if the code is execution bound that is. < 1613505904 170838 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :back < 1613505942 877673 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: it's actually close to theoretically impossible for code to be execution bound in general, on modern processors < 1613505976 88046 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it can only really happen in the case of instructions that take multiple clock cycles and can't be pipelined < 1613505979 278958 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :like division < 1613506007 932571 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in other cases, it's impossible to feed instructions into the execution units faster than the execution units can process them < 1613506029 132942 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can get a sort-of execution-bound when your code is trying to use one particular execution unit more than it can manage, though < 1613506053 797111 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(e.g. recent Intel processors can only run vector shuffle operations on port 5, so your code will be execution-bound if it's trying to do those at a rate of more than one per cycle) < 1613506113 218487 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :"close to theoretically impossible for code to be execution bound in general" => yes. < 1613506141 518227 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in AMD processors, the rest of the pipeline is faster compared to Intel processors, so those are more likely to become execution bound < 1613506149 673140 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ACTION wonders how they ended up named 0, 1, 5, and 6 < 1613506159 506245 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613506180 553722 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :it's like the old prank with the 3 pigs labeled "1", "2", and "4" < 1613506187 701971 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. if you write a few thousand register-register integer addition instructions in a row, that will be execution-bound because there are only four adders available and yet the rest of the pipeline could handle six addition instructions per cycle < 1613506196 718419 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :kmc: 2, 3, 4, 7 also exist but aren't ALUs < 1613506227 529421 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :2 and 3 are used for memory read operations (read-modify instructions will use both 2 or 3, and one of 0/1/5/6, simultaneously) < 1613506240 436686 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :4 is used for all memory writes (so you can only write memory once per clock cycle) < 1613506254 885243 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and 7 is an address generation unit for writes < 1613506258 875911 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ah < 1613506264 326078 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but what confuses me is that 7 isn't *always* used for writes, even though it can't do anything else < 1613506273 255283 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :does that mean LEA-arithmetic happens on 7? < 1613506279 456582 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :sometimes writes will borrow the AGU from port 2 or 3 < 1613506280 852438 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :that sounds contradictory < 1613506301 329699 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :LEA-arithmetic has varied on how it's done from processor to processor, but most modern processors do it on an ALU rather than an AGU < 1613506308 890291 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so that the AGUs don't need to be told how to write registers < 1613506312 852714 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :mm < 1613506370 227051 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :(my wife says someone actually did the thing with the pigs at her high school) < 1613506374 32142 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it looks like on recent Intel complex LEAs need to be done on port 1, simpler LEAs can be done on port 1 or 5 < 1613506377 131446 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :(this is what happens when you grow up in farm country?) < 1613506451 749400 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm never sure what counts as a complex LEA, but suspect it's something like index + base + displacement all being specified < 1613506491 969900 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also, RIP-relative addresses are "slow" on modern processors for some reason, they tend to require complex-AGU resources even though they're conceptually quite simple < 1613506504 761811 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(e.g. needing to go via port 1 for RIP-relative LEAs) < 1613506529 790823 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :probably the difficulty is in how %rip itself gets routed, because it isn't register-renamed like most registers are < 1613506734 217076 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ah yes, "slow" < 1613506751 208410 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :as in as slow as a double indexing < 1613506864 785908 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, I think I figured out why memory writes can use the AGU from port 2 or 3 < 1613506881 732839 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's so that if there's a read-modify-write instruction, the read and write use the same AGU as each other < 1613506928 849668 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it also wouldn't surprise me if port 7 were a recent addition, and if earlier processors just used 2 and 3 as the only AGUs available < 1613506960 99600 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613507179 798601 :TheLie!~TheLie@business-24-134-17-157.pool2.vodafone-ip.de QUIT :Remote host closed the connection < 1613507414 909666 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I don't follow all the details of the execution units. the practical effect is that it's often worth to interleave simple operations if they don't have dependencies either way. which is also why incrementing two pointers in parallel can be better than indexing, and the pointer compare-and-jump can go parallel with the computation. < 1613507524 158725 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :so in practice in those kinds of tight loops you want to optimize for decoder and decoded cache, after of course you arrange multiple loops to operate on nice L1-cache-sized chunks so the L2 cache doesn't bind you < 1613507643 661941 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :modeling the different execution units in detail rarely helps you. the execution latencies of the instructions do matter, but which execution units they can run on rarely does. < 1613507668 775435 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :unless you're writing a BLAS. < 1613507714 974588 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :interleaving doesn't help as much as you might think, because of how the reorder buffer works < 1613507729 271026 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what you do need to do is to keep the loop-carried-dependency chain as short as possible, though < 1613507770 581801 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because that will often be the limiting factor on how fast a loop can run < 1613507785 352696 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: do you mean the order you write the interleaved instructions doesn't matter as much? yes. < 1613507815 354 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: right, the order of instructions is mostly irrelevant on out-of-order processors (which includes most modern processors apart from intentionally low-power-usage ones) < 1613507834 491505 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :yes, that makes sense < 1613507835 948199 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :they can be moved quite some distance (tens of instructions) in order to get them to run as early as possible < 1613507849 239191 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I've discovered that the main effect from moving instructions round is to decrease register pressure < 1613507885 518954 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you have a temporary register that you need only for the course of a few instructions, it works best to put those instructions right next to each other so that the same register name can be reused as a temporary in a different block of instructions < 1613507892 425984 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :rather than needing to keep it live < 1613507900 566911 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613507989 9726 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: yes, that can allow shorter instr encodings. < 1613508180 899942 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or in extreme cases, avoid spills < 1613508711 722621 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613509576 869081 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613510851 406850 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613512604 64422 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613513055 110376 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613517771 925200 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613519622 577828 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613519663 216142 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu QUIT :Quit: Lost terminal < 1613519885 415567 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613519999 473906 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 QUIT :Quit: Leaving