< 1595809590 474373 :xelxebar_!~xelxebar@gateway/tor-sasl/xelxebar QUIT :Quit: ZNC 1.7.2+deb3 - https://znc.in < 1595809608 874814 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar JOIN :#esoteric < 1595810283 822806 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar QUIT :Ping timeout: 240 seconds < 1595810752 881325 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar JOIN :#esoteric < 1595814339 997746 :LKoen!~LKoen@81.255.219.130 JOIN :#esoteric > 1595815185 503079 PRIVMSG #esoteric :14[[07Turinf machine14]]4 N10 02https://esolangs.org/w/index.php?oldid=76240 5* 03Hakerh400 5* (+2362) 10+[[Turinf machine]] > 1595815190 228590 PRIVMSG #esoteric :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=76241&oldid=76189 5* 03Hakerh400 5* (+21) 10+[[Turinf machine]] > 1595815193 993222 PRIVMSG #esoteric :14[[07User:Hakerh40014]]4 10 02https://esolangs.org/w/index.php?diff=76242&oldid=76152 5* 03Hakerh400 5* (+21) 10+[[Turinf machine]] < 1595815727 463752 :LKoen!~LKoen@81.255.219.130 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.” < 1595815936 953797 :Phantom___Hoover!~phantomho@82.27.195.88 JOIN :#esoteric < 1595816318 997116 :Phantom___Hoover!~phantomho@82.27.195.88 QUIT :Ping timeout: 256 seconds < 1595818238 115444 :b_jonas!~x@catv-176-63-11-226.catv.broadband.hu PRIVMSG #esoteric :lol today's is a good one https://www.smbc-comics.com/comic/cantor < 1595820336 358778 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net JOIN :#esoteric < 1595820638 702334 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :ACTION would like to note that we math folk are prone to sudden cases of madness < 1595820737 130843 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What should the value for true be? 1 or -1? < 1595820810 15960 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :Uh, I feel like I need more context for that < 1595820830 466238 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I think there are advantages and disadvantages for each way < 1595820907 233671 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :OK, should booleans be signed or unsigned integers? < 1595820916 288466 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Assuming they're thought of as 1-bit integers. < 1595820947 340706 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :I'd be tempted to say "unsigned" < 1595820965 736309 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :idk, [-1, 0] feels like a weirder range for a data type than [0, 1] < 1595821709 553170 :salpynx!794954f8@121.73.84.248 PRIVMSG #esoteric :-1 as true seems wrong. -1 = false 1 = true could be useful, -1 = none or null also works. If you're asking about 1 bit signed or unsigned, doesn't 1 bit just give you a sign? < 1595821857 807373 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :Sure, but if you do it as 2's complement, it does end up making sense < 1595821863 23132 :salpynx!794954f8@121.73.84.248 PRIVMSG #esoteric :maybe I need to think about this more, but 1 bit signed seems like -0 or +0 < 1595821868 926570 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net QUIT :Quit: adu < 1595821987 159036 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :1 bit signed is: 1 bit is the sign bit, 0 bits are the data, so your max is 0, and your min is ~max - 1 = -1 < 1595822012 309630 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :erm, -max - 1 < 1595822325 620546 :salpynx!794954f8@121.73.84.248 PRIVMSG #esoteric :yes, that makes sense, as 2s complement for signed 1bit numbers. Is it useful though? Maybe, but doesn't seem especially connected to booleans. It's using 1 bit to represent something else < 1595822371 921232 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :I make no claim that it is in any sense useful. :) < 1595822430 540279 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I've heard people say that booleans should be signed and I think it sounded reasonable at one point? < 1595822433 547963 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But I'm not sure why. < 1595822458 367920 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :I bet it's so that all bits will be true if you use more than 1 bit to represent them. < 1595822506 776857 :salpynx!794954f8@121.73.84.248 PRIVMSG #esoteric :I think I could accept signed booleans as -1 = false 0 = true < 1595822578 981266 :salpynx!794954f8@121.73.84.248 PRIVMSG #esoteric :... which is just inverted < 1595822722 463738 :salpynx!794954f8@121.73.84.248 PRIVMSG #esoteric :next time I look at a truth table I'll be wondering whether those are signed or unsigned values... < 1595823225 786486 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :pikhq: I figured that much, but why is that important? Is that the only thing? < 1595823234 573493 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I mean, I shouldn't be asking you, since you didn't make this claim. > 1595823234 954126 PRIVMSG #esoteric :14[[07Surtic14]]4 M10 02https://esolangs.org/w/index.php?diff=76243&oldid=75669 5* 03Digital Hunter 5* (+215) 10/* Quine */ < 1595823255 75475 :pikhq!sid394595@gateway/web/irccloud.com/x-clfptxdaujhcobju PRIVMSG #esoteric :Yeah, I recall hearing it but super vaguely > 1595823473 808703 PRIVMSG #esoteric :14[[07Surtic14]]4 M10 02https://esolangs.org/w/index.php?diff=76244&oldid=76243 5* 03Digital Hunter 5* (-1) 10/* |Quines */ < 1595825763 805277 :MDude!~MDude@74.5.140.76 QUIT :Quit: Going offline, see ya! (www.adiirc.com) < 1595830450 109311 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar QUIT :Remote host closed the connection < 1595830469 861579 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar JOIN :#esoteric < 1595831441 680224 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I read about German word "Umwelt", but in English it might be "umbworld", so I look that too in Wiktionary, it is there, and seems to be recent (from 2008, apparently) < 1595831568 457248 :TheLie!~TheLie@2a02:8106:215:3300:844d:dece:9bd4:fbb2 JOIN :#esoteric < 1595833360 5443 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Remote host closed the connection < 1595833415 458362 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1595833600 133436 :imode!~linear@unaffiliated/imode QUIT :Ping timeout: 256 seconds < 1595835375 382885 :TheLie!~TheLie@2a02:8106:215:3300:844d:dece:9bd4:fbb2 QUIT :Remote host closed the connection < 1595835562 965141 :craigo!~craigo@144.136.206.168 JOIN :#esoteric < 1595836504 770199 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos JOIN :#esoteric < 1595837010 449498 :hendursa1!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1595837063 830961 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos QUIT :Ping timeout: 240 seconds < 1595837093 827107 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos JOIN :#esoteric < 1595837123 854505 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 240 seconds < 1595838612 875880 :Phantom___Hoover!~phantomho@82.27.195.88 JOIN :#esoteric < 1595838906 695863 :Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1595839561 402102 :sftp!~sftp@unaffiliated/sftp QUIT :Ping timeout: 272 seconds < 1595839622 473730 :sftp!~sftp@unaffiliated/sftp JOIN :#esoteric < 1595840683 426884 :b_jonas!~x@catv-176-63-11-226.catv.broadband.hu QUIT :Quit: leaving < 1595844265 300370 :t20kdc!~20kdc@cpc139340-aztw33-2-0-cust225.18-1.cable.virginm.net JOIN :#esoteric < 1595844303 861361 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos QUIT :Ping timeout: 240 seconds > 1595846057 674884 PRIVMSG #esoteric :14[[07Esolang:Categorization14]]4 10 02https://esolangs.org/w/index.php?diff=76245&oldid=76239 5* 03Ais523 5* (-22) 10Undo revision 76239 by [[Special:Contributions/Icecream17|Icecream17]] ([[User talk:Icecream17|talk]]) rv, I don't think this edit adds anything to the page < 1595846273 53532 :craigo!~craigo@144.136.206.168 QUIT :Ping timeout: 256 seconds < 1595846516 770255 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos JOIN :#esoteric < 1595847810 374203 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1595847979 974289 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 246 seconds < 1595847987 784346 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 NICK :Lord_of_Life > 1595848306 729740 PRIVMSG #esoteric :14[[07Turi14]]4 M10 02https://esolangs.org/w/index.php?diff=76246&oldid=75407 5* 03Osmarks 5* (+4) 10improvement of some kind > 1595848687 314356 PRIVMSG #esoteric :14[[07Turi14]]4 M10 02https://esolangs.org/w/index.php?diff=76247&oldid=76246 5* 03Osmarks 5* (+90) 10clarify digit > 1595848740 471770 PRIVMSG #esoteric :14[[07Turi14]]4 M10 02https://esolangs.org/w/index.php?diff=76248&oldid=76247 5* 03Osmarks 5* (+0) 10fix F# interpreter < 1595848869 194003 :Frater_EST!adrianbibl@172.242.0.73 JOIN :#esoteric < 1595849032 933755 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net JOIN :#esoteric > 1595849415 297238 PRIVMSG #esoteric :14[[07Turi14]]4 10 02https://esolangs.org/w/index.php?diff=76249&oldid=76248 5* 03Osmarks 5* (+693) 10 command, command > 1595849443 613406 PRIVMSG #esoteric :14[[07Turi14]]4 M10 02https://esolangs.org/w/index.php?diff=76250&oldid=76249 5* 03Osmarks 5* (+1) 10 > 1595849843 818392 PRIVMSG #esoteric :14[[07Turi14]]4 10 02https://esolangs.org/w/index.php?diff=76251&oldid=76250 5* 03Osmarks 5* (+160) 10 > 1595850773 192754 PRIVMSG #esoteric :14[[07Subreal14]]4 10 02https://esolangs.org/w/index.php?diff=76252&oldid=76211 5* 03RocketRace 5* (+3468) 10Begin detailing infinite surreal numeric literals < 1595850885 447163 :sftp!~sftp@unaffiliated/sftp QUIT :Ping timeout: 272 seconds > 1595850935 748495 PRIVMSG #esoteric :14[[07Subreal14]]4 M10 02https://esolangs.org/w/index.php?diff=76253&oldid=76252 5* 03RocketRace 5* (-1) 10Syntax < 1595850941 185667 :aaaaaa!~ArthurStr@nat-pool-13-124.soborka.net JOIN :#esoteric < 1595851022 560911 :sftp!~sftp@unaffiliated/sftp JOIN :#esoteric < 1595851403 789278 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos QUIT :Ping timeout: 240 seconds < 1595851730 955296 :craigo!~craigo@144.136.206.168 JOIN :#esoteric < 1595852172 674424 :xkapastel!uid17782@gateway/web/irccloud.com/x-dxnvixxdfeqvtkko JOIN :#esoteric < 1595852191 64588 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 JOIN :#esoteric < 1595852262 841610 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :shachaf: re https://esolangs.org/logs/2020-07-27.html#lo "What should the value for true be? 1 or -1?" => I talked about that in #esoteric previously, you may find it somewhere in the chat logs. It's complicated. < 1595853475 938443 :rain1!~rain1@unaffiliated/rain1 QUIT :Remote host closed the connection < 1595853495 673909 :rain1!~rain1@unaffiliated/rain1 JOIN :#esoteric < 1595854316 768399 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :shachaf: Basically -1 is the better representation more often, because of boolean masking operations, but 1 is sometimes also useful, partly because of intrinsic use like summing a boolean array to get a count, partly because of the x86_64 SETcc instructions inherited from 386 back when branchless code wasn't yet a priority; < 1595854404 569065 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :however, that applies for low-level code, in high level code you probably want to decouple the representation from the symbolic value, so the optimizer decides the representation which can differ for different pieces of code, but when you convert a bool to an int a true value is converted to 1, this is already the case in C and C++. < 1595854437 683610 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :The optimizer or interpreter can also choose different sizes (1 bit, 1 byte, 2 bytes, 4 bytes, 8 bytes etc) for the booleans. < 1595854455 959446 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :Or can temporarily store them in the carry flag, for single boolean tests. < 1595854506 815600 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :pikhq, salpynx: ^ < 1595854518 509313 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I'm pretty sure SETcc exist in order to accomodate boolean values 0/1, not vice versa. < 1595854536 551466 :int-e!~noone@int-e.eu PRIVMSG #esoteric :i.e., if the C convention had been -1 for true, SETcc would just set all the bits. < 1595854563 874526 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :int-e: because C was already using that, and because on those old CPUs the difference rarely matters, because you don't want to have branchless code. < 1595854581 142693 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :but at the same time fortran and basic was also ran on those cpus and is using different conventions < 1595854647 879568 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :all the new vector instructions use -1 as the representation when they write a true, and check the sign bit to decide if a boolean is true. < 1595854683 565587 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :and of course 1 is useful for indexing arrays. < 1595855156 777793 :int-e!~noone@int-e.eu PRIVMSG #esoteric :IIRC i386 added a prefetch queue so was the first x86 CPU to suffer from branching code. < 1595855206 113378 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Sure, writing -1 is more useful for masking tricks. < 1595855320 189958 :int-e!~noone@int-e.eu PRIVMSG #esoteric :And I believe SETcc is really a historical accident... an instruction clearly in the CISC mindset (something like, make every subexpression a compiler face translatable into one or two instructions) that turned out to be valuable for deeply pipelined architectures that hate (unpredictable) branches. < 1595855425 937529 :salpynx!794954f8@121.73.84.248 QUIT :Remote host closed the connection < 1595855444 568625 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :int-e: I'm not sure, but I think even 286 could technically benefit from branchless code, because it still does prefetching like the 6502 does, so a taken branch costs two extra cycles compared to a non-taken branch, but I might be mixing up cpus here. < 1595855486 310342 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :but the pipeline just gets deeper and deeper after that, so the later a non-mobile cpu is, the more it benefits from branchless code < 1595855498 71565 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :(there's some non-monotonicity in the low-power mobile cpus) < 1595855570 272596 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :it's just that that 2 cycle penalty for the taken branch is almost always cheaper than executin both branches < 1595855631 685569 :int-e!~noone@int-e.eu PRIVMSG #esoteric :hmm, https://en.wikipedia.org/wiki/Prefetch_input_queue suggests this goes back all the way to 8086 and 8088. Hmm. < 1595855652 978626 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :but you're right that a lot of the instruction set are historical instructions, the whole x86 instruction set started out as being able to do anything in a *single* instruction that a z80 instruction can do, as if being a single instruction was somehow an advantage < 1595855660 416877 :int-e!~noone@int-e.eu PRIVMSG #esoteric :but maybe i386 was the first to use it for more than one instruction in advance? < 1595855675 153710 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :(mind you, one instruction instead of multiple is a pretty good heuristic, barring other complications, but still) < 1595855682 974140 :salpynx!794954f8@121.73.84.248 JOIN :#esoteric < 1595855700 684185 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :int-e: yeah, probably, the 386 has a longer penalty for taken branches because it has a decode queue and always decodes as if branches weren't taken < 1595855719 745675 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :or something, I totally forgot all this historical crap because it's irrelevant for anything I program these days < 1595855750 503942 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :I don't claim that I understand current cpus, nobody does, but I try to have heuristics that apply to them < 1595855758 104993 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I mainly remember because on i386 you could *observe* the prefetch queue length with self-modifying code. < 1595855783 394703 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(poke less than 16 bytes ahead of the current instruction and the newly written instruction won't be executed this time. < 1595855786 479870 :int-e!~noone@int-e.eu PRIVMSG #esoteric :) < 1595855805 603593 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Later processors fixed that, restoring the illusion of sequential writes and reads. < 1595855831 91272 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :int-e: yes, but technically that's true on any modern x86, and it's still screwed by 386 compatibility, as in, every time you do any branch, even a short conditional branch, it has to make sure that self-modifying code is executed correctly (even if slowly), and that slows down the whole architecture even when you don't want to use self-modifying < 1595855831 616402 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :code much < 1595855863 256679 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :int-e: no I don't think so, I think x86 still promises only that self-modifying code executess correctly only if you do a branch instruction between < 1595855886 698917 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :that's for self-modifying in a single cpu core of course < 1595855907 133801 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :but it's possible that the implementation is like what you say < 1595855907 770053 :int-e!~noone@int-e.eu PRIVMSG #esoteric :by "later" I mean the next few generations, so basically early Pentiums. < 1595855924 625462 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :pentiums introduce out of order execution, right? < 1595855955 374249 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I think so. < 1595855984 577111 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :out of order execution with register renaming is such a crazy mad science invention, it's a wonder x86 cpus can do it without way too many stupid bugs < 1595856024 398332 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :if there weren't actual cpus doing it, I'd guess it was theoretically possible but never worth in practice, because you can't implement it correctly and gain performance with it < 1595856042 126673 :int-e!~noone@int-e.eu PRIVMSG #esoteric :But as prefetch queues grew, they were increasingly likely to break good old-fashioned self-modifying 8086 code, so for a while there was a good reason to invalidate the queue when it overlapped with a store. < 1595856081 839720 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :like, caching memory? sure, the memory is several clock cycles from you, signals can't propagate that fast, so you put a small cache close to the cpu. it's magic, and hard to implement, but it is worht. < 1595856119 371603 :tromp!~tromp@2a02:a210:ca3:2800:49f5:b4db:da88:8ff5 JOIN :#esoteric < 1595856131 623541 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :"good old-fashioned self-modifying 8086 code" => is that so common really? x86 has index registers, most code doesn't self-modify so quickly. but maybe I just don't read old code. < 1595856148 157800 :int-e!~noone@int-e.eu PRIVMSG #esoteric :it was common < 1595856184 430757 :int-e!~noone@int-e.eu PRIVMSG #esoteric :if only because for example, some of the libraries that shipped with compilers contained self-modifying code. (Borland's BGI had quite a few instances.) < 1595856234 907462 :tromp_!~tromp@ip-213-127-104-154.ip.prioritytelecom.net QUIT :Ping timeout: 260 seconds < 1595856275 269735 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Things like Bresenham line-drawing code that encodes the direction taken by replacing incs with decs as needed, and possibly modifying immediates of some instructions because registers were so scarce. < 1595856318 140945 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Obviously none of this is sane once you have multiple threads. < 1595856423 536887 :int-e!~noone@int-e.eu PRIVMSG #esoteric :And it's also pretty firmly in the domain of hand-written assembly code. < 1595856588 890470 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :int-e: self-modifying code sure, but the kind of self-modifying code that doesn't do a jump instruction between? every cpu technically has to support some kind of self-modifying code, so you can load a program. < 1595856601 840997 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :replacing incs with decs as needed? wow < 1595856653 845374 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :I've heard of BASIC code that uses machine code to replace between WRITE and READ for its save/load code... < 1595856659 209487 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :no wait, it's not READ < 1595856666 40178 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :replaces between PUT and GET < 1595856750 49442 :int-e!~noone@int-e.eu PRIVMSG #esoteric :wib_jonas: The only reason I know a bit about this is that I once wrote code to measure the length of the prefetch queue. It produced interesting numbers on 386, 486, but on Pentium it always resulted in 0. I don't recall whether I ever ran it on a 286. < 1595856788 847921 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :as in, game code printed into a magazine for a particular BASIC computer, probably commodore 64, where the game can be saved or loaded by writing the values of some variables and arrays in a partly unrolled loop. < 1595856802 65870 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(it worked by poking an inc instruction into a bunch of nops that were about to be executed) < 1595856858 553957 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I think modifying operands of memory-referencing instructions is reasonably common in Z80 code. < 1595856888 778530 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos JOIN :#esoteric < 1595856893 244615 :int-e!~noone@int-e.eu PRIVMSG #esoteric :It happens in MIX code too :P < 1595856921 627485 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(Unless my memory deceives me very badly. It might.) < 1595856995 719438 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Isn't there a MIX-in-MIX emulator in TAoCP that relies on copying instructions for most of its work? < 1595857023 839919 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(Not quite the same, but also an instance of heavily self-modifying code.) < 1595857423 877966 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :rfk86 has one case that changes the immediates in an upcoming pair of "bit N, a" and "set N, a" instructions, because I don't think there's a variant of those instructions that takes a register operand. < 1595857469 481175 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :int-e: what happens in MIX code? oh yeah, early self-modifying code. sure, it's a 70s computer, it made sense back then, most MIX implementations probably have synchronized memory access and don't even bother prefetching a single instruction < 1595857519 453536 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :in MIX, you effectively have to use self-modifying code to do function returns efficiently. you could avoid them, but it would be slower. < 1595857573 723115 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :MMIX fixes this, it has very strict rules about when self-modifying code is allowed, even on a single thread: < 1595857635 73138 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :there's a single special instruction to remove a memory range from code caches, and you must execute it between writing memory and executing it, no matter how many other things you do in between < 1595857661 157682 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :so the linker would execute that instruction on all the code loaded before it transfers control to the program < 1595857756 786190 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :and the operating system probably executes that instruction when zeroing a page before mapping it, so that a program can't sneakily get side channel information about data that was mapped to a different process, which sound silly, but MMIX's operating system interface is always like this, < 1595857782 242286 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :. < 1595857898 742502 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :so I guess to zero a page, you first call the pre-write instruction to throw away (roll back) any write-behind data cache, then you zero each word, then you call the pre-execute instruction to make sure the code cache doesn't leak information < 1595857957 69950 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :and this just gets worse if the cpu has three different kinds of branch prediction caches, like x86 has, and you have to make sure neither of them can leak side channel data from your cryptography code < 1595858643 52820 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :Ok I'm scared now. I'm writing code, I'm making a class with several arithmetic operators overloaded on it, it's intended to be used mixed with ordinary integers in a weakly typed language where you don't know in compile time if a variable has an integer or this type, I recognize that this is usually two much magic, < 1595858650 514390 :hendursa1!~weechat@gateway/tor-sasl/hendursaga QUIT :Quit: hendursa1 < 1595858667 23329 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1595858688 647998 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :I already wrote multiple paragraphs of explanation for what the fuck this class does in comments, and I still haven't manged to convince myself that I should abandon this and do the more usual non-magic solution. < 1595858742 455011 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :Either I'll realize that later, halfway into writing this or when maintaining the code, or if not, maybe operator overloading arithmetic operations is sometimes actually useful. < 1595860242 949502 :salpynx!794954f8@121.73.84.248 QUIT :Remote host closed the connection < 1595860997 641933 :Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net JOIN :#esoteric < 1595862452 257043 :Arcorann!~awych@121-200-5-186.79c805.syd.nbn.aussiebb.net QUIT :Read error: Connection reset by peer < 1595863023 802040 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos QUIT :Ping timeout: 240 seconds < 1595863551 574235 :xkapastel!uid17782@gateway/web/irccloud.com/x-dxnvixxdfeqvtkko QUIT :Quit: Connection closed for inactivity < 1595864945 278873 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos JOIN :#esoteric < 1595866515 541751 :wib_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 QUIT :Quit: Connection closed < 1595866951 604469 :LKoen!~LKoen@81.255.219.130 JOIN :#esoteric < 1595867709 40448 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I did remember reading a MIX-in-MIX emulator in TAoCP that relies on copying instructions for most of its work. (I only borrowed that book, so I do not still have.) < 1595869879 437619 :b_jonas!~x@catv-176-63-11-133.catv.broadband.hu JOIN :#esoteric < 1595870699 31625 :LKoen!~LKoen@81.255.219.130 QUIT :Remote host closed the connection < 1595871874 922911 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca QUIT :Ping timeout: 256 seconds > 1595871994 713021 PRIVMSG #esoteric :14[[07User:Palaiologos14]]4 M10 02https://esolangs.org/w/index.php?diff=76254&oldid=73739 5* 03Palaiologos 5* (-59) 10 < 1595872299 869121 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca JOIN :#esoteric < 1595875937 307685 :Phantom__Hoover!~phantomho@unaffiliated/phantom-hoover JOIN :#esoteric < 1595876124 976145 :Phantom___Hoover!~phantomho@82.27.195.88 QUIT :Ping timeout: 256 seconds < 1595876731 371996 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos QUIT :Quit: quit < 1595877716 62488 :rain1!~rain1@unaffiliated/rain1 PRIVMSG #esoteric :https://groupprops.subwiki.org/wiki/Groups_of_order_2%5En check the last 2 entries of this table < 1595878442 778205 :tromp!~tromp@2a02:a210:ca3:2800:49f5:b4db:da88:8ff5 QUIT :Remote host closed the connection < 1595878811 919318 :tromp!~tromp@ip-213-127-104-154.ip.prioritytelecom.net JOIN :#esoteric < 1595878901 674574 :tromp!~tromp@ip-213-127-104-154.ip.prioritytelecom.net QUIT :Remote host closed the connection < 1595878925 480463 :tromp!~tromp@2a02:a210:ca3:2800:245e:4c60:1d1e:be76 JOIN :#esoteric < 1595879071 438447 :b_jonas!~x@catv-176-63-11-133.catv.broadband.hu PRIVMSG #esoteric :zzo38: I have a pair of M:tG rules theory questions. with "Skullbriar, the Walking Grave" plus "Gisa and Geralf", we can now have counters on a card on the stack. is it possible (in non-un magic) to have a counter on a sorcery or instant spell on the stack? if there's a lifelink or deathtouch counter on a card on the stack that isn't a sorcery or instant, is it possible for the keyword that it gives to < 1595879077 434096 :b_jonas!~x@catv-176-63-11-133.catv.broadband.hu PRIVMSG #esoteric :matter for the rules before it's moved to another zone? < 1595879135 251543 :b_jonas!~x@catv-176-63-11-133.catv.broadband.hu PRIVMSG #esoteric :I'm asking this because of a hypothetical nonexistant card that lets you directly put a counter on a spell. < 1595879187 97800 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :b_jonas: Rule 122.1b says that keyword counters do count on objects in zones other than the battlefield, but it seems to say that if the object isn't in the battlefield, it has to be a card in order for the keyword counters to work, and that doesn't make much sense to me. < 1595879214 126516 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :But lifelink and deathtouch would be suitable if the spell deals damage. < 1595879450 168832 :b_jonas!~x@catv-176-63-11-133.catv.broadband.hu PRIVMSG #esoteric :zzo38: yes, and I know examples where a counter on a card in the gy or stack matters: a +1/+1 counter for Morbid Bloom, or a flying counter on a Skullbriar that you cast from the graveyard < 1595879450 312542 :int-e!~noone@int-e.eu PRIVMSG #esoteric :. o O ( enchant target counter ) < 1595879499 440923 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :int-e: Only players and objects can be targeted. (The rules previously allowed zones to be targeted too, but this is no longer the case.) < 1595879516 92753 :b_jonas!~x@catv-176-63-11-133.catv.broadband.hu PRIVMSG #esoteric :(Hidden Spider works differently from the other Hidden enchantments, I know this because Hidden Spider is an actually useful card that I used in my green decks.) < 1595879566 285182 :int-e!~noone@int-e.eu PRIVMSG #esoteric :zzo38: Did they get rid of the golden rule that the card text wins? < 1595879608 804584 :int-e!~noone@int-e.eu PRIVMSG #esoteric :It's sill of course, maybe Un-territory. < 1595879609 848913 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :int-e: No, but it even if the card text says something, it doesn't necessarily mean that the rules support it. < 1595879621 491515 :int-e!~noone@int-e.eu PRIVMSG #esoteric :*silly < 1595879627 176435 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(But, in Un-cards, you can ignore the fact that the rules don't support it.) < 1595880008 966960 :salpynx!794954f8@121.73.84.248 JOIN :#esoteric < 1595880095 766106 :MDude!~MDude@74.5.140.76 JOIN :#esoteric < 1595880159 226702 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(My own card set I am making with TeXnicard includes a fixed version of rule 122.1b, mentioned in the text of the "Rules" user variable.) < 1595880527 859076 :xkapastel!uid17782@gateway/web/irccloud.com/x-grdnynqdugkilmgv JOIN :#esoteric < 1595881689 669175 :tromp!~tromp@2a02:a210:ca3:2800:245e:4c60:1d1e:be76 QUIT :Remote host closed the connection < 1595881827 17322 :tromp!~tromp@2a02:a210:ca3:2800:245e:4c60:1d1e:be76 JOIN :#esoteric < 1595883066 136665 :tromp!~tromp@2a02:a210:ca3:2800:245e:4c60:1d1e:be76 QUIT :Remote host closed the connection < 1595883203 785721 :tromp!~tromp@2a02:a210:ca3:2800:245e:4c60:1d1e:be76 JOIN :#esoteric < 1595887283 932254 :imode!~linear@unaffiliated/imode JOIN :#esoteric < 1595888143 984895 :tromp!~tromp@2a02:a210:ca3:2800:245e:4c60:1d1e:be76 QUIT :Remote host closed the connection < 1595888849 162736 :aaaaaa!~ArthurStr@nat-pool-13-124.soborka.net QUIT :Quit: leaving < 1595888873 255449 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net QUIT :Quit: adu < 1595889772 226845 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net JOIN :#esoteric < 1595890962 429583 :xkapastel!uid17782@gateway/web/irccloud.com/x-grdnynqdugkilmgv QUIT :Quit: Connection closed for inactivity < 1595891074 327011 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1595891217 21504 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 256 seconds < 1595891217 304253 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 NICK :Lord_of_Life < 1595891442 34106 :aaaaaa!~ArthurStr@nat-pool-13-124.soborka.net JOIN :#esoteric < 1595891958 254983 :aaaaaa!~ArthurStr@nat-pool-13-124.soborka.net PART :#esoteric < 1595892185 580727 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net QUIT :Quit: adu < 1595892692 1910 :Arcorann!~awych@121-200-5-186.79c805.syd.nbn.aussiebb.net JOIN :#esoteric < 1595893287 594332 :V!v@anomalous.eu JOIN :#esoteric