< 1756686703 985631 :amby!~ambylastn@host-78-151-24-148.as13285.net QUIT :Remote host closed the connection > 1756693215 399538 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03SzszszszszszszsZ 5* 10uploaded "[[02File:Onecompiler stdin.png10]]": OneCompiler's stdin box, as opposed to interactive consoles < 1756695410 939239 :visilii_!~visilii@85.94.26.33 QUIT :Ping timeout: 258 seconds < 1756697557 442029 :sprout!~sprout@2a02-a448-3a80-0-c61c-b515-5509-58e7.fixed6.kpn.net QUIT :Ping timeout: 260 seconds < 1756697589 56478 :sprout!~sprout@84-80-106-227.fixed.kpn.net JOIN #esolangs sprout :sprout < 1756699793 66180 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1756700063 481201 :visilii!~visilii@85.94.26.33 JOIN #esolangs * :ZNC - https://znc.in < 1756708702 132502 :visilii!~visilii@85.94.26.33 QUIT :Read error: Connection reset by peer < 1756708708 612130 :visilii_!~visilii@85.94.26.33 JOIN #esolangs * :ZNC - https://znc.in < 1756709907 689608 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c JOIN #esolangs * :Textual User < 1756713555 91954 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas < 1756714790 337880 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"you need something like call/cc to interact with the world outside the stack" => I was thinking about this because of Consumer Society, and what I figured that you can restrict the system interaction functions to work only when the data stack is empty, or when the call stack is empty, or even both, but in the latter two cases the system < 1756714790 838235 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :interaction functions need to use continuation passing style so they can call back to your code after they're done, sort of like in Haskell IO. but I don't know how much of that applies to Underload. < 1756715094 533967 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the problem is that if you want something like Haskell IO, your code effectively returns an algebraic data type that tells what system function to call, plus its arguments including one or more continuation arguments. but if you want to do that in something like pure untyped lambda calculus, then you'd represent the algebraic data type with a < 1756715095 36254 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :simple function (a Church-encoding or whatever it's called), and then that function has the potential to run your code in the system's space. < 1756715121 112394 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :Underload would be similar but worse, because you can mess with the data stack < 1756715251 480911 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :admittedly this is sort of a problem with Consumer Society too, you have to make your code behave properly or else it can mess up the system < 1756717060 637026 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :uh, I think I've replied to some old messages from the log > 1756718297 273721 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03CanonNi 5* 10New user account > 1756718387 378461 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=164232&oldid=164203 5* 03CanonNi 5* (+195) 10hi < 1756720271 205404 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer > 1756723619 982486 PRIVMSG #esolangs :14[[07Brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=164233&oldid=164217 5* 03HungKhanh0106 5* (+0) 10/* Batchfile interpreters */ changed link for own impl < 1756724740 584495 :amby!~ambylastn@host-78-151-24-148.as13285.net JOIN #esolangs amby :realname < 1756725069 424884 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1756725961 308143 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c JOIN #esolangs * :Textual User < 1756726046 989625 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 258 seconds < 1756726102 616433 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord > 1756726887 387221 PRIVMSG #esolangs :14[[07LPTA14]]4 10 02https://esolangs.org/w/index.php?diff=164234&oldid=164223 5* 03I am islptng 5* (+678) 10 > 1756727542 461494 PRIVMSG #esolangs :14[[07LPTA14]]4 10 02https://esolangs.org/w/index.php?diff=164235&oldid=164234 5* 03I am islptng 5* (+515) 10 < 1756727863 672518 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1756728461 574722 :APic!apic@apic.name PRIVMSG #esolangs :Hi < 1756728545 93991 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Ping timeout: 250 seconds < 1756731151 914495 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c JOIN #esolangs * :Textual User < 1756732480 69096 :Lykaina!~lykaina@user/lykaina JOIN #esolangs Lykaina :Lykaina < 1756733489 785989 :bongino!~bongino@user/bongino JOIN #esolangs bongino :bongino < 1756733791 525824 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1756734447 225546 :bongino!~bongino@user/bongino QUIT :Quit: leaving < 1756734464 978910 :bongino!~bongino@user/bongino JOIN #esolangs bongino :bongino < 1756736842 504980 :molson_!~molson@24-124-54-137-dynamic.midco.net JOIN #esolangs molson :realname < 1756736858 240506 :molson!~molson@24-124-54-137-dynamic.midco.net QUIT :Ping timeout: 256 seconds < 1756737334 238451 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca QUIT :Ping timeout: 256 seconds < 1756737750 149288 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1756737790 100155 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : uh, I think I've replied to some old messages from the log ← I think that too, but it isn't necessarily a bad thing – I can remember enough of the old conversation for it to be reasonable to continue it < 1756737804 238225 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although I guess the ideal would be to link to the previous part of the conversation so that people can refresh their memory) < 1756738311 895070 :bongino!~bongino@user/bongino PRIVMSG #esolangs :HackEso: logs ais523 < 1756738329 597956 :bongino!~bongino@user/bongino PRIVMSG #esolangs :i forgot < 1756738335 41858 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the logs are linked from the topic but I don't think we have a bot that reads them < 1756738344 687531 :bongino!~bongino@user/bongino PRIVMSG #esolangs :we have < 1756738368 184248 :bongino!~bongino@user/bongino PRIVMSG #esolangs : i mean. it certainly is expandable. < 1756738368 425294 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :HackEgo used to be able to read them a long time ago but I think that changed for some reason, I'm not sure if its replacement HackEso was ever updated to do that < 1756738381 570080 :bongino!~bongino@user/bongino PRIVMSG #esolangs :oh < 1756738479 421479 :bongino!~bongino@user/bongino PRIVMSG #esolangs :hm. but the website logs still work. one could link from/to website in case of teambacklogging event :p < 1756738505 942988 :bongino!~bongino@user/bongino PRIVMSG #esolangs :is hackeso still hackable < 1756738551 778553 :bongino!~bongino@user/bongino PRIVMSG #esolangs :HackEso: ^ls / < 1756738560 328681 :bongino!~bongino@user/bongino PRIVMSG #esolangs :HackEso: help < 1756738572 244286 :bongino!~bongino@user/bongino PRIVMSG #esolangs :its been a while really < 1756738620 695463 :bongino!~bongino@user/bongino PRIVMSG #esolangs :ah. now i read you. < 1756738642 669814 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`ls / < 1756738645 878997 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :bin \ dev \ etc \ hackenv \ lib \ lib64 \ proc \ sbin \ sys \ tmp \ usr < 1756738662 103694 :bongino!~bongino@user/bongino PRIVMSG #esolangs :thanks < 1756739800 988120 :bongino!~bongino@user/bongino QUIT :Ping timeout: 258 seconds < 1756740055 233054 :molson_!~molson@24-124-54-137-dynamic.midco.net QUIT :Quit: Leaving < 1756740950 538532 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :`ls -l ~/ < 1756740952 670509 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :ls: invalid option -- ' ' \ Try 'ls --help' for more information. < 1756740969 88861 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :`ls ~/ < 1756740971 140730 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :ls: cannot access '~/': No such file or directory < 1756740978 484406 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :`ls -l / < 1756740979 995673 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :ls: invalid option -- ' ' \ Try 'ls --help' for more information. < 1756741016 411816 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :`pwd < 1756741017 638175 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​/hackenv/tmp < 1756741186 946199 :molson!~molson@24-124-54-137-dynamic.midco.net JOIN #esolangs molson :realname < 1756741341 400943 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :``ls -l / < 1756741342 369570 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​`ls? No such file or directory < 1756741347 842292 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`` ls -l / < 1756741349 554236 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :total 24 \ drwxr-xr-x 2 0 0 4096 Jul 1 2024 bin \ drwxr-xr-x 7 0 0 440 Jul 1 2024 dev \ drwxr-xr-x 3 0 0 0 Sep 1 15:42 etc \ drwxr-xr-x 22 1000 1000 4096 Dec 11 2021 hackenv \ drwxr-xr-x 10 0 0 4096 Nov 17 2019 lib \ drwxr-xr-x 2 0 0 4096 Jul 1 2024 lib64 \ dr-xr-xr-x 34 0 0 0 Sep 1 15:42 proc \ drwxr-xr-x 2 0 0 4096 Jul 1 2024 sbin \ dr-xr-xr-x 11 0 0 0 Sep 1 15:42 sys \ drwxrwxrw < 1756741356 549113 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there we go, that's how you give commands multiple arguments < 1756741570 248998 :Lykaina!~lykaina@user/lykaina PRIVMSG #esolangs :`` ls -F < 1756741572 463193 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​🌱* \ 3 \ a.o \ a.out* \ asmbf-1.2.7/ \ banana.txt \ bef2* \ bfi* \ bin/ \ Burlesque/ \ canary \ cmd.whatis \ compiled_brachylog.pl \ detect* \ detect.c \ egel-master/ \ egel-scripts/ \ egel.zip \ eGtbSgN68aHU \ fence.c \ foo \ he-ng.7z \ he-ng.7z.base64 \ he-ngc* \ he-ngx* \ hlu* \ JoaoDir/ \ just \ karma \ le@ \ nonoodl* \ olist.new* \ output.b \ paste/ \ pd* \ pd.c \ perlV \ pg* \ pg.cxx \ pikhqbow_tst* \ program* \ -.s \ spline \ spout \ sra* \ sr < 1756741987 903921 :Lykaina!~lykaina@user/lykaina QUIT :Quit: Leaving < 1756742240 118182 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`learn The password of the month is Myosotis. < 1756742244 270519 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :Relearned 'password': The password of the month is Myosotis. < 1756742322 132667 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm still not entirely sure why we even have a password of the month < 1756742375 398976 :int-e!~noone@int-e.eu PRIVMSG #esolangs :It's traditional. :P < 1756742468 676049 :int-e!~noone@int-e.eu PRIVMSG #esolangs :also, these days, a test whether HackEso's repo functionality still works < 1756742472 393461 :int-e!~noone@int-e.eu PRIVMSG #esolangs :because it's hardly used < 1756742498 497307 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Anyway. It serves no real purpose, it really is just something we've mostly kept up for the past 10 years. < 1756742617 612214 :int-e!~noone@int-e.eu PRIVMSG #esolangs :where "we" is mostly b_jonas and I these days; oerjan and shachaf were prolific potm-ers earlier on. < 1756743343 503925 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c JOIN #esolangs * :Textual User < 1756743967 210863 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1756744205 726637 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03 5* 10New user account > 1756744739 94543 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=164236&oldid=164232 5* 03 5* (+310) 10 > 1756744741 148037 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=164237&oldid=164236 5* 03 5* (+0) 10 < 1756745969 991316 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c JOIN #esolangs * :Textual User < 1756746557 876658 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :oh yeah, I meant to change that < 1756746623 961509 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I'm stupid, I always forget < 1756746652 390744 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I even checked tom7's blog (radar), which is the other thing I want to do on the internet at the start of each month < 1756746697 499730 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :`? log < 1756746699 438427 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​#esoteric channel logs: https://esolangs.org/logs/ http://tunes.org/~nef/logs/esoteric/?C=M;O=D http://codu.org/logs/_esoteric/ https://github.com/KrzysztofSzewczyk/esologs/ < 1756746827 324843 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :well there are large gaps when nobody changed the password, but sure, "mostly kept up" is probably right < 1756746872 573384 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: you might actually get a small giggle out of https://en.wikipedia.org/wiki/Myosotis (unless you know what that is) < 1756747038 949418 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`` du -sh . < 1756747040 498274 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :43M . < 1756747412 127465 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :int-e: whoa, it's the password of the month! < 1756747435 653381 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I don't look at IRC nearly as much these days. < 1756747503 453917 :int-e!~noone@int-e.eu PRIVMSG #esolangs :that seems to happen a lot < 1756747643 369892 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I'm on the other side of the Atlantic now, though. Maybe that puts me in the channel's time zone. < 1756748427 726157 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`as-encoding jrcxz 1f; 1f: nop < 1756748429 922628 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​{standard input}: Assembler messages: \ {standard input}:1: Error: junk at end of line, first unrecognized character is `1' \ {standard input}: Error: local label `"1" (instance number 1 of a fb label)' is not defined < 1756748442 680574 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`as-encoding jrcxz 1f; 1: nop < 1756748444 258160 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :e3 00: jrcxz 0x2 \ 90: nop < 1756748477 223855 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`as-encoding jecxz 1f; 1: nop < 1756748478 542376 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :67 e3 00: jecxz 0x3 \ 90: nop < 1756748496 164243 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, weird use of prefixes < 1756748498 626228 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`as-encoding jcxz 1f; 1: nop < 1756748499 594236 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​{standard input}: Assembler messages: \ {standard input}:1: Error: `jcxz' is not supported in 64-bit mode < 1756748517 698570 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it would have been too silly for that one to work with a 66 prefix… < 1756749451 489036 :int-e!~noone@int-e.eu PRIVMSG #esolangs :yeah, "not encodable" according to Intel < 1756749616 118666 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1756749779 533887 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm, it is interesting that it uses the address size prefix. < 1756749919 604980 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if it used the data size prefix the default size would be 32, with prefixes for 64 and 16 < 1756749963 277085 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess AMD wanted the default to be 64 so they used the address size logic? < 1756750136 339793 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca JOIN #esolangs zzo38 :zzo38 < 1756750308 829425 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Well, the choice was made by intel when they added the 32 bit mode with i386. I guess they wanted the default to be 32 bits in 32 bit mode. < 1756750326 788639 :int-e!~noone@int-e.eu PRIVMSG #esolangs :err < 1756750346 498658 :int-e!~noone@int-e.eu PRIVMSG #esolangs :intel could've picked either prefix at the time, it was arbitrary < 1756750358 932794 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah right, a 67 prefix in 32-bit code means a 16-bit cx? < 1756750374 768993 :int-e!~noone@int-e.eu PRIVMSG #esolangs :yeah < 1756750429 881990 :int-e!~noone@int-e.eu PRIVMSG #esolangs :AMD could've picked a different prefix for 64 bit mode but it makes sense that they didn't < 1756750442 278265 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, they probably want to reuse the decoder circuit < 1756750452 498906 :int-e!~noone@int-e.eu PRIVMSG #esolangs :it's not like jrcxz is even used much. < 1756750463 720425 :int-e!~noone@int-e.eu PRIVMSG #esolangs :or jecxz < 1756750467 517288 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Remote host closed the connection < 1756750521 193182 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1756750551 692340 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right – Intel suggest that it can be used at the start of a loop to skip past the end if the iteration count is 0 < 1756750594 442282 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I think most modern compilers don't even bother trying to put the count into cx (perhaps they might use the instruction if it happens to be in cx naturally though?) < 1756750709 793577 :int-e!~noone@int-e.eu PRIVMSG #esolangs :What's the current state of these instructions (jcxz/loop*) being microcoded? < 1756750732 388916 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(And thus, slow) < 1756750850 744254 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c JOIN #esolangs * :Textual User < 1756750896 526453 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I believe jrcxz is fast but loop is microcoded < 1756750948 261340 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the reason is that if loop pagefaults on loading in the jump target, the processor doesn't have an easy way to rewind the decrement of rcx, and yet it has to rewind the decrement so that the instruction can be retried after paging the jump target in < 1756750974 769912 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :dec rcx; jnz doesn't have that problem because it can just leave the IP between the dec and the jnz, even though it parses it as a single instruction < 1756751138 115128 :int-e!~noone@int-e.eu PRIVMSG #esolangs :apparently the answer is... fast on AMD, slow on Intel, though j*cxz is only 2 micro-ops compared to 7 for loop and over 10 for loop(n)e < 1756751175 201204 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1756751185 934636 :int-e!~noone@int-e.eu PRIVMSG #esolangs :dec rcx interferes with adcx/adox < 1756751425 529431 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(source: Agner's latency table from https://www.agner.org/optimize/) < 1756751940 371133 :int-e!~noone@int-e.eu PRIVMSG #esolangs :https://stackoverflow.com/questions/35742570/why-is-the-loop-instruction-slow-couldnt-intel-have-implemented-it-efficiently is interesting too. > 1756752525 842244 PRIVMSG #esolangs :14[[07Che14]]4 10 02https://esolangs.org/w/index.php?diff=164238&oldid=122359 5* 03Cameron 5* (+30) 10Made an interpreter > 1756752557 32588 PRIVMSG #esolangs :14[[07Che14]]4 M10 02https://esolangs.org/w/index.php?diff=164239&oldid=164238 5* 03Cameron 5* (-2) 10Messed up formatting < 1756752592 937151 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname > 1756752636 44327 PRIVMSG #esolangs :14[[07Che14]]4 M10 02https://esolangs.org/w/index.php?diff=164240&oldid=164239 5* 03Cameron 5* (-2) 10Added correct tag < 1756754366 582614 :lynndotpy60!~rootcanal@134.122.123.70 JOIN #esolangs lynndotpy :lynn < 1756754368 164879 :j4cbo_!sid186930@id-186930.helmsley.irccloud.com JOIN #esolangs j4cbo :j4cbo < 1756754393 685924 :strerror_r!~strerror@user/strerror JOIN #esolangs strerror :ZNC - https://znc.in < 1756754460 371102 :j4cbo!sid186930@id-186930.helmsley.irccloud.com QUIT :Ping timeout: 248 seconds < 1756754460 556440 :myname!~myname@152.53.22.209 QUIT :Ping timeout: 248 seconds < 1756754460 723684 :lynndotpy6!~rootcanal@134.122.123.70 QUIT :Read error: Connection reset by peer < 1756754461 755784 :strerror!~strerror@user/strerror QUIT :Ping timeout: 248 seconds < 1756754461 841114 :FireFly!~firefly@glowbum/gluehwuermchen/firefly QUIT :Ping timeout: 248 seconds < 1756754462 97981 :j4cbo_!sid186930@id-186930.helmsley.irccloud.com NICK :j4cbo < 1756754462 565778 :lynndotpy60!~rootcanal@134.122.123.70 NICK :lynndotpy6 < 1756754483 871139 :FireFly!~firefly@glowbum/gluehwuermchen/firefly JOIN #esolangs FireFly :firefly < 1756754549 930535 :myname!~myname@152.53.22.209 JOIN #esolangs * :myname < 1756756665 536132 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"pagefaults on loading in the jump target" => sorry what? it's always a short jump with the relative offset in the instruction itself. there's no variant where the jump target is loaded from memory. < 1756756748 466674 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I can believe that it's a slow instruction, but not because of that < 1756757022 609564 :visilii_!~visilii@85.94.26.33 QUIT :Ping timeout: 260 seconds < 1756757050 979579 :visilii!~visilii@85.94.26.33 JOIN #esolangs * :ZNC - https://znc.in < 1756757693 116392 :visilii!~visilii@85.94.26.33 QUIT :Read error: Connection reset by peer < 1756757718 528951 :visilii!~visilii@85.94.26.33 JOIN #esolangs * :ZNC - https://znc.in < 1756757752 604569 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1756757799 784653 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: Yeah, I don't understand that either; those faults would occur when trying to fetch the next instruction after the `loop` has completed and the instruction pointer has been updated. < 1756757801 11861 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: the page containing the code that you're trying to might have been paged out < 1756757818 562786 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* trying to jump to < 1756757859 29258 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe I was misinformed, or maybe there's a reason the processor couldn't jump and then subsequently fault < 1756757907 380634 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Or does the GP actually happen *before* IP is updated? < 1756757921 125734 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the documentation says that there's a #GP if the jump target is an impossible address, but doesn't specify a #PF if it's paged out < 1756757927 577406 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(LOOP is actually documented to be able to cause a #GP) < 1756757955 994451 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, I was looking at JRCXZ < 1756757982 384052 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But that *shouldn't* cause an issue either; the limits in question are all available right away, while LOOP executes. < 1756757989 503420 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but LOOP is the same, #GP if the address is not of a valid form for a code pointer, such as being above the last legal virtual address < 1756758031 359687 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that's different from a #PF < 1756758092 843375 :int-e!~noone@int-e.eu PRIVMSG #esolangs :What else is there... hardware interrupts? Surely those can wait until after the instruction is done. < 1756758161 856982 :int-e!~noone@int-e.eu PRIVMSG #esolangs :TBF, the #GP issue is thorny enough; it means you can't simply treat this as decrement CX followed by a conditional jump internally. < 1756758181 182147 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the first answer on the page you linked earlier implies that after a successful jump and subsequent #PF, the processor doesn't know whether cx has already been incremented or not < 1756758194 618887 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :presumably some sort of race condition due to all the pipelining < 1756758215 457319 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I think the #PF claim is bogus. < 1756758242 209482 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Or maybe specific to whatever i386 did to handle the related GP issue. < 1756758273 869925 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the second answer claims they made it slow intentionally, and speculates about the reasons < 1756758317 788405 :int-e!~noone@int-e.eu PRIVMSG #esolangs :The co-evolution of ISA and compilers that is also mentioned is certainly is a factor. < 1756758524 756004 :visilii!~visilii@85.94.26.33 QUIT :Read error: Connection reset by peer < 1756758637 983440 :visilii!~visilii@85.94.26.33 JOIN #esolangs * :ZNC - https://znc.in < 1756758799 540126 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :whoa, `as-encoding? < 1756758807 559690 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :`cat bin/as-encoding < 1756758810 377874 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :cat: bin/as-encoding: No such file or directory < 1756758816 680867 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Oh, right. < 1756758855 716866 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :`as-encoding jrcxz 1f; 1: nop < 1756758857 241949 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :e3 00: jrcxz 0x2 \ 90: nop < 1756758858 696947 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :`asm jrcxz 1f; 1: nop < 1756758860 6690 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :0: e3 00 jrcxz 0x2 \ 2: 90 nop < 1756758863 493642 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Hmm. < 1756759140 614740 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`as-encoding xchg eax, eax < 1756759142 933975 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​{standard input}: Assembler messages: \ {standard input}:1: Error: too many memory references for `xchg' < 1756759155 275047 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`as-encoding xchg %eax, %eax < 1756759157 82491 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :87 c0: xchg %eax,%eax < 1756759183 992060 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…now I'm wondering whether or not that's the most efficient way to zero the top half of %rax < 1756759187 557653 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Heh, that Intel erratum is also weird. Notably... one of the cases where the contents of CX was supposedly unreliable was a `PUSH` instruction that underflows the stack segment. < 1756759224 998488 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Rather than, you know, something with a `rep` prefix which would be far more understandable. Or, well, loop*. < 1756759267 374691 :visilii!~visilii@85.94.26.33 QUIT :Read error: Connection reset by peer < 1756759276 537636 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(It could be the instruction following one of those tricky instructions of course. But it is weird.) < 1756759384 945404 :visilii!~visilii@85.94.26.33 JOIN #esolangs * :ZNC - https://znc.in < 1756759417 280669 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Oh there's also a comment saying that if you follow the pseudo-code of the LOOP* instructions, *CX is decremented unconditionally, even when #GP is raised. < 1756759457 599438 :int-e!~noone@int-e.eu PRIVMSG #esolangs :So the claim is getting more dubious... or well, it points towards intel doing something weird with those instructions. < 1756759572 67310 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so Linux likes to put the stack near but not at the maximum possible usermode address – that means that the #GP should be testable by mapping the highest usermode address and trying to jump into the noncanonical space above < 1756759586 702476 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I'm not immediately sure how you'd determine what happened to cx, upon catching the segfault < 1756759663 922037 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess you could run it in gdb (which I assume is able to look at noncanonical pointers without crashing) < 1756759689 956931 :int-e!~noone@int-e.eu PRIVMSG #esolangs :how much info can you extract with libsigsegv, hmm < 1756759843 701569 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also I'm not immediately sure whether this would be sigsegv or sigbus – I never really understood the distinction < 1756760256 661622 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1756760300 237132 :int-e!~noone@int-e.eu PRIVMSG #esolangs :It appears that Linux doesn't allow us to map that particular page. < 1756760371 968904 :int-e!~noone@int-e.eu PRIVMSG #esolangs :this works fine, mmap((void *)(0x800000000000ULL - 0x2000), 0x1000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_FIXED, -1, 0) but not when the 0x2000 is replaced by 0x1000 < 1756760417 954395 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :interesting < 1756760436 561707 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and you can't get any nearer than 4096 bytes due to the page size < 1756760451 1716 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :what about if you change the config setting that normally prevents you mmapping over null? < 1756760474 503975 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :/proc/sys/vm/mmap_min_addr < 1756760687 214615 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :unfortunately it isn't documented in the manpages, and I don't want to decompress the kernel source to check there < 1756760701 163415 :ais523!~ais523@user/ais523 QUIT :Quit: sorry about my connection < 1756760706 379457 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: still denied < 1756760718 937650 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1756760725 663797 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :pity < 1756760786 897889 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wonder what the motivation for making that page unmappable is? unlike page 0, I can't immediately think of a security reason < 1756760816 62447 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Though if we can put code at 0 and do a backwards `loop`... hmmm < 1756760854 885149 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(IIRC the primary but not only reason you can't mmap page 0 is to ensure a #PF if the kernel tries to dereference a null pointer – presumably SMAP would catch most cases of that nowadays but the ban on low mmap is probably older) < 1756760869 436960 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :all-bits-1 is a valid address, though < 1756760893 643662 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's a kernel address so you can't normally access it from userspace but that doesn't fit the description of #GP in the docs < 1756760949 861398 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c JOIN #esolangs * :Textual User < 1756761053 248799 :int-e!~noone@int-e.eu PRIVMSG #esolangs :hmm, right. < 1756761802 955759 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :huh, apparently some x86-64s have matrix registers in addition to vector registers, now < 1756761821 416811 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although they don't do much yet except for matrix multiplication and addition < 1756761871 320929 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I think the problem is only that an instruction that both outputs to a (non-eflags) register and can jump is unusual so the pipeline isn't built to handle it. both outputting to a register and jumping are tricky super-optimized things that the pipeline handles in a complicated way, and has to be able to roll back when eg. a speculative jump fails, and the register renamer or jump handler just < 1756761877 328343 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :isn't built to handle this combo easily < 1756761912 696796 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: call/ret both jump and change rsp < 1756761920 697251 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I guess they're probably special-cased < 1756761994 561463 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"change the config setting that normally prevents you mmapping […] /proc/sys/vm/mmap_min_addr" => don't change that in /proc , there's a per-process setting for it < 1756762059 923481 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, setarch --mmap-page-zero < 1756762069 317257 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wait, no < 1756762081 43385 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that automatically maps read-only zeros over null, which is not what we want < 1756762085 309262 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :though I'm not sure that still exist on x86_64; it's mostly for x86_32 running virtual 8086 mode < 1756762126 983457 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it had a very promising name though! < 1756762157 883602 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can't see another similar setting in setarch or personality < 1756762159 476607 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe prctl? < 1756762251 820107 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :nope, can't see it there either < 1756762254 649600 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: meh it seemed okay to change on a single-user machine for the purpose of an experiment < 1756762261 315727 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I changed it back, of course < 1756762613 787205 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: https://man7.org/linux/man-pages/man7/capabilities.7.html CAP_SYS_RAWIO capability lets processes create memory mappings at addresses below the value specified by /proc/sys/vm/mmap_min_addr < 1756762617 791155 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so just be root < 1756762640 210316 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or if you don't like that then create a non-root process that keeps that capability < 1756762735 273380 :tromp!~textual@2001:1c00:3487:1b00:8172:2e8c:f9b:6c5c QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1756762761 857423 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and still no luck at 0x7ffffffff000 < 1756762763 3690 :int-e!~noone@int-e.eu PRIVMSG #esolangs ::P < 1756763029 762763 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wonder whether maybe there's some technical limitation against mapping that address < 1756763063 149341 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I wouldn't expect it, given that there are plenty of other sentinel values to use, and some recent x86-64 processors on which the address is a valid normal address because there are 57 rather than 48 address bits < 1756763869 552927 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think it's just a conservative choice as an additional layer of protection against kernel bugs that would handle a zero address wrong, since zero is a convenient sentinel value even for pointers to userspace for the kernel, and in fact it's used as a special value in lots of user-facing interfaces of the kernel too < 1756763938 557381 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok, maybe that last part isn't true < 1756763975 749061 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think it's not used as a sentinel value in kernel-user interfaces, only within kernel land and within userland < 1756764004 897431 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :no wait, it is < 1756764037 102923 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :mmap without MMAP_FIXED in the flags argument takes the first argument as a hint for where to place the mapping when it's nonzero < 1756764576 157146 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that doesn't use 0x7ffffffff000 as a sentinel < 1756764577 650825 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/hw-vuln/rsb.rst ...this is about preventing having a call instruction at the very end of the canonical user address space, which would put a non-canonical address into the return stack buffer < 1756764607 260261 :int-e!~noone@int-e.eu PRIVMSG #esolangs :https://github.com/torvalds/linux/blob/master/Documentation/arch/x86/x86_64/mm.rst calls it a "guard page" < 1756764614 851578 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: ooh < 1756764618 519865 :int-e!~noone@int-e.eu PRIVMSG #esolangs :both IIUC < 1756764636 979938 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(well, the second one is hard to misunderstand) < 1756764662 218484 :int-e!~noone@int-e.eu PRIVMSG #esolangs :err, "guard hole" < 1756764798 944328 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, it isn't immediately clear to me why a non-canonical address in the RSB would be vulnerable < 1756764808 336283 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it isn't like an attacker can control memory there! < 1756764864 164188 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 JOIN #esolangs DOS_User :[https://web.libera.chat] DOS_User_webchat < 1756764926 637259 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe the issue is that the address wraps to a valid address < 1756764930 700494 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: but an attacker can control memory at 0x0 < 1756764964 20475 :int-e!~noone@int-e.eu PRIVMSG #esolangs :yeah, some sort of wrapping would be my guess < 1756764980 443113 :int-e!~noone@int-e.eu PRIVMSG #esolangs :anyway, I'm not going to dig further, this is good enough for me :) < 1756765013 301664 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(digging further would mean finding the commits surrounding this and then the accompanying LKML discussions) < 1756765074 985459 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :when you're in a guard hole, stop digging? < 1756765089 603584 :int-e!~noone@int-e.eu PRIVMSG #esolangs :that does sound like good advice. < 1756766011 95982 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 QUIT :Ping timeout: 250 seconds < 1756766338 102421 :amby!~ambylastn@host-78-151-24-148.as13285.net QUIT :Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement